juanschallibaum/cve-2024-38473-nuclei-templateNuclei-Vorlage zur Erkennung von Apache-Servern, die für CVE-2024-38473 anfällig sind
Nuclei-Vorlage zur Erkennung von Apache-Servern, die anfällig für CVE-2024-38473 sind. Sie identifiziert zunächst Server, die Apache < 2.4.60 mit Standard-PHP-FPM-Einstellungen betreiben. Anschließend fuzzt sie nach potenziellen PHP-Dateien, die durch ACLs geschützt sind und aufgrund dieser Schwachstelle umgangen werden könnten.
Um diese Nuclei-Vorlage zu verwenden, müssen Sie das Repository klonen. Dies können Sie mit folgendem Befehl tun:
git clone https://github.com/juanschallibaum/CVE-2024-38473-Nuclei-Template
Navigieren Sie zum Verzeichnis des geklonten Repositorys:
cd CVE-2024-38473-Nuclei-Template
Nuclei-Vorlage auf einem einzelnen Host ausführen:
nuclei -t CVE-2024-38473.yaml -u http://example.com
Nuclei-Vorlage gegen eine Liste von Hosts ausführen:
nuclei -t CVE-2024-38473.yaml -l hosts.txt
Nuclei-Vorlage auf einem einzelnen Host ausführen und eine gültige .html- oder .php-Datei angeben:
nuclei -t CVE-2024-38473.yaml -u http://example.com/valid.php
Auf diese Weise kann eine höhere Erkennungsrate erzielt werden. Sie können auch URLs in diesem Format in die Hosts-Datei aufnehmen, um die Vorlage gegen diese Liste auszuführen.
Um die CVE-2024-38473-Schwachstelle einfach zu testen, können Sie mit Docker eine anfällige Umgebung einrichten. Befolgen Sie diese Schritte, um die Wirksamkeit der Nuclei-Vorlage schnell zu überprüfen:
Stellen Sie sicher, dass der Docker-Daemon läuft: Vergewissern Sie sich, dass der Docker-Daemon auf Ihrem System läuft. Sie können ihn mit dem folgenden Befehl starten, falls er noch nicht läuft:
sudo systemctl start docker
Docker-Container ausführen: Führen Sie im Repository-Verzeichnis den folgenden Docker-Befehl aus, um einen Container mit einer anfälligen Apache- und PHP-FPM-Konfiguration zu starten:
docker run -p 8787:80 -v "$(pwd)/test-env-webroot:/app" webdevops/php-apache:7.1
Schwachstelle testen:
Manuell: Öffnen Sie Ihren Webbrowser und navigieren Sie zu http://localhost:8787, um mit dem Apache-Server im Docker-Container zu interagieren. Rufen Sie http://localhost:8787/info.php auf, um die Schwachstelle zu testen. Diese Datei ist durch eine ACL geschützt, und wenn die ACL-Umgehung erfolgreich ist, sehen Sie die Ausgabe von phpinfo():
Mit der Nuclei-Vorlage: Führen Sie den folgenden Nuclei-Befehl aus, um den Server mit der Vorlage zu testen:
nuclei -t CVE-2024-38473.yaml -u http://localhost:8787
Am 8. August 2024 hielt der Sicherheitsforscher Orange Tsai auf der Black Hat USA 2024 einen Vortrag mit dem Titel: Confusion Attacks: Exploiting Hidden Semantic Ambiguity in Apache HTTP Server!. In diesem Vortrag berichtete er über mehrere Schwachstellen, die den Apache HTTP Server betreffen. Er erklärte, dass Apache eine hochmodulare Architektur besitzt, die aus Hunderten von Modulen besteht, von denen jedes seine Funktion erfüllt, während es auf eine gemeinsam genutzte Struktur namens request_rec liest und schreibt, die fast 100 Felder umfasst.
Die Ursache der vom Sicherheitsforscher gemeldeten Schwachstellen liegt in der Inkonsistenz, wie verschiedene Apache-Module die verschiedenen Felder der gemeinsamen Struktur behandeln. Beispielsweise behandelt mod_authz_core das Feld r->filename als eine Datei, während mod_proxy es als eine URL behandelt, was zu Diskrepanzen führt, die eine Vielzahl von Schwachstellen verursachen.
In seinem Vortrag definiert Orange Tsai eine Angriffsart namens 'Filename Confusion'. Obwohl dieser Angriff eine vielfältige Angriffsfläche hat, bezieht sich CVE-2024-38473, den wir in dieser Vorlage abdecken, darauf, wie wir den 'Filename Confusion'-Angriff anwenden können, um Apache-ACLs zu umgehen und Zugriff auf eingeschränkte Dateien zu erhalten.
Das Problem tritt auf, wenn das Authentifizierungsmodul von Apache, mod_authz_core, das Attribut r->filename als eine Datei behandelt, während mod_proxy es als eine URL behandelt. Dadurch sind Apache-Installationen mit PHP-FPM in ihrer Standardkonfiguration von dieser Schwachstelle betroffen. Stellen Sie sich vor, ein Server mit Apache und PHP-FPM hat eine ACL wie die folgende konfiguriert, um den Zugriff auf die Datei admin.php mit Anmeldeinformationen zu schützen:
<Files "admin.php">
AuthType Basic
AuthName "Admin Panel"
AuthUserFile "/etc/apache2/.htpasswd"
Require valid-user
</Files>
Aufgrund der Schwachstelle ist es möglich, ACLs wie die oben genannte zu umgehen, die den Schutz einer einzelnen Datei betreffen. Tatsächlich kann dies so einfach wie das Senden der folgenden Anfrage erfolgen: http://server/admin.php%3fooo.php.
Um dies gründlich zu verstehen, ist es wichtig zu bedenken, dass beim Verarbeiten einer Anfrage wie der obigen durch Apache das Modul mod_authz_core den Wert admin.php?fooo.php aus dem Feld r->filename der gemeinsamen Struktur liest. Es behandelt diesen Wert als den Namen der angeforderten Datei, und beim Vergleich mit der ACL ergibt sich keine Übereinstimmung, da admin.php?fooo.php sich von admin.php unterscheidet.
Da admin.php?fooo.php auf .php endet, wird die Anfrage von PHP-FPM bearbeitet. PHP-FPM entfernt vor der Verarbeitung alles, was in dem von Apache empfangenen Dateinamen auf das ? folgt, und behandelt es eher als URL denn als Datei. Infolgedessen verarbeitet PHP-FPM direkt admin.php. Da die ACL-Prüfung zuvor bestanden wurde, kann der Angreifer ohne Authentifizierung auf admin.php zugreifen.
Die aktuelle Nuclei-Vorlage zielt nicht nur darauf ab, geschützte Dateien durch Brute-Force zu entdecken, sondern enthält auch eine Logik, um zu identifizieren, wann ein Server eine anfällige Apache < 2.4.60-Konfiguration mit PHP-FPM aufweist, selbst wenn keine durch ACLs geschützten Dateien erkannt werden. Im grundlegenden Ablauf wird zunächst versucht zu identifizieren, ob der Server eine anfällige Konfiguration hat, und falls ja, wird versucht, häufige Dateien zu identifizieren, die möglicherweise durch ACLs geschützt sind.
Die Idee hinter der Erkennung anfälliger Konfigurationen mit Apache < 2.4.60 und PHP-FPM basiert auf zwei grundlegenden Annahmen:
In einer anfälligen Konfiguration würde die Anfrage an http://server/file.php%3fooo.php denselben 200-Statuscode und dieselbe Antwortlänge zurückgeben wie die Anfrage an http://server/file.php, wenn file.php auf dem Server existiert (da PHP-FPM nach dem Entfernen von %3fooo.php die angeforderte Datei gleich wäre).
In einer anfälligen Konfiguration würde die Anfrage an http://server/file.html%3fooo.php einen 403 Access Denied zurückgeben, wenn file.html auf dem Server existiert. Dies liegt daran, dass PHP-FPM versuchen würde, eine Datei mit der Erweiterung .html statt .php zu laden, was standardmäßig nicht erlaubt ist.
Der Ablauf der Vorlage besteht aus 7 Gruppen von Anfragen. Sie müssen in der Reihenfolge ausgeführt werden und die jeweiligen Trefferbedingungen erfüllen, um zur nächsten Gruppe von Anfragen überzugehen. Dies hilft, die Anzahl unnötig gesendeter Anfragen zu minimieren, wenn Bedingungen bereits bekanntermaßen nicht erfüllt sind.
Die Vorlage sendet eine Anfrage an index.phpooo.php%3fooo.php, eine nicht existierende Datei. Die Idee ist, Fehlalarme auszuschließen, wenn index.php%3fooo.php einen 200-Statuscode und denselben Inhalt wie index.php zurückgibt, obwohl PHP-FPM nicht konfiguriert ist. Dies könnte beispielsweise auftreten, wenn es Regeln gibt, die jede angeforderte Datei oder Dateien, die mit 'index' beginnen, auf index.php umschreiben, wie zum Beispiel:
RewriteRule . /index.php [L]
RewriteRule ^index\.php(.*)$ index.php [L]
RewriteRule ^index(.*)$ index.php [L]
Diese Anfrage sollte einen 200-Statuscode zurückgeben, wenn der Server Regeln wie die oben genannten hat, oder einen 404-Statuscode in normalen Fällen, in denen PHP-FPM konfiguriert sein könnte. Wenn diese Anfrage keinen 404-Statuscode zurückgibt, stoppt die Vorlage die Verarbeitung auf diesem Host.
Die Vorlage sendet eine Anfrage an foo.phpooo.php%3fooo.php, eine nicht existierende Datei. Die Idee ist, Fehlalarme auszuschließen, wenn index.html%3fooo.php einen 403-Statuscode zurückgibt, obwohl PHP-FPM nicht konfiguriert ist. Dies könnte beispielsweise auftreten, wenn es Regeln gibt, die das Zeichen %3f an einer beliebigen Stelle in der URL verbieten oder den Zugriff auf Dateien, die mit .php enden, einschränken. Beispiele für solche Regeln sind:
<FilesMatch "\.php$">
Require all denied
</FilesMatch>
RewriteCond %{REQUEST_URI} (%3f)
RewriteRule ^(.*)$ - [F]
Diese Anfrage sollte einen 403-Statuscode zurückgeben, wenn der Server Regeln wie die oben genannten hat, oder einen 404-Statuscode in normalen Fällen, in denen PHP-FPM konfiguriert sein könnte. Wenn diese Anfrage keinen 404-Statuscode zurückgibt, stoppt die Vorlage die Verarbeitung auf diesem Host.
Die Vorlage sendet Anfragen, um einige verfügbare Dateien auf dem Server zu identifizieren. Zunächst wird versucht festzustellen, ob index.php verfügbar ist. Dann wird nach index.html und index.htm gesucht. Schließlich wird die Datei getestet, die in der vom Benutzer angegebenen URL vorhanden ist, falls sie existiert. Wenn Nuclei mit einer gültigen Datei in der URL ausgeführt wird, kann die Erkennungseffektivität in Fällen verbessert werden, in denen klassische Indexdateien nicht existieren.
Die Vorlage sendet eine Anfrage an eine nicht existierende Datei, um die letzten Fehlalarme auszuschließen, wenn index.php%3fooo.php einen 200-Statuscode und denselben Inhalt wie index.php zurückgibt, obwohl PHP-FPM nicht konfiguriert ist. Einige Webserver, insbesondere solche, die nicht Apache sind, ignorieren alles, was auf %3f folgt. Wenn wir also index.php%3fooo.php senden, behandelt der Server es als index.php. Um diese Fälle auszuschließen, sendet die Vorlage eine Anfrage an index.php%3fooo.html (falls index.php auf dem Server gefunden wurde) oder index.html%3fooo.html (falls index.html auf dem Server gefunden wurde). Da es auf .html endet, würde es in normalen Fällen, in denen PHP-FPM konfiguriert sein könnte, nicht von PHP-FPM verarbeitet und als statische Datei behandelt werden, die logischerweise nicht existiert, was zu einem 404-Statuscode führt. In den Fällen, die wir ausschließen möchten, in denen alles nach %3f ignoriert wird, würde es jedoch einen 200-Statuscode zurückgeben. Wenn diese Anfrage keinen 404-Statuscode zurückgibt, stoppt die Vorlage die Verarbeitung auf diesem Host.
Die Vorlage sendet eine Anfrage, um die anfällige Konfiguration zu identifizieren. Es gibt 2 Fälle, von denen mindestens eine der Trefferbedingungen erfüllt sein muss:
Fall 1: In Anfrage Nr. 3 wurde index.php gefunden. In diesem Fall sollte Apache < 2.4.60 mit PHP-FPM in der Standardkonfiguration den Teil %3fooo.php entfernen und index.php laden, was zu einer 200-Antwort mit derselben Länge wie in Anfrage Nr. 3 führt. Wenn mod_php oder ein anderer Handler verwendet wird, würde index.php%3fooo.php als vollständiger Dateiname behandelt und ein 404 zurückgegeben. Damit dieser Fall zutrifft, muss die Anfrage 200 und einen Antwortkörper mit derselben Länge wie die Antwort von Anfrage Nr. 3 zurückgeben.
Fall 2: In Anfrage Nr. 3 wurde index.html gefunden. In diesem Fall sollte Apache < 2.4.60 mit PHP-FPM in der Standardkonfiguration den Teil %3fooo.php entfernen und versuchen, index.html zu laden, was einen 403 Access Denied zurückgeben würde, da PHP-FPM versuchen würde, eine Datei mit einer nicht erlaubten Erweiterung zu laden. Wenn mod_php oder ein anderer Handler verwendet wird, würde index.php%3fooo.php als vollständiger Dateiname behandelt und ein 404 zurückgegeben. Damit dieser Fall zutrifft, muss die Anfrage 404 zurückgeben.
Wenn die Vorlage diesen Punkt erreicht hat, deutet dies darauf hin, dass der Server eine anfällige Konfiguration aufweist. Folglich sendet die Vorlage Anfragen, um nach potenziell geschützten Dateien zu fuzzen, die einen 403-Statuscode zurückgeben oder eine Authentifizierung erfordern und einen 401-Statuscode zurückgeben. Standardmäßig wird versucht, nur eine Handvoll der häufigsten und potenziell geschützten Dateinamen zu identifizieren. Sie können jedoch eine Zeile auskommentieren, um eine benutzerdefinierte Wortliste mit 350 möglichen PHP-Dateinamen zu verwenden.
Die Vorlage sendet eine Anfrage, um zu validieren, dass die in Anfrage Nr. 6 identifizierte geschützte Datei mit dem Bypass einen 200-Statuscode zurückgibt.
Wenn eine Bedingung aus Anfrage Nr. 5 erfüllt ist, deutet dies darauf hin, dass der Server Apache < 2.4.60 mit Standard-PHP-FPM-Einstellungen ausführt. Dies bedeutet, dass eine ACL, die eine einzelne Datei schützt, möglicherweise umgangen werden kann. Allerdings können diese anfälligen Konfigurationen oft erkannt werden, ohne geschützte Dateien zu identifizieren. Standardmäßig verwendet die Vorlage die Wortliste wordlists/potential_protected_php_files_10.php, um nach geschützten Dateien zu fuzzen. Diese Liste enthält die Top 10 der PHP-Dateinamen, die am wahrscheinlichsten durch ACLs geschützt sind. Alternativ ist eine größere Wortliste mit 350 Einträgen verfügbar: wordlists/potential_protected_php_files_350.php. Um zur größeren Liste zu wechseln, kommentieren Sie die 10-Eintrags-Wortliste aus und kommentieren Sie die 350-Eintrags-Liste im YAML-Abschnitt von Anfrage Nr. 6 in der Vorlage ein, wie folgt:
#fuzz: wordlists/potential_protected_php_files_10.txt
fuzz: wordlists/potential_protected_php_files_350.txt
Die Verwendung der größeren Wortliste kann die Chancen erhöhen, geschützte PHP-Dateien zu finden. Allerdings kann die Wortliste potential_protected_php_files_350.txt ungewöhnliche PHP-Dateinamen enthalten und gängigere PHP-Dateinamen vermissen lassen, die durch ACLs geschützt sein könnten. Daher sind Verbesserungen oder Ergänzungen der Wortliste willkommen. Darüber hinaus können für weitere Erkundungen auch noch größere benutzerdefinierte Wortlisten verwendet werden.
Beachten Sie, dass umgehbare ACLs für verschiedene virtuelle Hosts konfiguriert sein können, in .htaccess-Dateien in jedem Verzeichnis der Anwendung, nicht nur im Stammverzeichnis. Daher wird empfohlen, eine gründliche Erkundung von Verzeichnissen und Subdomains durchzuführen und die Vorlage gegen alle identifizierten URLs mit verschiedenen Subdomains und Verzeichnissen auszuführen, um die Chance auf Identifizierung von ACL-geschützten Dateien zu maximieren.
Derzeit stoppt der Ablauf von Anfrage Nr. 6 nach der Identifizierung der ersten ACL-geschützten Datei. Es könnte jedoch weitere geben. Dies liegt daran, dass ich keinen Weg gefunden habe, mit Nuclei mehrere Dateien zu fuzzen, die Ergebnisse zu speichern und sie dann in einer Folgeanfrage zu verwenden, um zu überprüfen, ob der Bypass tatsächlich Zugriff auf die geschützten Dateien gewährt. Daher sind auch Vorschläge willkommen, wie die Vorlage geändert werden kann, um mehrere geschützte Dateien zu identifizieren und zu validieren, dass sie tatsächlich umgehbar sind.
Alle Anerkennung für die Meldung der Schwachstellen und die Durchführung der herausragenden Forschung gebührt Orange Tsai. Seine umfangreiche Arbeit zu Schwachstellen im Apache HTTP Server, einschließlich CVE-2024-38473, hat wesentlich zur Erhöhung des Sicherheitsbewusstseins beigetragen. Ich, Juan Schallibaum, bin ausschließlich für die Erstellung dieser Nuclei-Vorlage verantwortlich, um das Testen und die Erkennung von CVE-2024-38473 zu erleichtern.
Die Verwendung dieser Nuclei-Vorlage zum Angriff auf Ziele ohne vorherige gegenseitige Zustimmung ist illegal. Es liegt in der Verantwortung des Endbenutzers, alle geltenden lokalen, staatlichen und bundesstaatlichen Gesetze einzuhalten. Die Entwickler übernehmen keine Haftung für Missbrauch, Schäden oder rechtliche Konsequenzen, die aus der Verwendung dieser Vorlage resultieren. Stellen Sie immer sicher, dass Sie vor der Durchführung von Sicherheitstests die ausdrückliche Genehmigung haben.