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

40

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,

Lothar_Grimpsenbacher
la source
6
Je ne sais pas, avez-vous donné votre mot de passe à quelqu'un?
4
Si vous savez exactement quand cela se produit, recherchez dans votre access_log toutes les choses inhabituelles à cette époque. Prenez particulièrement note de toutes les demandes POST: où vont-elles, qu'est-ce qu'elles ont fait.
Sanmai
3
Thx WhirlWind ... très utile.
Lothar_Grimpsenbacher
2
En fait, si vous les connaissez, pourquoi ne pas coller leurs coordonnées sur un site anti-spam. Laissez le réseau leur "parler" et donnez-leur un aperçu de leur propre médecine. :-)
4
@ gaoshan88 - plus utile que vous pourriez le penser. Un vecteur d'attaque est un cheval de Troie qui détecte les mots de passe des clients ftp des développeurs.
Quentin

Réponses:

9

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.

Tour
la source
6
+1, évitez FTP comme peste. Un cheval de Troie renifleur de mots de passe peut infecter votre ordinateur et utiliser vos informations d'identification pour modifier les fichiers. Ou cela peut infecter votre routeur. Ou l'ordinateur de votre voisin au netcafe avec le réseau wifi non sécurisé. Envoyer le mot de passe en clair est une mauvaise idée.
Tgr
1
FTP ne vient avec SSL, vous savez.
Grawity
1
@grawity la plupart des gens n'utilisent pas "ftps", mais cela vous évitera de vous faire pirater. sftp est plus populaire.
Rook
2
Www-data ne doit PAS posséder de fichiers dans votre répertoire Web. Tout ce que www-data peut être mis à jour par un script mal écrit sur le serveur.
Zoredache
9

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

typeoneerror
la source
haha. mes sites de gs sont tous en panne en ce moment. pas d'email. weblog.mediatemple.net/weblog/category/system-incidents/…
typeoneerror
2

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)?

Abarax
la source
renommer est une bonne idée. Je vais essayer cela une fois que je verrai quels effets cela aura sur le site. Crontab avait une chose un peu étrange, il y a une entrée pour à peu près le moment où les fichiers ont été modifiés mais c'est le gestionnaire de sauvegarde de Plesk ... une application compilée. Si cela est compromis, Media Temple aura un gros problème à résoudre.
Lothar_Grimpsenbacher
1

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!


la source
1

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.

éditeur
la source
Les journaux indiquent le trafic à peu près au moment où ces fichiers ont été modifiés, mais il contient des informations inoffensives telles que: 207.46.13.43 - - [05 / May / 2010: 01: 42: 26 - 0700] "GET /oped/bpr.php?edid= 211 & page = 4 HTTP / 1.1 "404 257" - "" msnbot / 2.0b (+ search.msn.com/msnbot.htm ) "
Lothar_Grimpsenbacher
Savez-vous comment ce hack Wordpress a fonctionné? Peut-être me dire comment résoudre mon propre problème.
Lothar_Grimpsenbacher
2
Oui, il s'agissait de mauvaises autorisations sur les boîtes partagées, probablement dues à de mauvaises configurations par défaut de la part de Network Solutions. La solution recommandée était de verrouiller les autorisations sur 755 pour les dossiers et 644 sur les fichiers.
1

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.

Webbiedave
la source
Je suppose qu'il se peut que le code tiers ait un exploit. C'est sur un serveur partagé, mais j'aurais trouvé tous les scripts téléchargés (à moins qu'ils ne l'aient téléchargé, utilisé, puis supprimé, mais j'aurais quand même trouvé quelque chose dans les fichiers journaux indiquant leur connexion ftp)
Lothar_Grimpsenbacher
1
Si vos fichiers peuvent être écrits par le serveur Web, il est possible que le script ait été chargé sur n’importe quel site Web du serveur et écrasé vos fichiers. Mais je voudrais aussi regarder de près cette application tierce.
Le code tiers ... est-ce un script exécutable ou juste un extrait de code JavaScript? JavaScript ne peut pas modifier les fichiers sur le serveur.
Salman Un
@Salman A - c'est une collection de scripts PHP qui gèrent la publicité.
Lothar_Grimpsenbacher
OK, alors j'espère que vous avez étudié ce code.
Salman Un
1

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

outis
la source
1

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.

Salman A
la source
1

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.

BillThor
la source
Les scripts non-CGI peuvent souvent avoir le mode 600 ou 640 (en fonction du propriétaire et du groupe de fichiers et de l'utilisateur sous lequel le serveur Web s'exécute), car de nombreux scripts sont transmis à un interpréteur.
sortie
0

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

Tgr
la source
0

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.

Joe Phillips
la source
Aucun Wordpress impliqué ici.
Lothar_Grimpsenbacher