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 :
- la met en mémoire-cache,
- la considère valide jusqu'à la date 'date1',
- 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 :
