"Virus XSS" : Les attaques "XSS" de 3ème génération

Date : 05 Décembre 2005

En octobre 2005, un chercheur ("Wade Alcorn") a publié une étude montrant qu'il est possible d'utiliser une vulnérabilité de type "XSS" ("Cross-Site Scripting") pour propager un virus. La technique "XSS" qu'il utilise pour ce virus n'est pas nouvelle, mais elle est mal connue. Nous l'appelons "attaque XSS de 3ème génération".
Nous présentons ici tout d'abord cette troisième génération d'attaque (en rappelant ce que sont les 2 précédentes), puis nous expliquons comment cette attaque peut permettre de développer un virus.

Attaques XSS

1ère génération : Ce cas s'applique typiquement lorsqu'une vulnérabilité "XSS" existe dans un "forum web". Pour réaliser son attaque, le pirate "poste" sur le forum un article qui contient du code JavaScript caché. Toute personne qui consulte par la suite cet article piégé exécute, sans le savoir, le code JavaScript déposé dans le forum par le pirate. On parle ici souvent d'attaques "XSS" "persistantes",  car le code d'attaque reste accessible tant que l'article piégé n'est pas supprimé du forum (et il se déclenche à chaque fois qu'il est consulté). Les pirates utilisent le plus souvent ces attaques de 1ère génération pour voler les identifiants des utilisateurs du forum et se faire ensuite passer pour eux.

2ème génération : Ce cas s'applique lorsqu'une vulnérabilité "XSS" existe sur une page particulière d'un site web, en dehors de tout espace de partage de données (i.e. en dehors d'un espace de type "forum" comme par exemple les messages d'erreur personnalisés ou non). Cette vulnérabilité peut exister par exemple dans un site web bancaire. Dans ce cas, le pirate envoie un message malicieux (typiquement un e-mail) à un client de cette banque, et l'invite à cliquer sur un lien (inclus dans le message) pour se rendre sur le site bancaire. Ce lien contient en fait un code JavaScript caché qui (du fait de la vulnérabilité XSS) va s'exécuter lorsque la victime arrive sur le site bancaire. On parle ici souvent d'attaque "XSS" "non persistante" parce que l'attaque vise un utilisateur précis, et se déclenche une seule fois. Tout comme pour la première génération, le pirate utilise le plus souvent cette attaque pour voler l'identifiant du client de la banque, et "utiliser" ensuite son compte bancaire.

Nota : la technique d'attaque (e-mail incitant à visiter le site bancaire) est la même que celle utilisée dans le cas d'un "phishing". Dans le cas d'un "phishing" cependant, le pirate va se faire passer pour la banque et demander à l'utilisateur des informations sensibles (son "login" et son "mot de passe"). Dans le cas d'un "XSS", le pirate ne demande rien à sa victime, mais observe (et vole) les données d'authentification au moment ou la victime les fournit à sa banque.

3ème génération : Pour les deux premières générations, le code JavaScript injecté par le pirate effectue une action pré-programmée bien précise et relativement simple : typiquement le vol des cookies (identifiant). Dans le cas de la 3ème génération, le code injecté est plus complexe : il dialogue avec un site web tiers qui va lui indiquer le code qu'il doit exécuter. Cette technique (qui a aussi des utilisations légitimes) est couramment appelée le "remote scripting" et est réalisée techniquement au moyen de tags "IFRAME". L'exemple le plus impressionnant du "XSS de 3ème génération" est le travail réalisé par le projet "proxy XSS". En février 2005, ce projet a en effet publié un code de démonstration dans lequel le code injecté au moyen du XSS reçoit dynamiquement ses ordres d'un serveur "proxy", qui les reçoit lui-même du poste de travail du pirate. Dans ce cas, le navigateur web de l'utilisateur victime du XSS devient un véritable "zombie" qui exécute (au nom de l'utilisateur du navigateur) tout ce que le pirate lui dit de faire.

Virus XSS

Le "virus" proposé par "Wade Alcorn" combine les techniques de la 1ère et la 3ème générations. Il utilise la technique des XSS de 3ème génération (le "remote scripting" au moyen de tags "IFRAME") pour exécuter sur le navigateur de l'internaute un code stocké sur un forum web. Ce code, une fois téléchargé par le navigateur de l'internaute victime, cherche aléatoirement sur Internet de nouveaux forums web présentant une faiblesse XSS de 1ère génération. A chaque fois qu'il en trouve un, il y dépose le code "3ème génération" qui infectera ensuite tous les navigateurs qui visiteront ce forum.

Le virus proposé aujourd'hui est expérimental (il s'agit d'une "preuve de concept") et n'a pas d'action nuisible (il ne fait que se propager). Il s'agit pour le moment d'une "curiosité" qui a plusieurs particularités très intéressantes :

  • il "vit" en symbiose, pour moitié sur les serveurs web infectés (c'est là qu'il est "dormant"), et pour moitié sur le navigateur des internautes qui visitent se serveur web (c'est sur le navigateur web qu'il devient "actif"; il tente de se propager vers d'autres serveurs web, et éventuellement de déclencher des actions nuisibles sur le poste infecté)
  • il s'attaque aussi bien à "Internet Explorer" qu'à "Mozilla" (car il est codé en Javascript), quelle que soit la plate-forme support (Windows, Unix, MacOS)
  • il utilise un vecteur de propagation "moderne" et "universel" : HTTP

On a vu récemment (cf. le ver "Lupper", avis CERT-IST/AV-2005.429) qu'il y avait suffisamment de serveurs PHP mal protégés pour qu'un ver utilisant de "vieilles" failles PHP se propage de manière significative. Or, une grande partie des serveurs PHP sont aujourd'hui utilisés pour héberger des applications de type "forum" (ou des "blogs", ou des galeries photos, etc…). On peut donc légitimement se poser la question : "que se passerait-il si quelqu'un activait un virus XSS la prochaine fois qu'une faille de ce type était découverte dans un forum PHP ?". La réponse est probablement que ce virus se répandrait alors de manière significative, et que l'on passerait alors du stade actuel de "preuve de concept" à l'étape "crise avérée".

La prise en compte systématique des vulnérabilités de type "XSS" (failles souvent jugées "mineures" par les développeurs) nous paraît donc indispensable et urgente.

Pour plus d'informations

Précedent Précedent Suivant Suivant Imprimer Imprimer

© 2024 Cert-IST