entwickler.com

Das in About Security #17 beschriebene HTTP Request Smuggling erlaubt auch die Täuschung von Firewalls und Intrusion-Detection- bzw. Prevention-Systemen. Wie das funktioniert, erfahren Sie in dieser Folge.

Täuschen der Firewall

Check Points Firewall FW-1 (FP4-R55W Beta) prüft eingehende HTTP-Requests auf vielfältige Weise, um mögliche Angriffe zu erkennen. Dazu werden gespeicherte Signaturen unerwünschter Aktionen mit den HTTP-Requests verglichen. Durch HTTP Request Smuggling können diese Schutzfunktionen umgangen werden.

Folgendes Beispiel (nach dem in About Security #17 erwähnten Whitepaper von Watchfire (PDF) basiert auf einem IIS-5.0-Webserver, der von einer FW-1-Firewall geschützt wird. Der IIS enthält einen Fehler bei der Verarbeitung von POST-Requests mit sehr langem Body: Nach 48 KByte (49152 Bytes) wird der Body abgeschnitten, wenn der Content-Type des Request nicht vom erwarteten Typ ist. Empfängt der IIS z.B. einen POST-Request für eine .asp-Seite mit einer Body-Länge von 48 KByte + x Byte ohne passenden Content-Type, werden die x Bytes als neuer Request betrachtet, während die FW-1 sie als Bestandteil des Body betrachtet.

Im Folgenden soll /seite.asp eine .asp-Seite auf dem Webserver sein. Die folgenden Requests werden über die FW-1-Firewall an den IIS-Webserver gesendet:

 1 POST /seite.asp HTTP/1.1
 2 Host: test 
 3 Connection: Keep-Alive
 4 Content-Length: 49223
 5 [CRLF]
 6 aaa...aaa [49151 mal "a"]
 7 POST /seite.asp HTTP/1.0
 8 Connection: Keep-Alive
 9 Content-Length: 36
 10 [CRLF]
 11 POST /seite.asp HTTP/1.0
 12 Wegdamit: 
 13 POST /seite.asp?cmd.exe HTTP/1.0
 14 Connection: Keep-Alive
 15 [CRLF]

Jede Zeile mit Ausnahme der zwölften endet mit einem CRLF ("\r\n"). In Zeile 12 befindet sich ein Leerzeichen hinter Wegdamit:, aber kein CRLF.

Die FW-1-Firewall parst diese Requests folgendermaßen: Der erste Request hat eine Content Length von 49.223 Bytes. Zeile 6 (49.151 mal a) und Zeile 7–10 (insgesamt 72 Bytes) werden als Body des ersten Request betrachtet. Als Zweites wird der Request ab Zeile 11 geparst. Das POST in Zeile 13 wird wegen des fehlenden CRLF in Zeile 12 als Wert des dortigen Wegdamit:-Headers betrachtet. Der zweite Request endet daher mit Zeile 15. Die Firewall würde das Muster cmd.exe in Zeile 13 als Nimda-Wurm erkennen, wenn es Bestandteil eines URL wäre. Da es hier aber als Teil des Headers betrachtet wird, wird es nicht erkannt. Daher wird cmd.exe durch die Firewall geschmuggelt.

Der IIS-Webserver parst den ersten Request als POST-Request für eine .asp-Seite. Da der Request nicht den erwarteten Content-Type: application/x-www-form-urlencoded-Header enthält wird der Body nach 49.152 Bytes beendet. Der zweite Request beginnt daher in Zeile 7 und hat eine Content-Length von 36 Bytes. Als Body werden die Zeilen 11 und 12 betrachtet. Die Zeilen 13–15 werden danach als dritter Request geparst, sodass das cmd.exe durch die FW-1-Firewall zum IIS-Webserver geschmuggelt wurde. Genauso können andere bösartige URLs durch die Firewall geschmuggelt werden.

Zuletzt noch eine Übersicht über die geparsten Header:

Die Schwachstelle in FW-1 wurde von Check Point behoben.

Weitere Angriffsmöglichkeiten

Außer den bisher vorgestellten Möglichkeiten für HTTP Request Smuggling hat Watchfire weitere Anomalien gefunden, die für einen Angriff ausgenutzt werden können (Quelle wie oben):

• Bei Requests mit zwei Content-Length-Headern werden von verschiedenen Servern nicht dieselben Header verwendet (Beispiele in About Security #17 und #18).
• Von einem als HTTP-Proxy eingesetzten Apache vor Version 2.1.6 wurden bei Requests, die sowohl einen Transfer-Encoding: chunked-Header als auch einen Content-Length-Header enthalten, die verschiedenen Body-Teile zu einem Body zusammengesetzt. Es wurde aber weder ein eigener Content-Length-Header hinzugefügt noch ein bereits vorhandener Content-Length-Header angepasst oder gelöscht.
• Eine Header-Zeile mit einem einzelnen CR, gefolgt von einem CRLF, wird von manchen Servern als HTTP-Header-Zeile betrachtet, während andere darin das Ende des Headers erkennen. Zusammen mit unterschiedlichen Interpretationen von Leerzeichen im Header können die Angriffe durchgeführt werden.
• Bei GET-Requests mit Content-Length-Header wird vom DeleGate-Cache-Server kein Body verarbeitet, während manche Webserver einen erwarten.
• CRLF Leerzeichen CRLF werden von der Check Point FW-1 und Squid in bestimmten Fällen als eine Fortsetzung des vorhergehenden Headers angesehen, während der IIS 5.0 darin das Ende des Headers erkennt.
• Wie bereits im obigen Beispiel gezeigt, schneidet der IIS bei einem sehr langen Body ohne passenden Content-Type-Header den Body bei 49.152 Bytes ab.

Nachdem Sie nun wissen, was HTTP Request Smuggling ist und welche Angriffe darüber möglich sind, geht es in der nächsten Folge um das Erkennen und Verhindern des HTTP Request Smuggling.

Carsten Eilers

About Security – Übersicht zum aktuellen Thema "Sichere Webanwendungen"

• About Security #11: SQL Injection
• About Security #12: SQL Injection verhindern
• About Security #13: Mit Stored Procedures gegen SQL Injection
• About Security #14: Cross-Site Scripting
• About Security #15: Cross-Site Scripting verhindern
• About Security #16: Skriptcode einschleusen
• About Security #17: HTTP Request Smuggling
• About Security #18: Spielarten des HTTP Request Smuggling, 1
• About Security #19: Spielarten des HTTP Request Smuggling, 2
• About Security #20: HTTP Request Smuggling erkennen und verhindern
• About Security #21: HTTP Response Splitting, 1
• About Security #22: HTTP Response Splitting, 2
• About Security #23: Caches vergiften
• About Security #24: Caches indirekt vergiften
• About Security #25: Entführen von Webseiten
• About Security #26: Gefahren für Webanwendungen
• About Security #27: Gefahren für Webserver
• About Security #28: Standorte für Webserver