entwickler.com

Außer den in About Security #209 und #210 beschriebenen Default-Inhalten und nicht für die Allgemeinheit gedachten Funktionen gibt es auch HTTP-Methoden, die für einen Angreifer nützlich sein können.

GET und POST sind nur der Anfang

Webserver unterstützen außer den meistgenutzten Methoden GET und POST eine ganze Reihe weiterer Methoden für spezielle Aufgaben. Einige davon können von einen Angreifer für seine Zwecke missbraucht werden, sofern er darauf zugreifen kann.

• PUT dient dem Heraufladen einer Datei an den angegebenen Speicherort
  Ein Angreifer kann darüber z.B. seine eigenen Skript- oder Programmdateien auf dem Server speichern
• DELETE dient dem Löschen der angegebenen Resource
  Ein Angreifer kann darüber z.B. wichtige Inhalte oder störende Konfigurationsdateien löschen
• COPY dient dem Kopieren der angegebenen Resource an den im Destination-Header angegebenen Ort
  Ein Angreifer kann darüber z.B. die Funktion der Webanwendung manipulieren
• MOVE dient dem Verschieben der angegebenen Resource an den im Destination-Header angegebenen Ort
  Ein Angreifer kann darüber z.B. störende Konfigurationsdateien an einen Ort verschieben, an dem sie ihn nicht mehr stören
• SEARCH dient der Suche nach Ressourcen in einem Verzeichnis(pfad)
  Ein Angreifer kann darüber nach ihn interessierenden Dateien suchen
• PROPFIND dient zur Ausgabe von Informationen über die spezifizierte Ressource wie Autor, Größe und Content-Type
  Ein Angreifer kann darüber evtl. für den Angriff nützliche Informationen über Skripte etc. erhalten
• TRACE dient zur Ausgabe des Requests, den der Server empfangen hat
  Ein Angreifer kann darüber z.B. Schutzfunktionen ermitteln und diese evtl. umgehen.

Einige der Methoden gehören zur WebDAV-Erweiterung (Web-based Distributed Authoring and Versioning) des HTTP-Protokolls zum Editieren und Verwalten der auf dem Server bereit gehaltenen Inhalte. Also genau dem, was auch ein Angreifer gerne machen würde.

Welche Methoden für ein bestimmtes Verzeichnis zulässig sind, kann mit der Methode OPTIONS ermittelt werden:

OPTIONS / HTTP/1.0
Host: www.server.example

HTTP/1.1 200 OK
Server: Microsoft-IIS/5.1
Date: Wed, 01 Jul 2009 07:55:52 GMT
X-Powered-By: ASP.NET
MS-Author-Visa: MS-FP/4.0,DAV
Content-Length: 0
Accept-Ranges: none
DASL: <DAV:sql>
DAV: 1, 2
Public: OPTIONS, TRACE, GET, HEAD, DELETE, PUT, POST, 
COPY, MOVE, MKCOL, PROPFIND, PROPPATH, LOCK, UNLOCK, 
SEARCH
Allow: OPTIONS, TRACE, GET, HEAD, COPY, PROPFIND, LOCK,
UNLOCK, SEARCH

Die Antwort zeigt, welche der oben genannten Methoden unterstützt werden. Sie sagt aber nichts darüber aus, ob für ihre Ausführung eine Authentifizierung erforderlich ist oder ob es andere Beschränkungen für ihre Nutzung gibt.

Besonders gefährlich ist die Methode PUT, mit der z.B. eine Skript- oder Programmdatei unterhalb des Webroot-Verzeichnisses gespeichert werden kann. Wenn die PUT-Methode vorhanden und aktiviert ist, kann das mit folgendem Request überprüft werden:

PUT /test.txt HTTP/1.1
Host: www.server.example
Content-Length: 4


test

HTTP/1.1 201 Created

Schwachstellen finden

Um potentiell gefährliche Methoden zu finden, reicht bei der eigenen Webanwendung auf dem eigenen Server ein Blick in dessen Konfiguration. Bei einem unbekannten Server müssen alle vorhandenen Verzeichnisse mit Hilfe der OPTIONS-Methode auf die vorhandenen Methoden untersucht werden. Alle Verzeichnisse, da für verschiedene Verzeichnisse verschiedene Methoden aktiviert sein können. Für diese Aufgabe gibt es verschiedene Tools, z.B. bruteoptions.py von Marcin Wielgoszewski von ts/sci security oder bruteoptions.c von "C1c4Tr1Z" von voodoo-labs.org.

Werden potentiell gefährliche Methoden gefunden, bedeutet das noch lange nicht, das sie auch vom Angreifer verwendet werden können. Daher müssen alle gefundenen Methoden daraufhin geprüft werden, ob sie wirklich verwendet werden können oder ob für ihre Ausführung eine Authentifizierung erforderlich ist oder ob es andere Schutzmaßnahmen gibt. Der schon öfter erwähnte Paros ist z.B. in der Lage, die PUT-Methode für jedes gefundene Verzeichnis automatisch zu testen.

Sind einige WebDAV-Methoden aktiviert, kann auch ein WebDAV-Client für weitere Tests verwendet werden.

Schwachstellen beheben

Das Beheben der Schwachstellen ist einfach, da nur die Konfiguration des Webservers geändert werden muss: Nicht benötigte Methoden müssen deaktiviert, benötigte durch eine vorgeschaltete Authentifizierung vor unbefugter Nutzung geschützt werden. Der erste Schritt bei aktiviertem WebDAV ist die Frage "Wird WebDAV benötigt?" - wenn nicht, kann es komplett deaktiviert werden, wodurch die davon bereit gestellten Methoden ebenfalls deaktiviert werden.

Eine ziemlich nutzloser Versuch ist das "verstecken" potentiell gefährlicher Methoden durch Deaktivieren der OPTIONS-Methode oder einer Manipulation deren Ausgabe: Ein Angreifer sieht dann zwar nicht auf den ersten Blick, welche Methoden vorhanden sind, auf vorhandene Methoden kann aber trotzdem zugegriffen werden.

In der nächsten Folge geht es weiter um die Sicherheit des Webservers, dann um dessen Missbrauch als Proxy.

Carsten Eilers

About Security - Übersicht zum aktuellen Thema:

• About Security #206: Schwachstellen-Suche: Webserver identifizieren
• About Security #207: Schwachstellen-Suche: Webserver angreifen
• About Security #208: Schwachstellen-Suche: Webserver schützen
• About Security #209: Schwachstellen-Suche: Webserver untersuchen
• About Security #210: Schwachstellen-Suche: Webserver-Konfiguration
• About Security #211: Schwachstellen-Suche: Gefährliche HTTP-Methoden