Donnerstag, 18. Juni 2009


Topthema

Donnerstag, 23. Oktober 2008 | Topthema

About Security #178: Schwachstellen-Suche: Directory-Traversal (2)

(Link zum Artikel: http://www.entwickler.de/entwicklerde/kolumnen/045650)

Angreifer können die in About Security #177 vorgestellten Directory-Traversal-Schwachstellen auf verschiedene Arten ausnutzen. Welche Möglichkeiten sie dabei haben, erfahren Sie ab dieser Folge.

Zurück zum Beispiel

Ausgangspunkt ist weiterhin das schon in About Security #177 verwendete Beispiel

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

Anders als in About Security #177 soll jetzt aber weder die Datei

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

noch einen Variante mit einer Endung wie .txt, .html o.ä. im Verzeichnis anwendung/programm existieren. Der Angreifer kennt aus seiner anfänglichen Untersuchung der Webanwendung alle gültigen Werte für den Parameter daten. Evtl. sind darunter Werte, die sich hoch zählen lassen, z.B. numerische IDs, bekannte Produktbezeichnungen, Datumsangaben, ..., so dass der Angreifer aus dem Vorhandensein von z.B. bericht0108 und bericht0208 auf einen noch nicht verlinkten bericht0308 schließen kann. Schon dadurch ist der Zugriff auf (noch) nicht für die Veröffentlichung bestimmte Informationen möglich.

Quelltext ausgeben lassen

Um weiter zu kommen, fehlen dem Angreifer Informationen über den Aufbau der Webanwendung. Um an die zu gelangen, könnte er zuerst einmal versuchen, folgende URL aufzurufen:

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

Der Webserver führt die Anweisungen in start.asp aus und gibt dabei den Inhalt der über den Parameter daten spezifizierten Datei aus: In diesem Fall ist das der Quelltext der Skriptdatei. Nach dem gleichen Muster kann der Angreifer sich auch alle anderen Skriptdateien anzeigen lassen. Die enthalten meist viele für den Angreifer nützliche Informationen wie z.B. die Zugangsdaten zu einer Datenbank, Verweise auf nachgeladene Konfigurationsdateien oder Informationen über die Programmlogik. Im Beispiel könnte der Angreifer so herausfinden, wo die Datei mit den Zugangsdaten der Benutzer gespeichert ist, um sie dann ausgeben zu lassen (siehe About Security #177).

Datei nicht gefunden

Security aktuell
T�glich aktuelle Security-Infos!

Evtl. wird der Quelltext aber auch nicht ausgegeben, sondern es erscheint eine Fehlermeldung, das die Datei nicht gefunden wurde, oder der Platz für die auszugebenden Daten bleibt leer. Da die Datei eindeutig vorhanden ist, lässt das darauf schließen, das der Wert des Parameters nicht direkt für den Zugriff auf die Datei verwendet wird, sondern zuvor um weitere Daten ergänzt wird. Dafür gibt es 2 übliche Ansätze, die auch gemeinsam auftreten können: Es wird ein fest vorgegebener Pfad und/oder eine fest vorgegebene Endung hinzugefügt.

Eine evtl. angehängte Endung kann oft durch das Anhängen eines Nullbytes (%00) an den Wert des Parameters umgangen werden: Das Nullbyte wird als Ende des Strings mit Pfad und Dateinamen interpretiert, eine evtl. noch folgende, fest kodierte Endung folglich ignoriert. Wird vor den Eingabewert ein fest kodierter Pfad kopiert, kommt es zum eigentlichen Directory Traversal: Durch Eingabe von ../ wird in das übergeordnete Verzeichnis gewechselt. Der Einfachheit halber wird hier immer der Slash / als Pfadtrenner verwendet, Windows-Systeme verwenden ggf. den Backslash \.

Im Beispiel kann das z.B. so aussehen:

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

ergibt wieder die "Datei nicht gefunden"-Meldung oder eine leere Ausgabe, ebenso wie

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

und weitere derartige Versuche. Aber mit

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

erreicht der Angreifer sein Ziel: Der Quelltext der Skriptdatei wird ausgegeben. Darin steht für dieses Beispiel, dass für den Zugriff auf die anzuzeigenden Dateien der Pfad

/webserver/seiten/anwendung/daten/

vor den Wert des Parameters daten kopiert wird. Davon ausgehend, kann der Angreifer nun versuchen, weitere für ihn interessante Dateien ausgeben zu lassen, z.B. die in About Security #177 erwähnten boot.ini oder /etc/passwd:

http://www.server.example/anwendung/programm/start.asp?daten=../../../../boot.ini
http://www.server.example/anwendung/programm/start.asp?daten=../../../../etc/passwd

Benutzernamen und Passwörter für Windows-Systeme lassen sich aus der SAM-Datei oder ihrer Sicherheitskopie ermitteln:

http://www.server.example/anwendung/programm/start.asp?daten=../../../../windows/system32/config/sam
http://www.server.example/anwendung/programm/start.asp?daten=../../../../windows/repair/sam._
Ausführliche Fehlermeldungen erfreuen den Angreifer
About Security: Die komplette Serie

Die mühsame Suche nach der Skriptdatei bleibt dem Angreifer erspart, wenn die Fehlermeldung nicht nur einfach "Datei nicht gefunden" o.Ä. lautet, sondern ausführlicher ist. Häufig gibt es dann Meldungen nach dem Muster

Warnung: Die Datei /webserver/seiten/anwendung/daten/start.asp konnte nicht gelesen werden!

Danach weiß der Angreifer, wo nach der anzuzeigenden Datei gesucht wird, und kann sofort die passende Anzahl ../-Sequenzen und Verzeichnisnamen für den Wechsel in ein gewünschtes Verzeichnis einfügen.

In der nächsten Folge werden weitere mögliche Angriffe beschrieben.

Wenn Sie Fragen oder Themenvorschläge haben, können Sie diese gerne an die angegebene E-Mail-Adresse senden oder im Security-Forum einbringen!

Carsten Eilers

About Security - Übersicht zum aktuellen Thema:

Kommentare

Folgende Links könnten Sie auch interessieren