REX sur incident : cas d un site web compromis Juin 2013 Philippe Bourgeois Plan de la présentation 1) Analyse d une compromission web Détection Analyse Remise en service Conclusions 2) Les faiblesses le plus souvent constatées Constats Recommandations page 2 1
1: Analyse d une compromission web 1.1 - Détection Google indique que le site web est dangereux page 4 2
1.2 - Analyse Constats 650 fichiers «.js» du site web ont été infectés document.write('<iframe src="http://google.com" scrolling="auto«frameborder="no" align="center" height="11" width="11"></iframe>'); Toutes les 30 minutes les fichiers sont ré-infectés 21:10:59 : <iframe src="http://eisczfg.freewww.info/facebook.cgi?8 22:25:23 : <iframe src="http://jevvke.pcanywhere.net/facebook.cgi?8 22:57:47 : <iframe src="http://kxsgd.ddns.info/facebook.cgi?8: 23:16:36 : <iframe src="http://oaiudvzrx.myftp.name/facebook.cgi?8 Le but est d infecter les visiteurs du site web infecté (drive-by download) Une backdoor est trouvée sur le site /images/banners/.lib_doyoa8.php Mot de passe : )GjKGqGZ page 5 1.2 - Analyse Encodage de la backdoor page 6 3
1.2 - Analyse Observation Toutes les 30 minutes un script PHP est envoyé à la backdoor L analyse de log ne permet pas d identifier formellement la méthode d infection Brute-force sur l interface d administration? Vulnérabilité dans le plugin JCE de Joomla? (file upload) page 7 1.3 - Remise en service Il est décidé d un plan d éradication de l infection Mais, avant le T0, le pirate opère un mouvement de repli : Il nettoie lui-même les fichiers infectés Et s en va (en laissant sa backdoor ) Le pirate préfère abandonner sa victime plutôt que de mettre en danger son infrastructure. page 8 4
1.4 - Conclusions L attaquant est professionnel Il n introduit pas de dysfonctionnements (discrétion, non détection) Il a un plan d action prédéfini (campagne, actions de replis) Il utilise les mêmes outils que les amateurs mais «bien»! Backdoor connue. Pilotée par des scripts PHP de bonne qualité Actions automatisées (scan, compromission, campagne d infection, etc ) page 9 2: Les faiblesses le plus souvent constatées 5
Constats 100% des attaques analysées utilisent des faiblesses connues Vulnérabilités connues (et correctifs non appliqués) Mots de passe triviaux sur des comptes administrateurs Si les sites web ne sont pas mis à jour, ils seront compromis! Certaines architectures n ont pas été conçues en prenant en compte la sécurité Pas de cloisonnement entre les sites web hébergés sur une même machine (pas de «chroot», le même «uid» pour tous les sites) L interface d administration n est pas protégée Fonctions «back-office» accessible depuis Internet, sans restriction. Un audit intrusif a-t-il inclus dans son périmètre ce «back-office». ainsi que les autres sites hébergés sur la même machine? page 11 Recommandations Prévention Détection Limiter l impact Traitement Les sites web doivent être maintenus à jour en termes de correctifs de sécurité Mise à jour régulière des serveurs (Apache, IIS) et des frameworks sous-jacents (Joomla, Symphony, RubyOnRail, Java,.Net, etc..) Empêcher ou détecter les attaques connues WAF / IDS / Antivirus Isoler pour éviter la conséquence d une compromission Autoriser uniquement le HTTP et HTTPS en entrée Et tout interdire en sortie (ce qui implique que les flux DNS et mail passent par des infra DMZ dédiées) Conserver les logs et analyser les incidents de sécurité page 12 6
QUESTIONS? page 13 7