entwickler.com

In dieser Woche geht es um eine weitere Möglichkeit des HTTP Request Smuggling, und zwar um die Täuschung von Firewalls und Intrusion-Detection- bzw. Prevention-Systemen.

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 [1, 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 einer 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 ([1, PDF]):

• 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.

Nächste Woche geht es um das Erkennen und Verhindern des HTTP Request Smuggling.

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 (#1): IT-Sicherheit -- Was ist das eigentlich?
• About Security (#2): Angriffsszenarien
• About Security (#3): Eindringlinge abwehren
• About Security (#4): Gefährdung aus der Peripherie
• About Security (#5): Der Pufferüberlauf
• About Security (#6): Ausnutzung von Pufferüberlauf-Schwachstellen
• About Security (#7): Gegenwehr -- Pufferüberläufe verhindern
• About Security (#8): Vorbeugung -- Pufferüberläufe verhindern
• About Security (#9): Sourcecode Audit -- Pufferüberläufe finden
• About Security (#10): Software- Audit -- Schwachstellensuche in Binaries
• 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