Moderne Webanwendungen sind nicht mehr das, was sie einmal waren. Die praktisch unbegrenzte Bandbreite und der unbegrenzte Speicherplatz, die das Cloud Computing bietet.
Die Microservices, die die monolithische Architektur umkreisen und die mehrschichtigen Anwendungen in kleine unabhängige Komponenten zerlegen. Die Single-Page-Apps, die die meisten Ressourcen (einschließlich der primären DOM-Elemente) einmal pro App-Zyklus laden, so dass Sie die Website nutzen und nur die erforderlichen dynamischen Inhalte aktualisieren können.
Schnelligkeit. Flexibel. Einfache Software-Integration. Cross-Kompatibilität. Kosteneffizienz. Langer Rede kurzer Sinn: Moderne Webanwendungen sind durch und durch leistungsfähig. Gleichzeitig sind sie aber auch leicht anfällig für Remote- und local file inclusion attacke. Aber was ist ein local file inclusion attacke(LFI) überhaupt?
Was ist LFI?
Um es kurz zu machen: LFIs sind Web-Schwachstellen, die durch Fehler der Programmierer ermöglicht werden. Durch die Einführung einer Sicherheitslücke in Webanwendungen ermöglichen unvorsichtige Programmierer unbefugten Benutzern den Zugriff auf Dateien, die Nutzung von Download-Funktionen, das Durchsuchen der verfügbaren Informationen und vieles mehr.
Wie ist dies von Seiten der Hacker möglich? Durch das Schlupfloch der “dynamischen file inclusion”. Unter Ausnutzung dieser Einbindungsmechanismen, die die Entwickler in die App implementieren, können Cyberkriminelle eine fremde Datei in den ursprünglichen Mix einfügen. Von dort aus muss dann nur noch ein einfaches bösartiges Skript ausgeführt werden. Sobald das Skript seine Arbeit getan hat, können Sie die Willkommensmatte auslegen, denn in der App wird freier Platz zur Verfügung stehen, und der Gastgeber wird jemand anderes sein als Sie.
Aber was macht aktuelle Webanwendungen so anfällig für eine LFI-Schwachstelle? Gute Frage.
Das Problem liegt in jeder serverbasierten Skriptsprache im Web, die etwas auf sich hält. Genauer gesagt, mit dem Teil, in dem sie sich auf Dateieinschlüsse verlassen, um den Code der Webanwendungen schön und ordentlich (und auch wartbar) zu halten. Abgesehen davon können Webanwendungen mit Hilfe von Dateieinschlüssen auch Dateien direkt aus dem Dateisystem lesen, Download-Funktionen aktivieren, Konfigurationsdateien parsen und so weiter.
Wo ist das Problem, werden Sie sich fragen? Das Problem kann und wird in den meisten Fällen auf der Seite der Programmierer auftreten. Wenn die Mechanismen zur file inclusion nicht richtig implementiert sind, haben erfahrene Hacker keine Probleme, die Einbindungsmöglichkeiten dieser Mechanismen auszunutzen. Durch die Ausarbeitung und Ausführung eines effektiven local file inclusion attacke Cyberkriminelle vertrauliche Informationen preisgeben, ein Cross-Site-Skript (XSS) einschleusen oder eine Remote-Code-Ausführung (RCE) auslösen.
Klingt ein wenig weit gefasst? Schauen wir uns doch einmal die einzelnen Fälle an.
Beispiele für Local File Inclusion
Da das Ausnutzen einer LFI-Schwachstelle technisch so einfach ist wie das Hinzufügen einer fremden Datei zum System des Ziels, gibt es mehrere Möglichkeiten für Hacker, dies zu tun. Dies sind die gängigsten Methoden:
Der PHP-Dateifall
Laut den Web Tech-Umfragen verwenden 79,2 % aller Websites PHP. Ja, 79,2 % ALLER Websites, Sie haben richtig gelesen. Und PHP hat seine Vorteile, ohne Zweifel. Gleichzeitig stellt dieselbe Skriptsprache aber auch ein Risiko für die meisten heutigen Webanwendungen dar.
Wie Sie wissen, verwenden Entwickler von Websites und Webanwendungen, die PHP verwenden, diese beiden Funktionen, um den Inhalt einer PHP-Datei in eine andere einzubinden:
- Die include()-Funktion
- Die require()-Funktion.
Der Unterschied zwischen diesen Funktionen besteht darin, wie sie auf Probleme beim Laden von Dateien reagieren. Die erste, include-Funktion, meldet eine Warnung, lässt das Skript aber trotzdem weiterlaufen. Die zweite require-Funktion hingegen erzeugt einen schwerwiegenden Fehler und hält das Skript an.
Wie würde also ein PHP-Dateieinschluss-Angriff aussehen? Ungefähr so:
|
1 2 3 |
https://example.com/?page=filename.php |
Dies ist ein Stück Code, das für einen LFI-Angriff anfällig ist. Wenn die Eingabe nicht ordnungsgemäß bereinigt wird, haben Angreifer keine Probleme, die Eingabe zu ändern (siehe Beispiel unten) und die Anwendung so zu manipulieren, dass sie über die Direktive “../” auf eingeschränkte Dateien, Verzeichnisse und allgemeine Informationen zugreift. Dies wird normalerweise als Directory Path Traversal bezeichnet und sieht folgendermaßen aus:
|
1 2 3 |
https://example.com/?page=../../../../etc/test.txt |
In diesem Fall musste der Cyberkriminelle nur den “Dateinamen.php” in der Pfad-URL durch “../../../../etc/test.txt” ersetzen und schon konnte er auf die Testdatei zugreifen. In diesem Stadium könnte(n) der/die Eindringling(e) ein bösartiges Skript auf Ihren Server hochladen und auf dieses Skript über local file inclusion.
Dieser Prozess besteht aus vier Schritten:
- Die Eindringlinge identifizieren ein Weblabor mit unzureichender und/oder Browser-Eingabevalidierung durch die Benutzer der Anwendung.
- Die URL-Zeichenfolge wird mit der Direktive “../” geändert, um Directory Path Traversal zu ermöglichen.
- Die bösartige .php-Datei wird über eine Hintertür auf den Host-Server hochgeladen, um das Skript mithilfe der Path-Traversal-Methode zu finden.
- Der Hacker kann sein bösartiges Skript aufgrund der unzureichenden Validierung auf der Host-Anwendung Amok laufen lassen.
Wie kann man einen solchen Angriff verhindern?
Zunächst einmal können Sie eine Whitelist mit akzeptierten Sprachparametern erstellen. Wenn eine sichere Eingabemethode nicht in Frage kommt, können Sie die Eingabefilterung und die Validierung des übergebenen Pfads einsetzen. Mit Hilfe dieser Methoden können Sie unbeabsichtigte Zeichen und Zeichenmuster aus der Gleichung entfernen.
Das setzt allerdings voraus, dass Sie alle problematischen Zeichenkombinationen vorhersehen können. Eine praktikablere Lösung wäre daher die Verwendung vordefinierter Switch/Case-Anweisungen. Mit diesen bestimmt das System automatisch, welche Dateien einbezogen werden können, ohne sich auf URL- und Formularparameter zu verlassen, um einen Pfad dynamisch zu generieren.
Der Fall der gedruckten Seite
Manchmal müssen Sie die Ausgabe der Datei auf mehrere Webseiten verteilen (wie z. B. bei Header-Dateien). Dieser Ansatz ist am sinnvollsten, wenn Sie möchten, dass die Änderungen auf jeder Seite, auf der die Datei enthalten ist, berücksichtigt werden. Bei diesen Dateien kann es sich um einfache HTML-Dateien handeln, die keine Parser auf der Serverseite benötigen, um sie zu interpretieren. Sie können auch zur Hervorhebung einzelner Dateneinträge, einschließlich einfacher Textdateien, verwendet werden.
Angenommen, Sie haben mehrere .txt-Dateien mit Hilfetexten und möchten diese Dateien über Ihre Webanwendung verfügbar machen. Zu diesem Zweck können Sie sie durch einen Link sichtbar machen, der diesem Link nicht unähnlich ist:
|
1 2 3 |
https://example.com/?helpfile=login.txt |
In diesem Fall wird der Inhalt der Textdatei direkt auf die Seite gedruckt, ohne die Informationen vorher in einer Datenbank zu speichern.
Wie kann dies also zu einer local file inclusion führen?
Wenn Sie nicht über eine angemessene Filterung verfügen, können Angreifer den obigen Link leicht in etwas Ähnliches wie diese Zeilen ändern:
|
1 2 3 |
https://example.com/?helpfile=../secret/.htpasswd |
Infolgedessen können sie auf die Passwort-Hashes in der .htpasswd-Datei und alle Benutzeranmeldedaten zugreifen, die diese Datei normalerweise enthält. Mit diesen Zugangsdaten könnten die digitalen Diebe dann auf die geschützten Bereiche des Servers zugreifen und dort großen Schaden anrichten. Darüber hinaus könnten dieselben Hacker sogar in der Lage sein, versteckte Konfigurationsdateien zu lesen, die sensible Informationen (wie Passwörter) enthalten.
Also gut, wie kann man hier gegensteuern?
Was gedruckte Dateien betrifft, so sind die effektivsten Gegenmaßnahmen die gleichen, die Sie auch gegen Download-Dateien anwenden würden. Sie fragen sich, welche das sind? Prima. Aber lassen Sie uns zuerst herausfinden, was diesen Fall ausmacht.
Download Dateien Fall
Es gibt Dateien, die Webbrowser automatisch öffnen, wenn auf sie zugegriffen wird, nicht anders als PDF-Dateien. Wenn Sie also solche Dateien als Download anbieten wollen, anstatt sie im Browserfenster anzuzeigen, fügen Sie zusätzliche Header ein und weisen damit den Browser an, dies zu tun.
Mit einer Kopfzeile wie Content-Disposition: attachment; filename=file.pdf in der Anfrage verzichtet der Browser auf den Teil “Öffnen” und lädt stattdessen die Datei herunter.
Ein Beispiel: Einige Unternehmen bieten Broschüren im PDF-Format an, die die Besucher der Website über einen Link wie diesen herunterladen können:
|
1 2 3 |
https://example.com/?download=brochure1.pdf |
Wie kann dadurch eine LFI-Schwachstelle entstehen?
Ganz einfach, so geht’s. Genauer gesagt, wenn Sie die Anfrage nicht bereinigen, können Angreifer den Download der Dateien anfordern, auf denen die Webanwendung selbst aufbaut, wodurch sie Zugriff auf den Quellcode erhalten. Auf diese Weise können sie Schwachstellen in anderen Webanwendungen ausfindig machen oder “nur” sensible Dateiinhalte lesen.
Eine weitere schlechte Nachricht ist, dass Hacker diesen Exploit mit der oben erwähnten Methode des Directory Traversal kombinieren können. So könnten sie mit derselben Funktion den Quellcode der Datei connection.php lesen:
|
1 2 3 |
https://example.com/?download=../include/connection.php |
Wenn die Hacker die Werte für die Benutzerdatenbank, den Host und das Kennwort finden (was nicht unwahrscheinlich ist), können sie mit diesen gestohlenen Anmeldedaten auch die Datenbank auslesen. An diesem Punkt haben die Cyberkriminellen die Möglichkeit, Datenbankbefehle auszuführen und die Serverstruktur zu kompromittieren (es sei denn, der Datenbankbenutzer hat keine Schreibrechte für Dateien).
Was können Sie tun, um dies zu verhindern?
- Speichern Sie die Dateipfade in einer Datenbank und weisen Sie ihnen individuelle IDs zu. Wenn Sie dies tun, können die Benutzer nur die ID sehen, so dass sie den Dateipfad nicht anzeigen und ändern können.
- Nehmen Sie verifizierte und gesicherte Dateien in die Whitelist auf. Von dort aus können Sie jeden anderen Dateinamen und Pfad ignorieren.
- Legen Sie keine Dateien auf Webservern ab, die kompromittiert werden können und in den meisten Fällen auch werden. Verwenden Sie stattdessen Datenbanken.
- Führen Sie keine Dateien in bestimmten Verzeichnissen aus. Stellen Sie stattdessen sicher, dass der Server automatisch Header herunterlädt.
LFI-Beispiele aus der Praxis
Wir haben schon viele mutige Plattformen gesehen, die Opfer eines Angriffs mit local file inclusion attacke. Und, Sie werden überrascht sein, es sind nicht nur ein paar kleine Websites, die bereits einen LFI-Angriff erlitten haben. Um es kurz zu machen:
Unterm Strich
Local file inclusion Schwachstellen sind kein Scherz. Einige der größten Plattformen der Welt sind ihnen im Laufe der Jahre zum Opfer gefallen, und die Liste wird immer länger. Solange Sie jedoch die oben genannten Vorschläge befolgen und wachsam bleiben, sollten Sie in der Lage sein, unversehrt weiterzuarbeiten.