Donnerstag, 30. August 2012


Topthema

Donnerstag, 25. August 2005 | Topthema

About Security #20: HTTP Request Smuggling erkennen und verhindern

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

Was HTTP Request Smuggling ist und was ein Angreifer damit erreichen kann, wissen Sie inzwischen. In dieser Folge erfahren Sie, wie man HTTP Request Smuggling erkennen und verhindern kann.

Wie in den letzten Folgen zu sehen war, kann man die Angriffe z.B. an doppelten Headern mit unterschiedlichen Werten erkennen. Das Problem dabei: Die Firewall bzw. das Intrusion-Detection-/Prevention-System bekommt diese Header unter Umst�nden gar nicht in diesem Zusammenhang zu sehen. Also muss nach einer anderen Methode gesucht werden, um die Angriffe zu erkennen.

N E U ! Security aktuell
T�glich aktuelle Security-Infos!

HTTP Request Smuggling erkennen

Amit Klein hat ein Verfahren beschrieben, das die Angriffe auf TCP-Ebene erkennen kann. Das Verfahren nutzt das TCP-PSH-Bit und -PUSH-Flag. Laut RFC 793, in dem das Transmission Control Protocol definiert wird, haben diese folgende Bedeutung: Die push-Funktion stellt sicher, dass alle �bergebenen Daten sofort �bertragen werden. Wird das PUSH-Flag in einem SEND-Aufruf gesetzt, werden alle Daten des aktuellen Aufrufs und der vorhergehenden Aufrufe sofort an den Empf�nger �bertragen. Realisiert wird dies durch das PSH-Bit im TCP-Header.

RFC 793 schreibt vor, dass das Socket API die M�glichkeit bietet, das PSH-Bit �ber das PUSH-Flag in der SEND-Funktion zu setzen und entsprechend in der RECEIVE-Funktion abzufragen. Bei der Beschreibung der Communication Layer in RFC 1122 wurde dies jedoch als optional definiert. Tats�chlich sehen die aktuellen Sockets-Implementierungen, die Unix BSD Sockets und Winsock, das PUSH-Flag weder in der SEND- noch in der RECEIVE-Funktion vor. Daher wird gem�� RFC 1122 das PSH-Flag im letzten gepufferten TCP-Segment (IP-Paket) jedes Aufrufs automatisch gesetzt. Dadurch kann durch Pr�fen der TCP-Header festgestellt werden, ob in mehreren Segmenten empfangene Daten in einem einzelnen Aufruf (= Das PSH-Bit ist nur im letzten Segment gesetzt) oder mehreren Aufrufen (= Das PSH-Bit ist in jedem Segment gesetzt) gesendet wurden. Dies kann man zur Erkennung von Angriffen ausnutzen, wenn zwei Anforderungen erf�llt sind.

Anforderungen zum Erkennen von HTTP Response Splitting (mehr dazu in der n�chsten Folge):

  • Kein 'Pipelining': Eine zweite HTTP-Response darf erst akzeptiert werden, wenn die erste vollst�ndig verarbeitet und ein zweiter HTTP-Request vollst�ndig empfangen wurde. Praktisch bedeutet dies, dass ein Paket mit Daten der ersten Response keine weiteren, �berfl�ssigen Daten enthalten darf.
  • Aus der ersten Anforderung folgt, dass das Ende der ersten Response mit dem Ende eines Pakets und einer �bertragung �bereinstimmen muss. Daher muss das entsprechende Paket ein gesetztes PSH-Bit enthalten.

Um HTTP Request Smuggling zu erkennen, muss der Webserver die vom Proxy-Server empfangenen Requests daraufhin pr�fen, ob ihr Ende mit dem eines Pakets �bereinstimmt und ob in diesem Paket das PSH-Bit gesetzt ist. Wird ein Angriff erkannt, kann die TCP-Verbindung beendet und damit der Angriff abgewehrt werden.

About Security: Die komplette Serie

Das Verfahren schl�gt fehl, wenn Systeme zwischen Web- und Cache-Server den TCP-Stream ver�ndern oder ein beteiligtes System in jedem Paket das PSH-Bit setzt. Dies trifft z.B. auf den TCP-Stack von IBMs TPF 4.1 in der Default-Konfiguration zu.

HTTP Request Smuggling verhindern

Um HTTP Request Smuggling vollst�ndig unm�glich zu machen, m�ssten alle HTTP nutzenden Ger�te den HTTP-Standard gleich umsetzen. Da dazu alle unterschiedlichen Interpretationen auf einen Nenner gebracht werden m�ssten, ist mit dieser L�sung vorerst nicht zu rechnen. Also m�ssen andere Gegenma�nahmen ergriffen werden.

Das oben beschriebene Verfahren ist gut zum Einsatz in Intrusion-Detection- oder -Prevention-Systemen geeignet. Es muss lediglich der TCP/IP-Verkehr belauscht und jeder HTTP-Request und jede HTTP-Response, die nicht an einer Paketgrenze mit gesetzten PSH-Bit im Paket enden, aussortiert werden.

Befinden sich Cache- und Webserver am gleichen Ort, kann eine Kombination gew�hlt werden, die nicht f�r HTTP Request Smuggling anf�llig ist. Dies sch�tzt nat�rlich nicht davor, dass ein vorgelagerter Cache-Server angegriffen bzw. f�r einen Angriff ausgenutzt wird. Eine Firewall vor dem Cache- und/oder Webserver kann vor einem Teil der Angriffe sch�tzen, ist selbst jedoch in manchen F�llen ebenfalls angreifbar. Au�erdem kann die Firewall nat�rlich nur vor Angriffen auf hinter ihr liegende Server sch�tzen.

Die Verwendung eines Webservers, der die HTTP-Requests sehr strikt parst, kann ebenfalls vor Angriffen sch�tzen. Der Apache war z.B. nur in einem � inzwischen behobenen � Fall f�r HTTP Request Smuggling anf�llig, wenn er sowohl als Web- als auch als Cache-Server eingesetzt wurde.

Dass bekannte Schwachstellen behoben und die entsprechenden Patches bzw. Updates installiert werden m�ssen, sollte selbstverst�ndlich sein. Die von Watchfire gefundenen Schwachstellen (PDF) in Squid, der Checkpoint Firewall FW-1 und dem Apache-Webserver wurden inzwischen behoben. Allerdings bleiben noch genug verwundbare Kombinationen �brig, die auch noch nicht alle untersucht wurden.

Damit ist die Beschreibung der durch HTTP Request Smuggling m�glichen Angriffe und ihrer Abwehr abgeschlossen. In der n�chsten Folge geht es um das damit verwandte HTTP Response Splitting.

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 "Sichere Webanwendungen"

Kommentare

Folgende Links könnten Sie auch interessieren