Bonjour, ton site semble avoir un problème

"Bonjour, je crois que votre site web à un problème." Régulièrement, j'envoie ce genre de mail à des webmasters pour leur signaler un dysfonctionnement en donnant un maximum d’éléments pour les aider à corriger leur problème.
Malheureusement, les administrateurs ne donnent souvent pas suite car de leur point de vue, leur site fonctionne très bien.

J'ai donc pensé faire un petit récapitulatif ici des points importants à considérer lorsqu'on nous soumet une compromission de site web. Je ne vais pas parler des buts des pirates, qui peuvent être multiples et variés, depuis le message à faire passer jusqu'au commerce (vraisemblablement lucratif) des faux antivirus ou des botnets. Je vais présenter six types de compromissions.

• Le defacing
• l'ajout de sites webs
• l'ajout de pages webs ou répertoires
• l'ajout de javascript dans les pages webs
• la redirection par .htaccess
• et l'ajout de modules apache.

1/ Le defacing n'a absolument rien de furtif, son but en est même l'opposé. Que ce soit pour la glorification personnelle du pirate ou pour la diffusion d'un slogan (généralement politique et souvent opposé à celui du site piraté), il faut que cela se voie. L'administrateur s'en rend généralement très vite compte.

2/ Dans certains cas, le pirate ne cherche pas à utiliser le site pour profiter de sa popularité, mais préfère utiliser ses ressources (disque, réseau). Il va alors ajouter des sites webs en vhosts. De manière intéressante, j'ai pu observer plusieurs noms connus accolés à un nom quelconque, comme par exemple picasa.com.randomname.tld ou facebook.com.anotherrandomname.tld. L'administrateur devra donc consulter le contenu des fichiers de configuration d'apache et vérifier qu'aucun vhost n'est ajouté.

3/ L'ajout de page et de répertoire est à peine moins furtif qu'un defacing mais laisse le site d'origine fonctionner normalement. Pour s'en rendre compte, l'administrateur peut lire ses logs d'accès, consulter le contenu du site, et/ou demander à google l'état de son site (via une recherche site:www.site.tld ou cache:www.site.tld).
J'ai démontré un PoC d'une attaque similaire en utilisant directement la base de données. Un site de forum permettait aux utilisateurs d'enregistrer un avatar et une signature ce qui est courant. Ce qui était faible, c'est qu'il n'y avait aucune restrictions, ni de création de compte (automatisation possible), ni d'accès (par le referer par exemple), ni de taille ou de format de fichiers. Dès lors, il devenait simple de remplir la BdD de toutes les données souhaitées et d'utiliser la bande passante et le stockage de ce site à des fins malveillantes. Curieusement, j'ai rarement vu des attaques de ce genre "IRL", mais une surveillance du contenu et de l'usage de sa base de données n'est pas à exclure.

4/ Pour être encore un peu plus furtif, le pirate peut simplement ajouter un petit javascript dans certaines pages du site. Le site fonctionne toujours, et une vérification rapide du contenu du site ne montre rien d'évident. Il faut donc comparer le site avec une version saine. Et là, le fait de disposer de deux versions du site web (une préprod et une en prod par exemple) peut aider. Une autre méthode consiste à lire le code source des pages webs envoyées par le serveur pour trouver le code malveillant.
Cet ajout de code peut également être effectué à l'aide de la variable php auto_append_file qui comme son nom l'indique ajoute automatiquement à toutes les pages la valeur considérée.

5/ Pour ajouter en discrétion, le pirate peut choisir de modifier le .htaccess du site web et de ne rediriger que quelques clients (selon l'IP source, le navigateur ou le referer utilisé) vers une page malveillante. Généralement, le pirate ne redirige que des clients provenant d'un moteur de recherche. Ainsi, les habitués du site (admin, utilisateurs) ne constatent aucune modification et accèdent au site par l'utilisation d'un lien en favori ou en tapant l'URL directement dans la barre d'adresse.
Les redirections peuvent également choisir de renvoyer vers le site d'origine les machines sans intérêt (déjà passées par là, ou non vulnérables pour l'attaque considérée). Un utilisateur ira donc sur le site via une recherche google, se fera infecter et n'accédera pas au site. La seconde fois qu'il cliquera sur le site, il y accédera normalement.
L'administrateur devra donc accéder à son site de diverses manières pour vérifier l'état de son site.

6/ Le niveau le plus élevé de discrétion et de furtivité que j'ai pu voir a été fait en ajoutant des modules apaches. Chercher darkleech pour plus d'infos là dessus.
Ce module permet au pirate d'ajouter dynamiquement le code offensif aux pages web souhaitées . De plus, le module fait attention à ne jamais renvoyer deux fois le code offensif à la même IP source dans un certain intervalle de temps. Il surveille également les connexions IP au serveur web. Si une IP est connectée en ssh, alors aucun contenu malicieux ne lui sera renvoyé. Si root est loggé, si tcpdump est lancé, ou si des programmes comme rkhunter ou équivalent tournent le module n'a aucune activité.
C'est ingénieux: en cas de compromission, alors l'admin va toujours se connecter en ssh pour étudier la situation, et le module va faire le mort empêchant ainsi sa détection. Si l'admin recharge plusieurs fois la page ou scanne son serveur, il ne verra absolument rien d'anormal.

Conclusion/
Pour pouvoir nettoyer son site, il faut s'assurer de pouvoir s'y connecter. Dans certaines situations les pirates changent les mots de passe. Il faut donc toujours connaître plusieurs moyens d'accès: mot de passe du CMS, mot de passe ftp pour uploader les pages, mot de passe ssh, accès physique à la machine, redirection du DNS vers une autre IP, etc...
Une fois que le code offensif a été corrigé, il reste le plus gros du travail, c'est à dire à trouver comment le pirate est rentré la première fois, sinon il reviendra et vous serez condamné a recevoir un autre email vous prévenant que votre site "a sans doute un problème". Et pour ça, il n'existe pas de solution magique, lire les logs, mettre à jour, tracer les accès, mieux blinder le site, etc...

[update 25/04: quelques cleanup et typos]