Bei einem Angriff per Cross-Site Scripting (de.wikipedia.org) wird ein Scriptcode nur im Browser ausgeführt, d.h. es ist nur JavaScript oder VBScript möglich. Bei solchen Angriffen ist i.d.R. “nur” der Besucher einer Website das Ziel.

Ein Angriff per Remote File Inclusion (de.wikipedia.org), kurz RFI, zielt hingegen auf den Server direkt ab und in der Folge natürlich auch auf die Besucher.

Der Begriff Remote File Inclusion beschreibt eine Sicherheitslücke in Skript-basierten Webanwendungen, die es einem Angreifer ermöglicht, unkontrolliert Programmcode in den Webserver einzuschleusen und dort auszuführen.

Wurde ein Server über solch eine Schwachstelle kompromittiert, so hat ein Besucher kaum die Möglichkeit dies zu erkennen oder sich gar dagegen zu schützen.

Über die WordPress-Scripte wird hier z.B. ab und an versucht ein PHP-Script zu injiziert. In diesen Scripten stecken unglaublich viele Funktionen. Ohne nun ins Detail zu gehen: Es ist alles möglich was eine serverseitige Scriptsprache wie PHP bietet. Ich glaube jedem ist klar was ein Angreifer mit einem solchen Script auf einem Server ausspähen, verändern, löschen oder hinzufügen kann.

Das lokale Gegenstück dazu nennt sich Local File Inclusion (LFI). Hier werden lokale Dateien, also die bereits auf dem Server liegen, injiziert. Im ersten Moment denkt man vielleicht: “Wo ist dabei die Schwachstelle?” Darüber kann man z.B. Dateien auslesen in denen Zugangsdaten gespeichert sind oder Informationen darüber, wie der Server konfiguriert ist, was u.U. für weitere Angriffe nutzbar ist. Aber…

Über eine LFI-Schwachstelle können, unter schlechten Umständen, auch neue Dateien auf dem Server erstellt werden!

Zugriffe von Websitebesuchern werden in verschiedenen Logfiles protokolliert. Wird z.B. eine URL aufgerufen die es nicht gibt, so wird ein Eintrag in dem Logfile für Fehler geschrieben, in der die fehlerhafte URL protokolliert wird. Wird nun die nicht existente URL geschickt gewählt, so kann ein Angreifer eine Zeile im Logfile schreiben lassen, die für einen Angriff nutzbar ist. Diese Zeile selber tut noch nichts gefährliches am Server, da es nur eine Datei im Textformat ist. Wird nun aber dieses Logfile per LFI selber aufgerufen, so wird das injizierte Script ausgeführt. Über diesen kleinen Logfile-Umweg kann ein Angreifer, obwohl keine RFI-Schwachstelle vorliegt, sein eigenes Script vom Server ausführen lassen und dieses kann auf dem Server dann auch neue Dateien abspeichern.

Hier mal wieder ein kleines Video:

Mein kleines Beispielscript mag auf den ersten Blick konstruiert wirken, aber dies täuscht nur…

Das Aufbohren der LFI-Schwachstelle zu einer sehr schwerwiegenden Lücke ist nicht neu und warum mache ich mir dann so viel Arbeit? Weil es (angebliche) IT-Security-Fachleute gibt, die LFI als eine Schwachstelle erklären, über die man “nur” Daten auslesen könnte.