File Inclusions: kleiner Programmierfehler, fatale Wirkung, Teil 1

Angriffe über File Inclusions sind vor allem in PHP und JSP nach wie vor möglich und können verheerende Folgen haben.

In Pocket speichern vorlesen Druckansicht 58 Kommentare lesen
File Inclusions: kleiner Programmierfehler, fatale Wirkung, Teil 1
Lesezeit: 12 Min.
Von
  • Matthias Altmann
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.

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.

Das Diagramm zeigt die Suche nach "File Inclusion" über die CVE-Datenbank (Abb. 1).

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.

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.

Grundlegendes Prinzip von LFI (Abb. 2)

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

Szenario von RFI (Abb. 3)

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.

Ein Angreifer analysiert das Rückgabeergebnis auf Veränderung (Abb. 4).

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

Beim Einbinden einer externen Ressource spricht man von einer RFI (Abb. 5).

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.