Site hacké * Modification des droits d'écriture

[scoch]

Bonjour,

un site Web dont je m'occupe a été hacké : un script a été injecté dans des fichiers .html. Les fichiers .php sur le serveur n'ont pas été infectés. Le site est hébergé sur un serveur mutualisé chez ovh.

Je précise qu'il ne s'agit pas d'un CMS et que ce n'est pas moi qui ai développé ce site, le propriétaire du site m'a confié sa refonte sur laquelle je travaille en ce moment. Le site utilise de vieux fichiers .swf Flash mais ils n'ont pas été modifiés, de même il utilise de vieux fichiers JavaScript en provenance du Web (pas créés par l'ancien développeur) mais ces fichiers n'ont pas été modifiés. (La version que je prépare n'utilise ni Flash ni fichiers JavaScript en provenance du Web.)

Je précise aussi que le site permet aux utilisateurs de s'identifier et d'uploader des fichiers .pdf. Le dossier dans lequel sont uploadés les .pdf a les droits d'écriture à 705, les fichiers uploadés sont en 604. Le dernier .pdf uploadé l'a été quatre jours avant l'attaque.

La première chose que j'ai faite quand j'ai eu l'accès ftp a été de modifier le mot de passe et les droits en écriture des fichiers et dossiers. Je pensais avoir « blindé » les droits en écriture de ces fichiers en les mettant à 404, mais suite à l'attaque, je les ai retrouvés en 644.

Comment les attaquants peuvent-ils changer les droits en écriture des fichiers ?

Merci pour vos réponses.

[iRed]

faut voir si Apache a suffisament de droit pour modifier les droits des fichiers...
En tout cas ta fonction d'upload de PDF semble vulnérable

[scoch]

Merci pour ta réponse.

faut voir si Apache a suffisament de droit pour modifier les droits des fichiers...

Je peux modifier les droits d'un fichier avec la méthode chmod de php, c'est ça que tu voulais voir ?

En tout cas ta fonction d'upload de PDF semble vulnérable

Quelle est la vulnérabilité que tu vois ?

[yponomeute]

Regarde si tu as accès aux logs sur le mutualisé, si par hasard tu y trouves des url "bizarres", ça pourrait te permettre de trouver le point d'entrée du hacker.
D'autre part si le hacker a déjà eu accès au site il a pu y déposer un fichier qui va lui permettre d'y accéder à nouveau

Autre chose à regarder, sur certaines gammes de mutualisés ovh il est possible d'y accéder en ssh. Dans ce cas il faut vérifier s'il n'y a pas une autorisation d'accès qui a été créée avec une paire de clés ssh. S'il y en a une elle va se trouver dans un fichier qui se trouve dans le répertoire invisible .ssh/authorized_keys

Ce message a été modifié par yponomeute - 1 Sep 2014, 17:24.

[Akirami]

De mémoire, il y a une vulnérabilité dans le format PDF d'Adobe, le lecteur de Firefox n'est pas mieux et celui de Windows reste du Windows (pour être poli).

J'essaie de retrouver cela mais il n'est pas impossible que cela vienne directement de la manière d'afficher un PDF via un serveur Apache s'il elle est ancienne... la manière...

Edit : http://www.secuser.com/vulnerabilite/2011/...dobe-reader.htm

Chercher de ce côté là ou encore là : https://www.cases.lu/vulnerabilite_extremem...et_acrobat.html

Ce format bien pratique est une vrai passoire, merci Adobe d'avoir bien maintenu un format ouvert pour notre plus grand plaisir.

Ce message a été modifié par Akirami - 1 Sep 2014, 17:35.

[scoch]

Merci pour vos réponses.

Regarde si tu as accès aux logs sur le mutualisé, si par hasard tu y trouves des url "bizarres", ça pourrait te permettre de trouver le point d'entrée du hacker.
D'autre part si le hacker a déjà eu accès au site il a pu y déposer un fichier qui va lui permettre d'y accéder à nouveau

J'ai accès aux logs. Pas d'url suspectes. Dans la tranche horaire où les fichiers ont été infectés, seuls les bot de Bing et Voila (Orange) sont passés.
Je ne vois aucune trace de nouveau fichier sur le serveur, en me fiant aux dates de modification des dossiers et fichiers. Par contre c'est étrange, Filezilla m'indique qu'un dossier a été modifié il y a 30mn mais je ne vois aucun nouveau fichier dedans ou aucun fichier modifié, et les droits d'écriture de ce dossier n'ont pas changés…

Autre chose à regarder, sur certaines gammes de mutualisés ovh il est possible d'y accéder en ssh. Dans ce cas il faut vérifier s'il n'y a pas une autorisation d'accès qui a été créée avec une paire de clés ssh. S'il y en a une elle va se trouver dans un fichier qui se trouve dans le répertoire invisible .ssh/authorized_keys

Je ne vois pas le répertoire invisible .ssh/authorized_keys. Lorsque je me connecte en ssh (sftp) avec Filezilla j'ai ce message : « La clé du serveur hôte est inconnue. Vous n'avez aucune garantie que ce serveur est bien le bon. »

@Akirami je vais regarder ça ! Je dois faire une pause jusqu'à demain matin.

Ce message a été modifié par scoch - 1 Sep 2014, 18:32.

[No6]

De ce que je sais, les fichiers PDF peuvent eux même contenir des scripts, ils sont en Javascript à la sauce Adobe, avec les possibilités de lecture/écriture, et même, je crois la possibilité d'y faire des appels de fonctions externes via une url...

Si ce n'est déjà fait, j'imagine que seuls des utilisateurs authentifiés peuvent avoir accès au système d'upload des PDF, non ?

Sinon, il y a aussi la possibilité de n'accepter que des PDF dont l'origine est autentifiée => http://help.adobe.com/fr_FR/acrobat/standa...5ff-7d8b.w.html

...

[scoch]

Si ce n'est déjà fait, j'imagine que seuls des utilisateurs authentifiés peuvent avoir accès au système d'upload des PDF, non ?

Oui, seuls les membres de l'équipe qui anime le site crée et uploade ces .pdf.
Ces .pdf sont tous créés à partir d'un même gabarit. Pour partir sur une base saine, je vais proposer de les remplacer par du html avec un module en back office pour stocker les contenus en base de données.

Je suis tout de même ennuyé de ne pas savoir ce qui s'est passé…

Un truc qui m'a étonné aussi, c'est que c'est un utilisateur qui nous a informé que le site avait été hacké : Chrome affichait le message d'avertissement de logiciel malveillant, en mentionnant l'url que le script utilisait . Il m'a suffit de nettoyer le code html pour que ce message d'avertissement disparaisse. Or, généralement, quand Google détecte une infection il faut ensuite soumettre le site à examen pour que l'avertissement soit levé.

[iRed]

Si tu veux je jette un oeil rapide au site

[tibounise]

Peut-être un des contributeurs qui se serait fait pirater ? Ou bruteforce du login du FTP ?

[scoch]

Si tu veux je jette un oeil rapide au site

Merci pour la proposition mais la version actuelle ne sera plus utilisée dans quelques jours.
Cette attaque injecte un élément script dans le DOM de documents html statiques. Dans la nouvelle version c'est du php, le DOM est construit dynamiquement avec des inclusions de fichiers avec des noms « originaux » (pas head.php, footer.php, etc). Le site étant très bien référencé je fais de la réécriture d'url pour conserver les urls originales mais les fichiers html n'existent plus. J'espère ainsi un peu compliquer la tâche des pirates pour modifier le code des documents mais je ne saurai pas comment ils s'y sont pris cette fois-ci…

Peut-être un des contributeurs qui se serait fait pirater ? Ou bruteforce du login du FTP ?

Peut-être un PC vérolé. Pour le mot de passe ftp j'en avais créé un solide (une longue chaîne aléatoire de lettres, chiffres et symboles), je l'ai quand même changé

[iRed]

Ok pas de soucis.
Mais vu d'ici je dirais que ta fonction d'upload vérifie mal le type de fichier uploadé et que le hacker est passé par là. Du coup upload d'une backdoor PHP puis modification du code HTML pour balancer des malwares. Le coup mega classique.

[yponomeute]

Si tu veux je jette un oeil rapide au site

Merci pour la proposition mais la version actuelle ne sera plus utilisée dans quelques jours.
Cette attaque injecte un élément script dans le DOM de documents html statiques. Dans la nouvelle version c'est du php, le DOM est construit dynamiquement avec des inclusions de fichiers avec des noms « originaux » (pas head.php, footer.php, etc). Le site étant très bien référencé je fais de la réécriture d'url pour conserver les urls originales mais les fichiers html n'existent plus. J'espère ainsi un peu compliquer la tâche des pirates pour modifier le code des documents mais je ne saurai pas comment ils s'y sont pris cette fois-ci…

Peut-être un des contributeurs qui se serait fait pirater ? Ou bruteforce du login du FTP ?

Peut-être un PC vérolé. Pour le mot de passe ftp j'en avais créé un solide (une longue chaîne aléatoire de lettres, chiffres et symboles), je l'ai quand même changé

Il faudrait aussi changer le mot de passe du manager OVH par sécurité.
Le dernier site hacké qu'on m'a "confié" il a une dizaine de mois, se faisait re-hacker systématiquement après nettoyage et après changement du mot de passe ftp. Ça s'est arrêté après changement du mot de passe du manager (c'était pas chez ovh). Bon faut dire aussi que le mot de passe c'était un prénom en six lettres, même mot de passe pour le manager et login ftp.

[scoch]

@iRed merci pour la piste et les explications. J'ai regardé le programme php d'upload et effectivement ça n'est pas terrible question détection du type de fichier. J'ai lu qu'idéalement il faudrait que le dossier d'upload soit en dehors du webroot et de stocker en db les chemins d'accès aux fichiers, je ne l'ai jamais fait, je vais voir comment le mettre en place dans le cas où le format pdf reste obligatoire.

@yponomeute merci pour ton retour d'expérience. Dans mon cas, les mots de passe du manager et du ftp sont différents et plutôt solides. Je vais proposer de changer aussi celui du manager.

Ce message a été modifié par scoch - 3 Sep 2014, 14:25.

[Akirami]

Tu peux aussi simplement le faire écrire sur un fichier à plat, détruit après lecture, ça permet au moins après un read_file + explode de ne garder que l'URL ainsi que de la passer à l'eternel escape_string + htmlentites.
Tu as aussi la possibilité de vérifier l'ip de l'uplaod, vérrifier simplement s'il est encore là, si c'est dynamique après qq secondes, c'est pas bon, autrement tu gardes.

Aussi, regardes l'encodage, ISO ou UTF8 ? Le DOM, il peut y avoir des failles de partout sur de vieux scripts, si tu pouvais nous les mettre ici sans les logs et surtout la manière à se connecter à la BDD, je n'ai pas mon ordi mais je pourrais tjrs aider, ainsi que d'autres

Edit : l'entête HTTP avec...

Ce message a été modifié par Akirami - 3 Sep 2014, 16:14.

[scoch]

Merci pour ta réponse. J'ai manqué de temps pour passer plus tôt.

Tu peux aussi simplement le faire écrire sur un fichier à plat, détruit après lecture, ça permet au moins après un read_file + explode de ne garder que l'URL ainsi que de la passer à l'eternel escape_string + htmlentites.

Finalement, ma proposition de ne plus utiliser de fichiers pdf mais d'utiliser du contenu en base de données n'a pas été retenue, ces pdf doivent pouvoir être générés avec MS Word. Aussi, ces pdf participent au bon référencement du site, je suppose que si on les upload en dehors du webroot les robots d'indexation n'auront plus accès à leurs contenus mais seulement à leurs urls à partir de liens présents dans le site… Le nom avec extension des fichiers uploadés est généré dynamiquement lors de l'upload, caractères alphanumériques et extension .pdf.

Tu as aussi la possibilité de vérifier l'ip de l'uplaod, vérrifier simplement s'il est encore là, si c'est dynamique après qq secondes, c'est pas bon, autrement tu gardes.

Tu pourrais m'éclairer un peu plus ? Merci

Aussi, regardes l'encodage, ISO ou UTF8 ? Le DOM, il peut y avoir des failles de partout sur de vieux scripts, si tu pouvais nous les mettre ici sans les logs et surtout la manière à se connecter à la BDD, je n'ai pas mon ordi mais je pourrais tjrs aider, ainsi que d'autres

Edit : l'entête HTTP avec...

Le site et la base de données sont en utf-8. Dans ma version j'envoie un header HTTP Content-Type.
La version actuelle est vraiment vieille et utilise des requêtes mysql mais la base n'a pas été piratée, ouf ! Je reprends tout avec PDO et des requêtes préparées.

Il faudrait aussi changer le mot de passe du manager OVH par sécurité.
Le dernier site hacké qu'on m'a "confié" il a une dizaine de mois, se faisait re-hacker systématiquement après nettoyage et après changement du mot de passe ftp. Ça s'est arrêté après changement du mot de passe du manager (c'était pas chez ovh). Bon faut dire aussi que le mot de passe c'était un prénom en six lettres, même mot de passe pour le manager et login ftp.

J'ai vérifié, le client reçoit un mail de notification à chaque connexion au manager, il ne s'est rien passé de suspect.

Ce message a été modifié par scoch - 7 Sep 2014, 15:20.

[Akirami]

Vérifier l'IP de l'upload : ça veux dire simplement de vérifier qui se connecte sur ton serveur, c'est tout
Je rtetourne jouer à Warcraft et Dwarff Fortress...

[scoch]

C'était au sujet de vérifier si cette IP est encore là… Bon jeu

Ok pas de soucis.
Mais vu d'ici je dirais que ta fonction d'upload vérifie mal le type de fichier uploadé et que le hacker est passé par là. Du coup upload d'une backdoor PHP puis modification du code HTML pour balancer des malwares. Le coup mega classique.

Un truc que j'ai oublié de préciser c'est qu'à chaque fois qu'un pdf est uploadé, un mail avec le lien vers ce fichier est envoyé à l'équipe du site. Si le hacker upload un script php se faisant passer pour un pdf, le mail est censé être envoyé avec l'url de la backdoor, non ?

Ce message a été modifié par scoch - 7 Sep 2014, 21:13.

[iRed]

C'était au sujet de vérifier si cette IP est encore là… Bon jeu

Ok pas de soucis.
Mais vu d'ici je dirais que ta fonction d'upload vérifie mal le type de fichier uploadé et que le hacker est passé par là. Du coup upload d'une backdoor PHP puis modification du code HTML pour balancer des malwares. Le coup mega classique.

Un truc que j'ai oublié de préciser c'est qu'à chaque fois qu'un pdf est uploadé, un mail avec le lien vers ce fichier est envoyé à l'équipe du site. Si le hacker upload un script php se faisant passer pour un pdf, le mail est censé être envoyé avec l'url de la backdoor, non ?

En théorie oui. Il faut cependant voir comment est fait le script

[scoch]

C'est sûr
Je posterai mon nouveau script lorsqu'il sera prêt, pour avoir vos avis d'experts.