bttea/cve-2024-4577-rce-pocCVE-2024-4577 RCE PoC
Bei der Implementierung von PHP bemerkte das Team die Best-Fit-Funktion der Zeichenkodierungskonvertierung im Windows-Betriebssystem nicht. Dieses Versehen ermöglicht es nicht authentifizierten Angreifern, den vorherigen Schutz von CVE-2012-1823 durch bestimmte Zeichenfolgen zu umgehen. Über den Argument-Injektionsangriff kann beliebiger Code auf entfernten PHP-Servern ausgeführt werden.
Dieser PoC dient ausschließlich Lern- und Forschungszwecken. Verwenden Sie ihn nicht für illegale Aktivitäten; Sie sind allein für etwaige rechtliche Konsequenzen verantwortlich.
Diese Schwachstelle wurde von Orange Tsai (@orange_8361) von DEVCORE (@d3vc0r3) entdeckt. Folgen Sie unbedingt seiner herausragenden Forschung; unsere Rolle bestand lediglich darin, den Exploit für dieses Problem nachzubilden und zu entwickeln.
Warum ist es notwendig, das Exploit-Skript neu zu schreiben, wenn es bereits viele öffentlich verfügbare PoCs online gibt?
Da viele öffentlich verfügbare PoCs auf demselben ursprünglichen Exploit basieren, haben viele Anbieter diese PoCs als Referenz verwendet und bestimmte Schlüsselwörter blockiert, um ihre Ausnutzung zu verhindern. Sie übersehen jedoch oft die Blockierung aller potenziellen Exploit-Vektoren. Um dem entgegenzuwirken, enthält das Skript einen einfachen Mechanismus zur Generierung zufälliger Parameter sowie verschiedene LFI-zu-RCE-Ausnutzungsmethoden, um die Erfolgsquote der PHP-CGI-Injektion zu erhöhen, die zu RCE führt.
Während eines Tests, bei dem ich versuchte, eine Umgebungsschwachstelle zu reproduzieren, stellte ich fest, dass mein PoC unabhängig von Anpassungen stets einen HTTP-500-Fehler auslöste. Da ich in einer verwundbaren Umgebung arbeitete, begann ich, die Ursache des Fehlers zu untersuchen. Dann erinnerte ich mich an einen Artikel von Devcore, der erwähnte, dass der Server in bestimmten Exploit-Szenarien einen HTTP-500-Fehler zurückgibt, obwohl der RCE-Exploit tatsächlich erfolgreich war. Mit diesem Gedanken beschloss ich zu testen, ob ich lokal calc.exe starten könnte, und zu meiner Überraschung funktionierte es – es war ein blinder RCE!
Als ich jedoch das Apache-Fehlerprotokoll überprüfte, fand ich einen Fehler, der sich auf allow_url_include bezog, obwohl der Angriff erfolgreich ausgeführt wurde (und ich verstehe die Ursache immer noch nicht vollständig; wenn Sie Einblicke haben, kontaktieren Sie mich bitte). Dies veranlasste mich, einen Exploit zu erstellen, der auch eine Option zum Testen auf blinden RCE enthält 😊.
Wenn Ihr Ziel eine Betriebssystemversion vor Windows 7 ist, können Sie dennoch über andere Methoden auf einen sichtbaren RCE oder eine Reverse Shell eskalieren. Diese Techniken liegen jedoch außerhalb des Rahmens dieses Artikels, daher gehen wir nicht näher darauf ein. Als Penetrationstester oder Red-Team-Spezialist sollten Sie relativ schnell alternative Lösungen finden können, was ein interessanter Prozess sein kann 😉.
Aktualisiert am 15. November 2024
Aufgrund beruflicher Anforderungen habe ich das Skript weiter verbessert, um es so kompatibel wie möglich mit allen Umgebungen zu machen und die Chancen auf RCE zu maximieren. Diese Bemühung wurde dadurch angetrieben, dass einige Ziele PHP mit vielen öffentlichen PoCs nicht erfolgreich ausführen konnten. Schließlich konnte ich dieses Problem unerwartet lösen, indem ich fast alle Fälle von Fehler 500 überwand und die Ausführungsergebnisse von PHP erfolgreich anzeigte. Daher schien blinder RCE nicht mehr so kritisch zu sein. 😧
Ausnutzungsbedingungen
Sie müssen die Abhängigkeiten installieren:
$ python3 -m pip install requests Führen Sie das Skript direkt aus, um die Verwendungshinweise zu erhalten. Mit dem folgenden Befehl können Sie überprüfen, ob das Ziel verwundbar ist.
$ python3 CVE-2024-4577.py <target> <php shell>
Wenn der Exploit auf dem Ziel vorhanden ist, können Sie die PHP-Ausführungsergebnisse lokal speichern, was für diejenigen hilfreich ist, die phpinfo anzeigen müssen.
$ python3 CVE-2024-4577.py <target> "phpinfo()" --save info.html
Wenn das Ziel für blindes RCE verwundbar ist, versucht das Skript, auf einem lokalen Port zu lauschen und den Zielserver zu veranlassen, PHP auszuführen, indem es eine Anfrage sendet, um die Existenz des Exploits zu überprüfen. Wenn die Anfrage empfangen wird, zeigt dies an, dass der Zielserver den Befehl erfolgreich ausgeführt hat.
