Attaque de type "HTTP Request Smuggling"

Date :27 Juillet 2005

Publication: Article

Dans le bulletin d'octobre 2004 du Cert-IST, nous vous avions présenté les attaques de type "HTTP Response Splitting". Ces attaques consistent à injecter des données malicieuses dans les en-têtes des réponses HTTP, de façon à détourner les transactions web. Typiquement ces attaques permettent de corrompre un cache web, ou de voler des données utilisateurs (par exemple les cookies de session).

 Amit Klein, l'auteur de l'étude sur le "Response Splitting" a publié début juin, avec 3 autres chercheurs, une nouvelle étude qui explore en détail d'autres manipulations malicieuses des en-têtes HTTP. Cette fois, ce sont les requêtes (plutôt que les réponses) qui sont disséquées, pour produire des attaques baptisées "HTTP Request Smuggling". Nous traduisons ce terme par "Dissimulation de requêtes HTTP", car "smuggling" signifie mot à mot "contrebande".

Ces attaques s'appliquent dans le cas (très classique) où une requête web traverse un équipement amont avant de parvenir au serveur web (par exemple un "serveur cache", ou un garde-barrière effectuant de l'inspection HTTP). L'attaque consiste alors à construire des requêtes malicieuses qui seront interprétées différemment par l'équipement amont et par le serveur web. L’attaquant cherche ainsi à dissimuler à l'équipement amont les requêtes HTTP réellement traitées par le serveur web.

 Pour illustrer les principes de cette technique, nous reprenons la première attaque présentée dans l'étude. Considérons donc les données HTTP suivantes :

 1 POST http://SITE/foobar.html HTTP/1.1
 […]
 5 Content-Length: 0
 6 Content-Length: 44
 7
 8 GET /poison.html HTTP/1.1
 9 Host: SITE
10 Bla: [space after the "Bla:", but no CRLF]
11 GET http://SITE/page_to_poison.html HTTP/1.1
12 Host: SITE
13 Connection: Keep-Alive
14 [CRLF]

 Dans cette attaque, une anomalie a été sciemment introduite dans la requête "POST", en insérant deux champs "Content-Length". 

Selon l'étude :

  • Le serveur web "SunOne WebServer 6.1" prend en compte le premier des deux "Content-Length". Il considérera donc qu'il y a deux requêtes successives : un "POST", suivi d'un "GET poison.html", et retournera la page "poison.html" (la requête en ligne 11 sera ignorée et considérée comme la valeur associée à l'en-tête "Bla:".
  • Le serveur cache "SunOne Proxy 3.6" prend lui en compte le deuxième champ "Content-Length". Il considérera donc qu'il y a deux requêtes successives : un "POST", suivi d'un "GET http://SITE/page_to_poison.html" (ce GET débute 44 caractères après la fin de l'en-tête). Il placera dans son cache la réponse retournée par le serveur web, pour la renvoyer automatiquement dès qu'un internaute demandera à accéder à cette page.

L'injection de deux champs "Content-Length" a donc permis de corrompre le cache web : désormais, à chaque fois que l'on demande à consulter la page "page_to_poison.html", c'est en réalité la page "poison.html" qui est renvoyée.

L'étude identifie 6 types d'anomalies HTTP qui peuvent être utilisées pour réaliser le même type d'attaque :

  1. Insertion dans la même requête de deux champs "Content-Length" (c'est l'exemple donné ci-dessus).
  2. Insertion dans la même requête d'un champ "Transfer-Encoding: chunked" et d'un champ "Content-Length" (ce qui n'a pas de sens sémantiquement).
  3. L'insertion d'un double "Retour-chariot" dans un en-tête HTTP.
  4. L'ajout d'un champ "Content-Length" non nul à une requête "GET".
  5. L'utilisation d'un champ d'en-tête HTTP débutant par un blanc.
  6. L'utilisation de requêtes "POST" avec plus de 48 Ko de données.

Pour ces six cas, les auteurs ont réalisé des tests qui ont montré que les équipements traitaient ces anomalies de façon non cohérente (tous les équipements n'ont pas la même interprétation). Leur étude donne une liste (non exhaustive) de 25 couples "équipement amont" ("relais ou garde-barrière") et "serveur web", où des anomalies se produisent. Voici les "équipements amonts" cités (se reporter à l'étude pour obtenir le détail des couples) :

    • "PCCA" : il s'agit d'un acronyme (signifiant "Popular Commercial Cache Appliance") utilisé pour cacher l'identité réelle du produit affecté …
    • Squid 2.5
    • Apache 2.0.45
    • Microsoft ISA/2000
    • DeleGate 8.9.2
    • Oracle9iAS cache server
    • SunONE proxy server 3.6
    • CheckPoint FW-1 Web Intelligence 55W

L'étude donne enfin des exemples d' attaques que le "HTTP request smuggling" peut permettre de réaliser :

  • corruption de cache web,
  • contournement d'un garde-barrière contrôlant le flux http,
  • vol de cookies, ou de données d'authentification.

Globalement l'étude paraît très aboutie. Les techniques présentées sont complexes, mais elles sont illustrées d'exemples très détaillés montrant des cas réels d'attaques. On peut donc craindre qu'elles servent dans le futur à réaliser des attaques :

  • Soit pour corrompre des caches web. Ce type d'attaque devient de plus en plus "populaire". Elle peut permettre en particulier de réaliser des attaques de type "pharming", telles que présentées dans notre bulletin de mars 2005.
  • Soit pour voler des identifiants/authentifiants utilisateurs (attaques de type "Cross-Site Scripting").

L'étude mentionne que des correctifs pour certains de ces problèmes ont été apportés pour les produits SQUID et CheckPoint FW-1. La version "Alpha" de Apache 2.1 contient également une correction de ce type (mais ce correctif ne sera apparemment pas porté sur les branches 1.3 et 2.0).
 

Nota : L'anomalie "Transfer-Encoding: chunked" a donné lieu à la publication de 7 références CVE, correspondant aux 7 produits suivants considérés comme vulnérables à cette attaque :

  • CAN-2005-2088 (Apache)
  • CAN-2005-2089 (MS IIS)
  • CAN-2005-2090 (Tomcat)
  • CAN-2005-2091 (WebSphere)
  • CAN-2005-2092 (WebLogic)
  • CAN-2005-2093 (Oracle)
  • CAN-2005-2094 (Sun ONE)

Le Cert-IST a émis sur cette anomalie l'avis CERT-IST/AV-2005.276
 

Pour plus d'information :
 

Etude "HTTP Request Smuggling" :
http://www.watchfire.com/resources/HTTP-Request-Smuggling.pdf
 

Annonce de la prise en compte de ce problème par Apache :
 http://www.apache.org/dist/httpd/Announcement21.html