41 votes

A été piraté. Veut comprendre comment

Quelqu'un a, pour la deuxième fois, ajouté un morceau de javascript à un site que j'aide à gérer. Ce javascript détourne Google adsense, insérant leur propre numéro de compte, et collant des annonces partout.

Le code est toujours ajouté, toujours dans un répertoire spécifique (utilisé par un programme publicitaire tiers), affecte plusieurs fichiers dans plusieurs répertoires à l'intérieur de ce répertoire publicitaire unique (une vingtaine environ) et est inséré à peu près à la même heure de nuit. Le compte adsense appartient à un site Web chinois (situé dans une ville à une heure de là où je serai en Chine le mois prochain. Peut-être devrais-je aller réprimander... plaisanterie, en quelque sorte), au fait... voici les infos sur le site: http://serversiders.com/fhr.com.cn

Alors, comment pourraient-ils ajouter du texte à ces fichiers? Est-ce lié aux autorisations définies sur les fichiers (variant de 755 à 644)? À l'utilisateur du serveur Web (c'est sur MediaTemple donc ça devrait être sécurisé, non?)? Je veux dire, si vous avez un fichier avec des autorisations définies sur 777 je ne peux toujours pas juste y ajouter du code à volonté... comment pourraient-ils faire cela?

Voici un exemple du code réel pour votre plaisir visuel (et comme vous pouvez le voir... pas grand-chose à cela. Le vrai tour de main est comment ils l'ont inséré là-dedans):

<!--
google_ad_client = "pub-5465156513898836";
/* 728x90_as */
google_ad_slot = "4840387765";
google_ad_width = 728;
google_ad_height = 90;
//-->

Comme plusieurs personnes l'ont mentionné, voici ce que j'ai vérifié (et par vérifié, je veux dire j'ai regardé autour de l'heure à laquelle les fichiers ont été modifiés pour toute anomali et j'ai greppé les fichiers pour des déclarations POST et des traversées de répertoire:

  • access_log (rien à cette heure-là sauf du trafic bot msn normal (càd excessif))
  • error_log (rien d'autre que les erreurs habituelles de fichiers qui n'existent pas pour des fichiers anodins)
  • ssl_log (rien d'autre que d'habitude)
  • messages_log (pas d'accès FTP ici sauf pour moi)

*MISE À JOUR:** OK, problème résolu. Des hackers chinois avaient physiquement placé un fichier sur notre site leur permettant d'exécuter toutes sortes de tâches administratives (accès à la base de données, supprimer et créer des fichiers et des répertoires, vous l'appelez, ils avaient accès). Nous avons eu de la chance qu'ils n'aient rien fait de plus destructeur. Il n'y avait rien dans les fichiers de log Apache habituels mais j'ai trouvé un ensemble différent de fichiers journaux dans un analyseur de journaux de serveur Web et les preuves étaient là. Ils accédaient à ce fichier avec leur propre nom d'utilisateur et mot de passe admin, puis éditaient tout ce dont ils avaient besoin directement sur le serveur. Leur fichier avait "apache" comme utilisateur alors que tous les autres fichiers sur notre site avaient un nom d'utilisateur différent. Maintenant, je dois comprendre comment ils ont physiquement eu ce fichier sur notre système. Je soupçonne que la responsabilité de cela reposera éventuellement sur notre hébergeur Web (Media Temple), à moins qu'ils n'aient réellement eu nos infos de connexion FTP... pas sûr comment je vais déterminer cela, cependant, étant donné que ce fichier est probablement là depuis un moment.

1voto

webbiedave Points 149

Le code est toujours ajouté, toujours dans un répertoire spécifique

Est-ce lié aux autorisations définies sur les fichiers (allant de 755 à 644) ? À l'utilisateur du serveur web

Êtes-vous sur un serveur partagé ? Si c'est le cas (ou même si ce n'est pas le cas), quelqu'un a peut-être forcé un mot de passe FTP et a téléchargé un script qui a ajouté des fichiers qu'il pouvait obtenir.

utilisé par un programme publicitaire tiers

Ou peut-être que ce programme a une vulnérabilité.

1voto

DaveCrawford Points 671

Si vous avez un accès approprié (et un support noyau), vous pourriez essayer de mettre en place un démon de surveillance basé sur inotify ou dnotify pour détecter les changements sur vos fichiers, puis (rapidement) utiliser "lsof" pour voir quel processus a le fichier ouvert en écriture. Vous pourriez également utiliser strace pour la surveillance. Cela devrait vous donner une indication sur quel exécutable est exploité.

1voto

Salman A Points 452

L'inspection des journaux FTP est le premier endroit où commencer. Le journal devrait contenir la plupart, sinon la totalité des activités, ainsi que les horodatages, de sorte que si vous savez à quel moment vos fichiers ont été modifiés, vous pouvez déterminer si votre compte FTP est compromis ou non.

Ensuite, il pourrait s'agir d'un script sur votre serveur web qui injecte ce code. Dans un scénario d'hébergement partagé, je pense qu'il est possible d'exécuter cat /web/malicious.com/script.js >> /web/innocent.com/index.php. Cela pourrait fonctionner dans certaines conditions, telles que la commande étant exécutée par l'utilisateur httpd et le fichier index.php étant également possédé/inscriptible par cet utilisateur. Dans ce cas, vous devez demander à votre fournisseur d'hébergement de retracer le compte utilisé pour injecter les scripts.

1voto

BillThor Points 27096

La plupart des fichiers du site doivent être lisibles par le serveur web. Sur un site en lecture seule, seuls les journaux doivent être inscriptibles par le serveur web. Définissez le propriétaire sur quelqu'un d'autre que celui utilisé par le serveur web. Réglez la protection sur 640 pour tous les fichiers, sauf les scripts. Définissez les scripts et répertoires sur 750. Pour les fichiers ou répertoires qui doivent être écrits par le serveur web, vous pouvez changer le propriétaire en le serveur web ou définir le chmod g+2 pour les fichiers ou répertoires pertinents.

0voto

Tgr Points 306

Il existe des milliers de façons possibles de pirater un site. Ils auraient pu utiliser une faille dans votre script, voler votre mot de passe, exploiter une faille d'un site hébergé conjointement (si vous êtes chez un hébergeur bon marché), utiliser une faille de certains services non liés au web sur la machine du serveur...

En première étape, vérifiez la date de modification du fichier, et vérifiez les journaux d'accès, d'erreurs et de transfert FTP pour toute activité suspecte à ce moment-là.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X