J'ai été piraté. Vouloir comprendre comment

Pour la deuxième fois, une personne a ajouté une partie de javascript à un site que j'aide à fonctionner. Ce javascript détourne Google adsense, en insérant son propre numéro de compte et en collant des annonces partout.

Le code est toujours ajouté, toujours dans un répertoire spécifique (celui utilisé par un programme publicitaire tiers), affecte un certain nombre de fichiers dans plusieurs répertoires de ce répertoire (environ 20) et est inséré à peu près au même jour. temps. Le compte adsense appartient à un site Web chinois (situé dans une ville à moins d'une heure de là où je serai en Chine le mois prochain. Peut-être devrais-je me prendre la tête ... je plaisante, 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 (de 755 à 644)? Pour l'utilisateur du serveur Web (c'est sur MediaTemple alors il devrait être sécurisé, oui?)? Je veux dire, si vous avez un fichier dont les autorisations sont définies sur 777, je ne peux toujours pas y ajouter du code à volonté ... comment pourraient-ils le faire?

Voici un exemple du code réel qui vous plaira (et comme vous pouvez le voir ... pas grand-chose. Le vrai truc, c'est comment ils l'ont obtenu ici):

<script type="text/javascript"><!--
google_ad_client = "pub-5465156513898836";
/* 728x90_as */
google_ad_slot = "4840387765";
google_ad_width = 728;
google_ad_height = 90;
//-->
</script>
<script type="text/javascript"
src="http://pagead2.googlesyndication.com/pagead/show_ads.js">
</script>

Depuis que plusieurs personnes l'ont mentionné, voici ce que j'ai vérifié (et par coche, je veux dire, j'ai regardé vers le moment où les fichiers ont été modifiés pour éviter les bizarreries et j'ai attrapé les fichiers pour les instructions POST et les répertoires:

• access_log (rien dans le temps sauf le trafic bot normal et excessif)
• error_log (rien sauf le fichier habituel n'existe pas d'erreurs pour les fichiers inoffensifs)
• ssl_log (rien mais l'habituel)
• messages_log (pas d'accès FTP ici sauf pour moi)

* MISE À JOUR: ** OK, résolu. Des pirates chinois avaient placé physiquement sur notre site un fichier leur permettant de faire toutes sortes de démarches administratives (accès à une base de données, suppression et création de fichiers et de répertoires, vous le nommez, ils y 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 journaux Apache normaux, mais j'ai trouvé un ensemble différent de fichiers journaux dans un analyseur de journaux de serveur Web et les preuves s'y trouvaient. Ils accédaient à ce fichier avec leur propre nom d'utilisateur et mot de passe, puis modifiaient ce dont ils avaient besoin directement sur le serveur. Leur fichier a "apache" défini comme utilisateur alors que tous les autres fichiers sur notre site ont un nom d'utilisateur différent. Maintenant, je dois comprendre comment ils ont physiquement récupéré ce fichier sur notre système. Je soupçonne que notre responsable Web (Media Temple) en sera responsable,

Tout d' abord chmod 744ce ne est pas ce que vous voulez. Le but de chmod est de révoquer l’accès à d’autres comptes du système. Chmod 700est beaucoup plus sécurisé que chmod 744. Cependant, Apache n'a besoin que du bit d'exécution pour exécuter votre application php.

chmod 500 -R /your/webroot/

chown www-data:www-data -R /your/webroot/

www-data est couramment utilisé comme compte Apache, utilisé pour exécuter le php. Vous pouvez également exécuter cette commande pour voir le compte d'utilisateur:

`<?php
print system("whoami");
?>`

FTP est terriblement peu sécurisé et il est très probable que vous ayez été piraté par cette méthode. En utilisant FTP, vous pouvez rendre des fichiers accessibles en écriture, puis les infecter à nouveau. Assurez-vous que vous exécutez un anti-virus sur toutes les machines avec un accès FTP. Il existe des virus qui détectent le trafic local pour les noms d'utilisateur et les mots de passe FTP, puis se connectent et infectent les fichiers. Si vous vous souciez de la sécurité, vous utiliserez SFTP, qui crypte tout. Envoyer du code source et des mots de passe en clair en texte clair est une folie totale.

Une autre possibilité est que vous utilisiez une ancienne bibliothèque ou application. Visitez le site du fournisseur du logiciel et assurez-vous que vous utilisez la dernière version.

Les comptes de My Media Temple Grid Server ont été "piratés" de la sorte à plusieurs reprises. Leur sécurité est très médiocre ... a commencé avec PLAIN TEXT PASSWORDS l'année dernière et continue à ce jour (vous pouvez appeler le support technique pour qu'ils disent "quel est votre mot de passe?"). Je sais parce que je reçois des courriels mensuels sur la façon dont ils ont modifié tous les mots de passe de mon compte. Ils y vont et changent les mots de passe de la base de données pour vous chaque fois qu'ils se font pirater. Cette entreprise a un aspect brillant à la surface, mais le serveur de grille est en désordre. Je recommande de changer immédiatement .

S'il vous plaît voir ce post de l'année dernière sur le fiasco original (attention, il va vous faire chier). C'est descendu à partir de là. L'année dernière, j'ai passé l'action de grâce loin de ma famille et supprimer les liens pornographiques de mes sites Web. Charmant.

Gardez une trace de l’amusement sur leur page de statut : il vous dira tout sur les derniers exploits (et, effectivement, il y a un "exploit possible" là-bas en ce moment).

D'après le manque d'activité dans les journaux d'accès, etc., et le fait qu'il se passe à peu près au même moment, il semblerait que le serveur ait été compromis et qu'un script shell soit en cours d'exécution pour exécuter l'ajout.

Avez-vous vérifié quelque chose d'étrange chez crontab?

Avez-vous essayé de renommer le répertoire et ses références (cela risquerait de casser le script shell)?

Oui, cela pourrait très certainement être lié aux autorisations de fichiers. En disposant de fichiers accessibles en écriture par le processus Web, vous êtes exposé à toute faille de sécurité dans les applications Web que vous exécutez. Verrouillez tout pour que le processus Web ne puisse plus lire ou écrire plus que nécessaire.

L'autre composant détecte exactement comment ils modifient vos fichiers. La vérification des journaux d’accès du serveur Web est un bon point de départ. Vérifiez les dernières heures de connexion pour différents utilisateurs. Vous pouvez également configurer un script qui surveille la modification des fichiers et vous en informe afin que vous puissiez attraper les criminels en flagrant délit!

Cela semble terriblement familier aux hackers de Wordpress qui ont récemment touché de nombreux sites de solutions de réseau. Étant donné que vous êtes sur Media Temple, il est possible que vous laissiez certains fichiers visibles aux autres utilisateurs partageant votre ordinateur. Cela expliquerait le manque de traces POST ou étranges du journal Apache. Si c'est le cas, il serait extrêmement simple d'injecter du code sur la ligne de commande.

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

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

Êtes-vous sur un serveur partagé? Si tel est le cas (ou même si ce n’est pas le cas), il se peut que quelqu'un ait forcé un mot de passe FTP et téléchargé un script qui ajoute tous les fichiers sur lesquels il pourrait se trouver.

un utilisé par un programme publicitaire tiers

Ou peut-être que ce programme a un exploit.

Si vous disposez d'un accès approprié (et du support du noyau), vous pouvez essayer de créer un démon de surveillance basé sur inotify ou dnotify pour surveiller les modifications apportées à vos fichiers, puis (rapidement) utiliser "lsof" pour voir le processus avec lequel le fichier est ouvert. accès en écriture. Vous pourrez également utiliser strace pour la surveillance. Cela devrait fournir un indice sur le type d’exécutable exploité.

Les journaux d’inspection FTP sont le premier endroit à commencer. Le journal doit contenir la plupart, sinon la totalité des activités, ainsi que des horodatages. Par conséquent, si vous savez à quelle heure 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 de faire un cat /web/malicious.com/script.js >> /web/innocent.com/index.php. Cela peut fonctionner dans certaines conditions, telles que l'exécution de la commande par l'utilisateur httpd et le fichier index.php appartenant également à cet utilisateur. Dans ce cas, vous devez demander à votre fournisseur d’hébergement de retracer le compte utilisé pour injecter les scripts.

La plupart des fichiers de 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 une personne autre que celle utilisée par le serveur Web. Définissez la protection 640 sur tous les fichiers sauf les scripts. Définissez les scripts et les répertoires 750. Pour les fichiers ou les répertoires devant être écrits par le serveur Web, vous pouvez remplacer le propriétaire par le serveur Web ou définir le chmod g + 2 comme fichiers ou répertoires appropriés.

Il y a un million de façons possibles de casser un site. Ils auraient pu utiliser une vulnérabilité de votre script, voler votre mot de passe, utiliser la vulnérabilité d'un site co-hébergé (si vous êtes chez un hôte bon marché), utiliser une vulnérabilité de certains services non liés au Web sur la machine du serveur. .

Dans un premier temps, vérifiez la date de modification du fichier, puis consultez les journaux d'accès, des erreurs et FTP pour détecter toute activité suspecte à ce moment-là.

La même chose m'est arrivé il y a quelque temps. Wordpress était le seul logiciel qui aurait provoqué quelque chose comme ça autant que je sache.