Bei der Suche nach Schwachstellen in Webanwendungen geht es ab dieser Folge um Schwachstellen, die den Zugriff auf normalerweise nicht zugängliche Dateien erlauben. Den Anfang macht dabei die Directory-Traversal-Schwachstelle.

Einführung

Jede Webanwendung besteht aus mehr oder weniger vielen verschiedenen statischen oder dynamisch erzeugten Seiten, die vom einem Webserver an den Benutzer ausgeliefert werden. Dabei sind die Seiten im wesentlichen Dateien auf dem Server, die vom Webserver und der Webanwendung beim Aufruf ggf. mit dynamischen Inhalten erweitert und dann ausgeliefert werden. Da nicht alle auf dem Server gespeicherten Dateien für den Aufruf durch den Benutzer gedacht sind, ist der Webserver auch dafür zuständig, nur die für die Benutzer vorgesehenen Dateien auszuliefern und Zugriffe auf alle anderen Dateien zu unterbinden. Dazu werden die Dateien im wesentlichen in zwei Kategorien unterteilt: Zum einen die für die Ausgabe an den Benutzer bestimmten Dateien, die in einem eigenen Verzeichnis und dessen Unterverzeichnissen gespeichert sind, und zum anderen alle anderen Dateien, die außerhalb dieses sog. Webroot-Verzeichnisses gespeichert sind. Ein Spezialfall sind dabei Dateien, die zwar unterhalb des Webroot-Verzeichnisses gespeichert sind, auf die aber nur bestimmte Benutzer zugreifen dürfen.

Verzeichnis wechsle dich

Bei einem Directory-Traversal-Angriff ermittelt der Angreifer den Speicherort eines für ihn eigentlich nicht zugänglichen Verzeichnisses oder einer eigentlich nicht zugänglichen Datei und greift dann darauf zu. Je nach Art der Datei können die Folgen von der Preisgabe sensitiver Informationen (Zugriff auf z.B. eine Datei mit Zugangsdaten) bis zur Ausführung unerwünschten Codes (Zugriff auf ein Programm oder eine Skriptdatei) reichen.

Wo angreifen?

Ein Directory-Traversal-Angriff kann am einfachsten durch eine Änderung der URL in der Adresszeile des Browsers des Angreifers erfolgen. Weitere Angriffspunkte sind Parameter, die von der aktuellen Seite einzubindende Dateien wie z.B. Header, Footer oder Erweiterungen festlegen. Diese Parameter können wieder überall gespeichert sein: Als GET-Parameter in der URL, als POST-Parameter in einem evtl. versteckten Eingabefeld oder als Cookie-Wert.

Direkte Zugriffe

Für die folgenden Beispiele soll sich die Webanwendung im Verzeichnis /anwendung/programm befinden, Daten wie z.B. eine Datei mit den Zugangsdaten der Benutzer befindet sich im Verzeichnis /anwendung/daten. Ein normaler Benutzer ruft z.B.

http://www.server.example/anwendung/programm/start.asp

auf, um die Webanwendung zu starten. Der Angreifer könnte z.B. über

http://www.server.example/anwendung/programm/../daten/benutzer.dat

oder

http://www.server.example/anwendung/daten/benutzer.dat

auf die Datei mit den Zugangsdaten der Benutzer zugreifen. Ist der Webserver entsprechend konfiguriert, gibt er daraufhin die angeforderte Datei an den Angreifer aus. Wurde beim Entwickeln der Webanwendung darauf geachtet, das ein Benutzer nicht auf die Dateien im Verzeichnis /anwendung/daten und/oder solche mit der Endung .dat zugreifen kann, geht der Angreifer leer aus.

Ausgabe über ein Programm

Das Skript start.asp soll nun einen Parameter erhalten, über den vor der Ausgabe einzufügende Daten festgelegt werden:

http://www.server.example/anwendung/programm/start.asp?daten=impressum

zeigt dann z.B. das Impressum der Website an. Vielleicht gibt es ja eine Datei impressum, impressum.html oder ähnlich im gleichen Verzeichnis? Im Beispiel soll die entsprechende Datei in der Tat vorhanden sein und der Einfachheit halber impressum heißen: Beim Aufruf von

http://www.server.example/anwendung/programm/impressum

werde die Daten des Impressums ausgegeben, aber unformatiert und ohne das Aussehen der anderen Seiten der Anwendung. Das Skript start.asp wandelt also (Text-)Dateien in optisch am die Anwendung angepasste Webseiten um. Ob das Skript weitere Funktionen hat, ist zur Zeit uninteressant. Was passiert denn, wenn für den Parameter daten eine andere Datei als die im Rahmen der Anwendung üblichen angegeben wird? Ein Standardbeispiel für solche Fälle ist für Windows-Systeme die Datei boot.ini und für Unix-artige Systeme die Datei /etc/passwd, die zwar keine Passwörter mehr enthält, aber immerhin noch die Liste der existierenden Benutzer. Jetzt versuchen wir es aber erst mal eine Nummer kleiner und geben uns mit der Benutzerdatenbank der Webanwendung zufrieden:

http://www.server.example/anwendung/programm/start.asp?daten=../daten/benutzer.dat

führt entweder zu einer Fehlermeldung (prima, die Anwendung ist zumindest an dieser Stelle nicht angreifbar), oder zur Ausgabe der Zugangsdaten der Benutzer. Je nachdem, ob das Skript den Zugriff auf Dateien und/oder Verzeichnisse einschränkt, kann darüber also jede beliebige Datei angezeigt werden.

Welche Möglichkeiten sich einem Angreifer durch die Ausnutzung einer Directory-Traversal-Schwachstelle eröffnen erfahren Sie in der nächsten Folge.

Carsten Eilers