Was Directory-Traversal-Schwachstellen sind und was ein Angreifer durch ihre Ausnutzung erreichen kann, erfuhren Sie in About Security #177, #178 und #179. Ab dieser Folge geht es um die Suche nach diesen Schwachstellen.

Mögliche Angriffspunkte ermitteln

Schon beim Sammeln von Informationen über die Webanwendung wurden die Parameter ermittelt, über die Dateien herauf- oder heruntergeladen werden können. Typische Beispiele dafür sind Parameter für das Heraufladen von Bildern, z.B. für Avatare, Bildergalerien, Auktionen oder das Herunterladen von Informationen, z.B. Anleitungen, Geschäftsberichte, Vorlagen.

Weitere mögliche Angriffspunkte sind alle Parameter, die eine einzubindende oder anzuzeigende Datei spezifizieren oder allgemein den Schluss nahe legen, dass darüber auf das Dateisystem und nicht auf eine Datenbank zugegriffen wird.

Die am Anfang der Schwachstellensuche gesammelten Informationen müssen daher nach Requests durchsucht werden

• die anscheinend einen Parameter mit einer Datei oder einem Verzeichnis als Wert enthalten, z.B. language=deutsch, include=daten/impressum.dat oder template=/template/de/standard
• die Informationen anfordern, die üblicherweise im Dateisystem und nicht in einer Datenbank gespeichert werden, wie z.B. Word- und PDF-Dateien, Bilder oder Programmdateien

Hat man bei der Untersuchung der Webanwendung Zugriff auf den Webserver, können auch alle Zugriffe auf das Dateisystem protokolliert werden, um entsprechende Parameter zu ermitteln. Dazu wird ein entsprechendes Tool wie z.B. ltrace/strace für Linux verwendet, um die Dateizugriffe zu überwachen, während für jeden Parameter (einem nach dem anderen) ein eindeutiger String wie z.B. traversaltest eingegeben wird. Dabei müssen alle Parameter berücksichtigt werden, egal ob sie über GET- oder POST-Requests oder Cookies übertragen werden, egal ob es sich um offensichtliche URL-Parameter oder versteckte Formularfelder handelt. Bei jedem Dateizugriff, in dem der Teststring auftaucht, muss der entsprechende Parameter auf die Anfälligkeit für Directory-Traversal-Angriffe getestet werden.

Liegt der Quelltext der Webanwendung vor, entweder weil es die eigene ist oder es sich um Open-Source-Software handelt, vereinfacht das die Suche, da dann darin nach den entsprechenden Funktionsaufrufen gesucht werden kann.

Verdächtige Parameter prüfen

Nachdem alle möglicherweise für Directory-Traversal-Angriffe anfälligen Parameter identifiziert wurden, müssen sie daraufhin geprüft werden, ob Benutzereingaben ungeprüft und ungefiltert für die Dateisystemaufrufe verwendet werden. Die entscheidende Frage dabei ist, ob die Directory-Traversal-Sequenzen ../ bzw. ..\ ausgefiltert oder durchgereicht werden.

Im folgenden soll der zu untersuchende Parameter datei heißen, für den ein gültiger Wert daten/impressum.txt ist:

machwas.cgi?datei=daten/impressum.txt

Der einfachste erste Test besteht dabei darin, ein beliebiges, nicht notwendigerweise existierendes, Unterverzeichnis, gefolgt von einer Directory-Traversal-Sequenz, einzufügen:

machwas.cgi?datei=daten/gibtesnicht/../impressum.txt

Der Zugriff ist bei den meisten Dateisystemen auch dann möglich, wenn das Unterverzeichnis gibtesnicht gar nicht existiert. Das liegt daran, das der Pfad vor dem Zugriff darauf kanonisiert wird und dabei die Directory-Traversal-Sequenz das nicht vorhandene Verzeichnis aufhebt.

Verhält sich die Webanwendung bei Eingabe des Testmusters genau so wie bei Eingabe des richtigen Parameters, kann sie angreifbar sein. Als nächster Test wird versucht, aus dem Startverzeichnis auszubrechen. Dazu kann geprüft werden, ob wie in About Security #177 und #178 beschrieben auf die Dateien boot.ini oder /etc/passwd zugegriffen werden kann. Dabei kann ausgenutzt werden, das über die Wurzel des Dateisystems hinaus führende Directory-Traversal-Sequenzen von den meisten Dateisystemen toleriert werden (siehe About Security #179).

Da Windows-Systeme sowohl Slash als auch Backslash als Pfadtrenner akzeptieren (Unix-artige Systeme akzeptieren dagegen i.A. nur den Slash), sollten im Zweifelsfall immer beide Varianten ausprobiert werden. Auch wenn der Webserver unter einen Unix-artigen System läuft ist nicht auszuschließen, das die Webanwendung auch auf eine unter Windows laufende Komponente zurückgreift

Verhält sich die Webanwendung bei Eingabe des Testmusters anders als bei Eingabe des richtigen Parameters, wurde der Directory-Traversal-Versuch erkannt und der Parameter entweder vollständig verworfen oder der Pfad so bereinigt, dass er ungültig wurde. In diesem Fall muss als nächstes versucht werden, die Prüffunktion und/oder die Filterfunktion auszutricksen.

Der übliche Ansatz zur Verhinderung von Directory-Traversal-Angriffen ist das Erkennen und Ausfiltern der Directory-Traversal-Sequenzen. Die können aber auf verschiedene Arten kodiert werden, um so die Prüffunktion zu unterlaufen.

Welche Möglichkeiten es dafür gibt und wie man solche Angriffe erkennt, erfahren Sie in der nächsten Folge.

Carsten Eilers

About Security - Übersicht zum aktuellen Thema:

• About Security #177: Schwachstellen-Suche: Directory-Traversal
• About Security #178: Schwachstellen-Suche: Directory-Traversal (2)
• About Security #179: Schwachstellen-Suche: Directory-Traversal (3)
• About Security #180: Schwachstellen-Suche: Directory-Traversal (4)