File Inclusions: kleiner Programmierfehler, fatale Wirkung, Teil 1

Inhaltsverzeichnis

Ein Verständnis für die allgemeinen Sicherheitslücken, die sich durch File Inclusions ergeben, ist vor allem für Softwareentwickler relevant, die lernen möchten, wie sie die Schwachstellen vermeiden können und für Pentester, die mit den Angriffsmustern vertraut sein müssen, die sich daraus ergeben.

Ein kleiner Codeschnipsel reicht, um große Lücken aufzustoßen, und diese Artikelserie will dabei helfen, Schwachstellen im eigenen Code zu vermeiden. Der erste Teil beschreibt allgemeine Angriffsflächen und der zweite zeigt mit Code-Beispielen, welche Einfallstore existieren.

Manche Sicherheitslücken werden zwar seltener, können aber trotzdem gravierende Folgen haben, wenn Entwickler sie versehentlich in den eigenen Code einbauen. Im Interesse eines modularen Aufbaus der Software sind Teile des Codes als Dateien konzipiert, um beispielsweise einen Footer oder Header zu erzeugen. Das ist sinnvoll, weil Code dadurch besser lesbar und deutlich effizienter wartbar ist.

Das Vorgehen birgt jedoch Gefahren, vor allem wenn das Einbinden der Datei über den Dateinamen direkt erfolgt. Das kann dazu führen, dass sich bei jedem Laden eine sogenannte File-Inclusion-Sicherheitslücke öffnet, die zum Einschleusen von Schadcode oder zur feindlichen Übernahme ganzer Server führen kann.

Für Softwareentwickler

Die gezeigten Beispiele betrachten die Programmiersprachen PHP und JSP (JavaServer Pages) und sind auf Webanwendungen bezogen. Die Beispiele sind öffentlich auf GitHub verfügbar.

Bekannt gewordene Softwaresicherheitslücken wandern standardmäßig in die Liste der Common Vulnerabilities and Exposures (CVE). Die CVE-Liste ist ein Non-Profit-Projekt der MITRE Corporation, einer Ausgründung des MIT, mit Sitz in den USA.

Eine Suche in der CVE-Liste nach "File Inclusion" mit dem Tool cve-search ergibt für den zeitlichen Verlauf das in Abb. 1 gezeigte Schaubild. In den letzten Jahren ist die Menge deutlich zurückgegangen. Betroffen sind heute vornehmlich ältere, nicht gepatchte Programme.

Einige Programmiersprachen und darauf aufbauende Software sind besonders betroffen – in erster Linie PHP. Allerdings findet sich die Lücke ebenso in JSP, ASP, ASPX und in CGI-Skripten, vereinzelt auch in Ruby-basierten Rails-Anwendungen. Die jeweiligen Entwicklergruppen haben die Probleme erkannt und darauf reagiert.

Lokale und entfernte Lücke

File-Inclusion-Lücken treten grundsätzlich auf, wenn der Client von außen die Möglichkeit hat, Dateien mitzugeben, die der Server einbindet. Die Lücken unterscheiden sich in zwei Unterkategorien: Local File Inclusion (LFI) und Remote File Inclusion (RFI).

LFI bedeutet, dass ein Angreifer eine Datei, die auf dem Server der Zielanwendung liegt, in den Programmcode ziehen kann. Je nach Dateityp zeigt die Anwendung den Inhalt der Datei an oder führt ihn sogar aus.

Bei der RFI stammt die in der Zielanwendung geladene Datei von einem fremden Server und zwar dem des Angreifers.

File-Inclusion-Lücken sind über unterschiedliche Flanken angreifbar. Die häufigste Angriffsvariante ist die Manipulation der URL über den Browser durch GET-Parameter. Dabei passiert Folgendes: Die Webseite möchte sich eine Datei für das Einbinden merken. Dafür setzt sie ein Schlüssel-Werte-Paar in der URL. Da sich der Parameter direkt im Browser ändern lässt, können Angreifer bestimmen, was der Server lädt.

Bei der Remote File Inclusion enthält der GET-Parameter statt einer lokalen Datei eine externe URL, die die Zielanwendung anschließend einbindet.

Abstufung der Risikoklassen

Bei LFI/RFI-Angriffen kann man drei Risikoklassen unterscheiden:

1. LFI mit leesendem Zugriff,
2. LFI mit schreibendem Zugriff und
3. RFI.

In der ersten Klasse erschleichen sich Angreifer nur lesenden Zugriff auf die Daten des Servers. In der zweiten Klasse können sie Daten hochladen und ausführen. Ein Upload ist der häufigste, aber nicht einzige Weg. Interpretiert der Server die Daten, lässt sich Schadcode zur Ausführung bringen.

Die letzte Risikoklasse RFI ist besonders gravierend, da sie einfach auszunutzen und von Virensoftware schwierig zu erkennen ist, weil sie nur im Speicher des Ziel-Servers stattfindet.