93 Membres 1308 Contributions

Open Community

Votre site web est il compromis? (partie 3/3)

Publiée par Nicolas R. - Arkoon dans technique

Voici la troisième partie de notre article consacré à la compromission des sites webs. Nous allons voir comment les pirates modifient les .htaccess ou vont modifier le programme apache lui-même.

 

Pour ajouter en discrétion, le pirate peut choisir demodifier 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à, déjà infectées, 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 vérifier que son fichier .htaccess n'est pas modifié, et accéder à son site de diverses manières pour vérifier l'état de son site.

 

Le niveau le plus élevé de discrétion et de furtivité qui a été vu a été fait en ajoutant des modules apaches. Un module malveillant appelé darkleech ( http://ondailybasis.com/blog/?p=1368 ) 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. L'administrateur doit donc vérifier la liste des modules chargés par le serveur web. Dans le même veine, certains pirates modifient directement le binaire apache lui-même ( http://blog.sucuri.net/2013/04/apache-binary-backdoors-on-cpanel-based-servers.html ). La solution pour l'administrateur est de vérifier à l'aide du gestionnaire de paquetages de sa distribution la validité du binaire apache.

 

Cet article sur les différentes compromissions d'un site web se termine ici. Dans le cas d'une compromission avérée, il faut alors nettoyer son site, et pour cela 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 afin de fermer cette faille, mais là, il n'existe pas de solution magique: se tenir à jour, lire les logs, etc..

Pour publier un commentaire, merci de vous authentifier.

Messages d'alerte