Contamination de domaine

Date : 27 Février 2006

Ce mois-ci un article intéressant d'Amit Klein a été présenté par le "Web Application Security Consortium", sur les possibilités de prolonger une attaque de prise de contrôle d'un site web, après que son propriétaire légitime en ait repris le contrôle.

Attaque de départ

Le cas que nous nous proposons d'étudier est un scénario dans lequel un pirate prend temporairement le contrôle d'un site web, en proposant un page d'accueil personnalisée à la place du site web légitime.
Différentes techniques permettent des attaques de ce type :

  • Le "Cyber-squatting" où l'attaquant réserve un nom de domaine qu'il cède ensuite (en échange d’une contre-partie financière le plus souvent).
  • Le détournement de domaine ou "Domaine hijacking" via une pollution de cache DNS, ou un piratage de serveur DNS.
  • Le "Défacement" où l'attaquant est capable de modifier la page d'accueil du site sur le serveur lui-même.
  • La pollution de cache web ou "Web cache poisoning" où l'attaquant est capable de placer sa version de la page d'accueil du site, dans la mémoire cache d'un équipement (un serveur de relayage par exemple).

Prolongement de l'attaque

Cet article se propose de montrer qu'il existe des possibilités de prolonger ces attaques après que leurs victimes aient repris le contrôle de leurs sites web.

Principe :

Le principe est très simple : pendant que le site web est sous son contrôle, le pirate propose sa version de la page d'accueil, de manière à ce qu'elle soit conservée le plus longtemps possible dans la mémoire-cache des navigateurs, ou des serveurs de relayage ("proxy") qu'elle traverse.
En effet, même après que la victime ait repris le contrôle de son site, tant que la page piratée est encore dans la mémoire cache de navigateurs ou de "proxy", c'est elle qui est servie aux Internautes utilisant ces équipements.

Conséquences :

L'attaquant peut alors, via un script activé dans la page malveillante stockée en mémoire cache, effectuer des actions malicieuses tout en en redirigeant les internautes victimes vers la page web légitime, afin qu'ils ne se rendent compte de rien. Les actions suivantes sont possibles :

  • Vols d'informations confidentielles en lisant les cookies relatifs au domaine attaqué.
  • Modification des cookies relatifs au domaine attaqué, avec comme conséquence la possibilité de forcer des identifiants de session, afin de s'immiscer dans les sessions correspondantes.
  • Attaques de type "Man-In-The-Middle" entre les internautes et le domaine attaqué.

Directives HTTP et gestion de mémoire-cache

La gestion des pages web en mémoire cache est contrôlée par des champs d'en-tête du protocole HTTP. Ces champs sont intéressants à étudier pour comprendre la mise en œuvre d'une attaque et les moyens de la contrer.
Ils sont présentés dans le tableau suivant :

Nom Paramètres Description
Cache-Control 'no-cache' Définit la politique de gestion de cache d'une réponse HTTP. La valeur 'no-cache' interdit aux équipements et applications traitant une réponse de la mettre en mémoire-cache, la valeur 'public' autorise tous les  équipements et applications traitant une réponse à la mettre en mémoire-cache
'public'
Expires date Associé à une réponse il indique la date jusqu'à la quelle la ressource fournie par cette réponse est valide (et peut donc rester raisonnablement en mémoire cache)
Last-Modified date Associé à une réponse il indique la date la plus récente à laquelle la ressource fournie par cette réponse a été modifiée.
if-Modified-Since date Permet de faire une requête conditionnelle. Le serveur retourne la ressource demandée uniquement si elle a été modifiée depuis une certaine date, sinon il renvoie le code 304 (Not Modified).
ETag entity tag Associé à une réponse il indique un "entity tag" lié à la ressource fournie par cette réponse.
If-None-Match entity tag Permet de faire une requête conditionnelle. Le serveur retourne la ressource demandée uniquement si son "entity tag" est différent de celui associé à ce champ, sinon il renvoie le code 304 (Not Modified).

Remarques :

  • Lorsqu'une application demande une ressource mise en mémoire cache, et associée à une date passée avec le champ 'Last-Modified', elle peut alors faire une requête "if-Modified-Since", pour s'assurer de mettre à jour la mémoire cache uniquement si cela est nécessaire (ressource modifiée depuis sa mémorisation).
  • Lorsqu'une application demande une ressource mise en mémoire cache, et associée à un "entity tag" passé avec le champ 'ETag', elle peut alors faire une requête "if-None-Match", pour s'assurer de mettre à jour la mémoire cache uniquement si cela est nécessaire (la ressource n'est plus la même que celle mémorisée).
  • Ces champs peuvent être positionnés via les métas tag "HTTP-EQUIV" d'une page HTML.

Mise en oeuvre

Afin que sa page malveillante reste le plus longtemps possible en mémoire cache, un attaquant peut utiliser les champs HTTP suivants lors de l'accès initial à la page piratée :

  • Cache-Control : public
  • Expires : 'date1' (très loin dans le futur)
  • Last-Modified : 'date2' (très loin dans le futur)

En effet, un équipement ou une application recevant une page avec ces directives :

  1. la met en mémoire-cache,
  2. la considère valide jusqu'à la date 'date1',
  3. reçoit un code 304  (Not Modified) en réponse à ses requêtes "If-Modified-Since" tant que cette page n'a pas été modifiée après la date 'date2'.

De plus l'attaquant ne doit pas utiliser de champ "Etag" (entity tag) avec sa page malveillante.

Nota : la longévité de ce type d'attaque dépend de la manière dont est gérée la mémoire des navigateurs ou des "proxy" infectés. Pour les navigateurs il est intéressant de rappeler les possibilités suivantes :

  • rafraîchissement d'une page en mémoire cache par l'utilisateur à l'aide de la commande "Actualiser",
  • réinitialisation de toutes les informations en mémoire cache par l'utilisateur,
  • suppression des informations en mémoire cache lors de l'arrêt du navigateur,
  • configuration du navigateur pour qu'il rafraîchisse les informations en mémoire cache à chaque lancement.

Moyens de défense

Actions préventives

Il est intéressant de rappeler qu'un serveur utilisant HTTPS est mieux protégé contre les prises de contrôle par un attaquant. En effet, l'utilisation du protocole SSL protège des attaques de type "Domaine hijacking" ou "Web cache poisoning".

Afin de renouveler les ressources mémorisées dans les mémoires caches des différents équipements, il semble judicieux qu'un serveur :

  • ne réponde jamais à une requête avec le code 304 (Not Modified) aux requêtes '"if-Modified-Since",
  • gère les dates de modification et les "entity tag" de ses ressources.

Actions post-attaques

Les défenses contre de telles attaques ne sont pas triviales et dépendent de différents paramètres (sophistication de l'attaque, implémentation du serveur, relation avec les utilisateurs, …).
Toutefois, si cela est possible les actions suivantes peuvent être faites :

  • envoyer un e-mail aux internautes clients du site, en leur demandant de cliquer sur un lien vers une nouvelle page du site (donc non mise en mémoire cache), qui active un script provoquant le rafraîchissement de la mémoire cache des différents équipements impactés.
  • faire fermer le site malveillant contacté par la page web malicieuse stockée en mémoire cache.

Remarque : il faut également penser à détruire les cookies laissés par la page web de l'attaquant.


Pour plus d'information :

Précedent Précedent Suivant Suivant Imprimer Imprimer

© 2024 Cert-IST