LFI2RCE via Eternal waiting
Grundlegende Informationen
Standardmäßig generiert PHP beim Hochladen einer Datei (auch wenn es nicht erwartet wird) eine temporäre Datei in /tmp mit einem Namen wie php[a-zA-Z0-9]{6}, obwohl ich einige Docker-Images gesehen habe, bei denen die generierten Dateien keine Ziffern enthalten.
Bei einer lokalen Dateieinschließung erhalten Sie RCE, wenn es Ihnen gelingt, diese hochgeladene Datei einzuschließen.
Beachten Sie, dass PHP standardmäßig nur das Hochladen von 20 Dateien in einer einzelnen Anfrage zulässt (festgelegt in /etc/php/<version>/apache2/php.ini):
Andere Techniken
Andere Techniken beruhen darauf, PHP-Protokolle anzugreifen (Sie werden nicht erfolgreich sein, wenn Sie nur den letzten Teil des Pfads kontrollieren), den Pfad der Datei offenzulegen, erwartete Dateien zu missbrauchen oder PHP dazu zu bringen, einen Segmentierungsfehler zu erleiden, sodass hochgeladene temporäre Dateien nicht gelöscht werden. Diese Technik ist der letzten sehr ähnlich, erfordert jedoch kein Zero-Day.
Ewige Warte-Technik
Bei dieser Technik müssen wir nur einen relativen Pfad kontrollieren. Wenn es uns gelingt, Dateien hochzuladen und die LFI nie enden zu lassen, haben wir "genügend Zeit", um hochgeladene Dateien per Brute-Force zu durchsuchen und eine beliebige der hochgeladenen Dateien zu finden.
Vorteile dieser Technik:
Es ist nur erforderlich, einen relativen Pfad innerhalb eines Includes zu kontrollieren
Erfordert weder nginx noch unerwarteten Zugriff auf Logdateien
Erfordert kein 0-Day, um einen Segmentierungsfehler zu verursachen
Erfordert keine Offenlegung des Pfads
Die Hauptprobleme dieser Technik sind:
Es müssen bestimmte Datei(en) vorhanden sein (es könnten mehr vorhanden sein)
Die enorme Anzahl potenzieller Dateinamen: 56800235584
Wenn der Server keine Zahlen verwendet, beträgt die Gesamtanzahl potenzieller Dateien: 19770609664
Standardmäßig können nur 20 Dateien in einer einzigen Anfrage hochgeladen werden.
Die maximale Anzahl paralleler Worker des verwendeten Servers.
Diese Begrenzung zusammen mit den vorherigen kann dazu führen, dass dieser Angriff zu lange dauert
Timeout für eine PHP-Anfrage. Idealerweise sollte dieser ewig sein oder den PHP-Prozess beenden, ohne die temporär hochgeladenen Dateien zu löschen. Andernfalls wird dies auch zu einem Problem.
Wie also können Sie ein PHP-Include nie enden lassen? Einfach durch das Einbinden der Datei /sys/kernel/security/apparmor/revision (leider nicht verfügbar in Docker-Containern). Probieren Sie es einfach aus, indem Sie folgendes aufrufen:
Apache2
Standardmäßig unterstützt Apache 150 gleichzeitige Verbindungen, gemäß https://ubiq.co/tech-blog/increase-max-connections-apache/ ist es möglich, diese Zahl auf bis zu 8000 zu erhöhen. Folgen Sie diesem Link, um PHP mit diesem Modul zu verwenden: https://www.digitalocean.com/community/tutorials/how-to-configure-apache-http-with-mpm-event-and-php-fpm-on-ubuntu-18-04.
Standardmäßig (wie ich in meinen Tests sehen kann) kann ein PHP-Prozess ewig dauern.
Lassen Sie uns etwas Mathematik machen:
Wir können 149 Verbindungen verwenden, um 149 * 20 = 2980 temporäre Dateien mit unserer Webshell zu generieren.
Verwenden Sie dann die letzte Verbindung, um potenzielle Dateien brute-forcen.
Bei einer Geschwindigkeit von 10 Anfragen/s ergeben sich folgende Zeiten:
56800235584 / 2980 / 10 / 3600 ~= 530 Stunden (50% Chance in 265 Stunden)
(ohne Zahlen) 19770609664 / 2980 / 10 / 3600 ~= 185 Stunden (50% Chance in 93 Stunden)
Beachten Sie, dass wir in diesem Beispiel andere Clients vollständig DoSen!
Wenn der Apache-Server verbessert wird und wir 4000 Verbindungen missbrauchen könnten (halb so viel wie die maximale Anzahl), könnten wir 3999*20 = 79980 Dateien erstellen und die Anzahl würde auf etwa 19,7 Stunden oder 6,9 Stunden reduziert werden (10 Stunden, 3,5 Stunden 50% Chance).
PHP-FMP
Wenn anstelle des regulären PHP-Moduls für Apache zum Ausführen von PHP-Skripten die Webseite PHP-FMP verwendet (was die Effizienz der Webseite verbessert, daher ist es üblich, es zu finden), gibt es noch etwas anderes, das getan werden kann, um die Technik zu verbessern.
PHP-FMP ermöglicht es, den Parameter request_terminate_timeout in /etc/php/<php-version>/fpm/pool.d/www.conf zu konfigurieren.
Dieser Parameter gibt an, nach wie vielen Sekunden die Anfrage an PHP beendet werden muss (standardmäßig unendlich, aber 30 Sekunden, wenn der Parameter auskommentiert ist). Wenn eine Anfrage von PHP verarbeitet wird und die angegebene Anzahl von Sekunden erreicht, wird sie beendet. Das bedeutet, dass, wenn die Anfrage temporäre Dateien hochgeladen hat, weil die PHP-Verarbeitung gestoppt wurde, diese Dateien nicht gelöscht werden. Daher können Sie, wenn Sie eine Anfrage so lange dauern lassen können, Tausende temporäre Dateien generieren, die nicht gelöscht werden, was den Prozess des Auffindens beschleunigt und die Wahrscheinlichkeit eines DoS auf der Plattform verringert, indem alle Verbindungen verbraucht werden.
Um also einen DoS zu vermeiden, nehmen wir an, dass ein Angreifer nur 100 Verbindungen gleichzeitig verwendet und die maximale Verarbeitungszeit von PHP durch PHP-FMP (request_terminate_timeout) 30 Sekunden beträgt. Daher kann die Anzahl der temporären Dateien, die pro Sekunde generiert werden können, berechnet werden als 100*20/30 = 66,67.
Dann würde ein Angreifer 150 Sekunden benötigen, um 10000 Dateien zu generieren: 10000/66.67 = 150s (um 100000 Dateien zu generieren, würde die Zeit 25 Minuten betragen).
Dann könnte der Angreifer diese 100 Verbindungen nutzen, um ein Brute-Force-Suchmuster durchzuführen. Angenommen, eine Geschwindigkeit von 300 Anfragen/s, die benötigte Zeit, um dies auszunutzen, ist wie folgt:
56800235584 / 10000 / 300 / 3600 ~= 5,25 Stunden (50% Chance in 2,63 Stunden)
(mit 100000 Dateien) 56800235584 / 100000 / 300 / 3600 ~= 0,525 Stunden (50% Chance in 0,263 Stunden)
Ja, es ist möglich, 100000 temporäre Dateien in einer EC2 mittleren Instanz zu generieren:
Beachten Sie, dass es ausreicht, die verwundbare LFI-Seite einzuschließen, um den Timeout auszulösen, sodass sie in einer endlosen Include-Schleife landet.
Nginx
Standardmäßig unterstützt Nginx 512 parallele Verbindungen gleichzeitig (und diese Zahl kann verbessert werden).
Last updated
