Sonntag, 22. April 2012


Topthema

Donnerstag, 13. November 2008 | Topthema

About Security #181: Schwachstellen-Suche: Directory-Traversal (5)

(Link zum Artikel: http://www.entwickler.de/entwicklerde/kolumnen/046026)
  • Teilen
  • kommentieren
  • empfehlen
  • Bookmark and Share

Auch in dieser Folge geht es um die Suche nach Directory-Traversal-Schwachstellen. Ein üblicher Ansatz zur Verhinderung von Directory-Traversal-Angriffen ist das Erkennen und evtl. Ausfiltern der Directory-Traversal-Sequenzen, ein weiterer der Test auf das Vorhandensein bestimmter Suffixe (z.B. Dateiendungen) oder Präfixe (z.B. ein Startverzeichnis) Die Angriffe können aber auf verschiedene Arten kodiert werden, um so die Prüffunktion zu unterlaufen. Welche Möglichkeiten es dafür gibt, erfahren Sie in dieser Folge.

Alle im folgenden beschriebenen Tests lassen sich sehr viel effektiver durchführen, wenn man bei der Schwachstellen-Suche Zugriff auf den Webserver hat. Dann kann bei jeder Eingabe eines Testmusters sofort geprüft werden, ob überhaupt ein Dateiname an das Dateisystem weitergeleitet wird und wenn ja, welcher.

Directory-Traversal-Sequenzen tarnen

Wie schon in About Security #180 beschrieben, ist es immer einen Versuch wert, den Test sowohl mit dem Slash als auch mit dem Backslash durchzuführen. Viele Prüffunktionen prüfen nur auf das Auftreten eines davon, während das Dateisystem unter Umständen beide oder zufällig gerade die nicht geprüfte Variante akzeptiert. Das kann z.B. passieren, wenn der die Eingaben prüfende Teil der Webanwendung auf einen Unix-artigen System läuft, die Dateizugriffe aber auf einem nachgeordneten Windows-System erfolgen bzw. umgekehrt.

Reicht der Austausch nicht, helfen vielleicht andere Kodierungen für die Zeichen . und / bzw. \ beim Umgehen der Prüffunktion. Machmal reicht es aus, die Directory-Traversal-Sequenzen URL-kodiert zu senden, um die Prüffunktion zu umgehen. Das gleiche gilt für doppelte URL-, 16-Bit-Unicode- und überlange UTF-8-Unicode-Kodierung:

Zeichen URL-kodiert doppelt URL-kodiert 16-Bit-Unicode überlanger 8-Bit-Unicode
. %2e %252e %u002e z.B. %c0%2e, %e0%40%ae, ...
/ %2f %252f %u2215 z.B. %c0%af, %e0%80%af, ...
\ %5c %255c %u2216 z.B. %c0%5c, %c0%80%5c, ...

Die überlange UTF-8-Unicode-Kodierung widerspricht zwar den Unicode-Regeln, wird aber trotzdem vom manchen Unicode-Decodern akzepziert.

Filterfunktionen austricksen

Versucht die Webanwendung, gefundene Directory-Traversal-Sequenzen aus der Eingabe zu löschen, ohne diese Filterfunktion rekursiv anzuwenden, kann der Filter evtl. durch eine Verschachtelung mehrerer Directory-Traversal-Sequenzen ausgetrickst werden. Mögliche Eingaben wären dann z.B.

....//
....\/
..../\
....\\
..././
...\./

usw. - am Ende muss nur eine Directory-Traversal-Sequenz mehr in der Eingabe stecken, als die Filterfunktion angewendet wird.

Suffix und/oder Präfix nach Wunsch

Einige Webanwendungen akzeptieren nur Dateinamen mit bestimmten Endungen und verwerfen alle anderen Eingaben. Unter Umständen kann dieser Test ausgehebelt werden, indem an den gewünschten Dateinamen ein URL-kodiertes Null-Byte, gefolgt von einer zulässigen Endung, angehängt wird:

../../../../boot.ini%00.jpg
../../../../etc/passwd%00.jpg

Ein solcher Angriff funktioniert immer dann, wenn die Prüffunktion Nullbytes im Eingabestring akzeptiert, während die Funktion für den Dateizugriff ein Nullbyte als Stringende erkennt und damit auf die gewünschte Datei zugreift.

Eine weitere Möglichkeit ist das Einfügen eines URL-kodierten Newline-Zeichens, %0a, das von manchen Systemen beim Zugriff auf die Datei ebenfalls als Stringende erkannt wird:

Versucht die Webanwendung, die richtige Endung durch Hinzufügen einer eigenen Endung zu erzwingen, kann die Funktion evtl. ebenfalls durch Anhängen von %00 oder %0a an den Dateinamen umgangen werden.

Prüft die Webanwendung, ob der Dateiname mit einem bestimmten Unterverzeichnis beginnt, kann das durch Hinzufügen dieses Unterverzeichnisses und einer entsprechenden Anzahl Directory-Traversal-Sequenzen erreicht werden. Muss der Dateiname z.B. mit den Unterverzeichnissen daten/bilder/ beginnen, muss statt

../../../../boot.ini
../../../../etc/passwd

einfach nur

daten/bilder/../../../../../../boot.ini
daten/bilder/../../../../../../etc/passwd

eingegeben werden.

About Security: Die komplette Serie

Schlagen alle diese Versuche fehl, werden wahrscheinlich mehrere der beschriebenen Schutzfunktionen miteinander kombiniert. Entsprechend müssen auch mehrere der beschriebenen Angriffe kombiniert werden. Um herauszufinden, welche, geht man am besten systematisch vor. Ist z.B. der Zugriff auf

hintergrund.jpg

möglich, nicht aber der auf

gibtsnicht/../hintergrund.jpg

werden der Reihe nach alle möglichen Varianten der Directory-Traversal-Sequenz durchprobiert, bis der Zugriff wieder möglich ist:

gibtsnicht\..\hintergrund.jpg
gibtsnicht/%2e%2e%2fhintergrund.jpg
gibtsnicht/....//hintergrund.jpg

usw.. Danach ist bekannt, wie die Directory-Traversal-Sequenz kodiert werden muss, um die Schutzfunktion zu umgehen. Jetzt kann versucht werden, auf /boot.ini oder /etc/passwd zuzugreifen. Ist das trotz richtiger Kodierung der Directory-Traversal-Sequenz nicht möglich, ist sehr wahrscheinlich zusätzlich eine Prüfung für die Dateiendung vorhanden. Um das zu testen, wird wieder versucht, eine solchen Funktion beim Zugriff auf hintergrund.jpg zu umgehen:

hintergrund.jpg%00.jpg
hintergrund.jpg%0a.jpg

So wird versucht, alle vorhandenen Schutzfunktionen zu umgehen, ohne das von der Webanwendung vorgegebene Startverzeichnis zu verlassen. Sind alle Funktionen bekannt, kann der eigentliche Angriff beginnen und aus dem Startverzeichnis ausgebrochen werden.

In der nächsten Folge erfahren Sie, wie Sie Directory-Traversal-Schwachstellen verhindern können.

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