Mittwoch, 7. Januar 2009 |
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.
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.
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.
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.
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!