Depuis novembre 2007, plusieurs vagues d'attaques sensiblement similaires sont menées par injection de code SQL sur les architectures Microsoft IIS / ASP et SQL Server. Cette menace continue aujourd'hui de se réaliser à grande échelle, et plusieurs centaines de milliers de sites ont été, sont ou seront touchés. Concrètement, depuis le début de la semaine dernière, une vague d'attaque semble toucher plus spécifiquement des sites Web de langue française.

Pourquoi une telle ampleur ? Parce que dans ce cas, il s'agit d'une attaque automatisée utilisant les erreurs de développement Web, et non pas de l'exploitation d'une faille de sécurité connue sur un quelconque CMS, qui pourrait être rapidement corrigée par l'application d'un correctif.

Ainsi l'outil mis en Å“uvre pour l'attaque commence par effectuer une recherche sur Google pour identifier des sites potentiellement vulnérables (recherche de la chaine "ASP" dans l'URL par exemple), puis envoie une seule requête contenant le code d'exploitation et la charge utile. La requête SQL ainsi injectée est encodée afin d'éviter des mots-clés SQL connus tels que "SELECT", "UPDATE" ou "UNION". Celle-ci a souvent la forme suivante :
DECLARE%20@S%20NVARCHAR(4000);SET%20@S=CAST(...[requêteencodée] ...%20AS%20NVARCHAR(4000));EXEC(@S);--

Son effet va être de rechercher dans la base de données sous-jacente les champs de type "varchar" afin d'injecter du code Javascript malveillant. Ce code varie au cours des vagues d'attaques, mais est toujours de la forme :
<script src="http://xxxxx/x.js"></script>.

Bien entendu, de nombreux noms de domaine différents sont utilisés pour le dépôt du code malveillant.

Les visiteurs d'un site touché vont donc charger ce script à leur insu. Celui-ci va ensuite tenter d'exploiter diverses vulnérabilités connues, le plus souvent par le biais de contrôles ActiveX vulnérables, afin de provoquer le téléchargement d'un virus, dont le but est notamment de voler des mots de passe.

Compte-tenu de la difficulté de corriger définitivement la vulnérabilité (ce qui nécessite de passer en revue et d'implémenter un contrôle sur l'intégralité des variables utilisées par l'application), la résolution rapide de l'incident va principalement consister à remettre en état la base de données, et à filtrer cette attaque précise, par exemple par le biais d'un reverse proxy applicatif.

Si cette réponse à l'incident est judicieuse à court terme, il faut prendre en compte que les sites attaqués se retrouve référencés temporairement sur les moteurs de recherche, et on peut donc imaginer que d'autres attaquants vont en profiter pour dresser des listes de sites Web vulnérables, afin d'y revenir ultérieurement de manière manuelle ou automatique.

C'est pourquoi il est particulièrement judicieux de mettre en œuvre dès maintenant une démarche de revue du code applicatif, pour pouvoir prévenir tout nouvel incident.