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.