Discussion :

[rogerlenoir]

Bonjour,
Je m'occupe d'un site que je n'ai pas développé.
Ce site vient d'être attaqué via une injection SQL présente dans un fichier.
et de plus les mots de passe n'étaient pas cryptés dans la base de donnée.

Par ailleurs les fichiers PHP ont tous été effacés du serveur qui les hébergeait.

Bon on va remonter tout ça, maintenant qu'on sait qu'il y a une faille on va la corriger...
et puis on va crypter les mots de passe et faire quelques vérifications d'usage.

Mais comme je suis pas un cador il y a plein de choses que je ne sais pas.
Entre autre :
Comment fait-on à partir de la base de donnée pour effacer le site sur le ftp.

Et comme je ne sais pas, ça risque de nous arriver encore une fois.
Si quelqu'un peut m'expliquer la manip mais surtout la riposte je le remercie d'avance...


Merci et à bientôt

ps si cela est nécessaire j'ai les logs qui correspondent à l'attaque)

[NoSmoking]

Bonjour,
je ne doute pas de ta bonne fois mais il important de comprendre que ce genre de question et la réponse qui pourrait y être associé serait à la limite du hacking et donc illégale.

Je t'engages fortement à lire les cours sur ce sujet
http://web.developpez.com/cours/deve...ivers#securite

[rogerlenoir]

Merci NoSmoking,

je vais suivre le lien et lire attentivement.

Juste pour poursuivre la discussion l'information que je demande n'est pas illégale et elle devrait se trouver dans tous les bons manuels de programmation web.
Tout au plus c'est l'utilisation malhonnête de cet information qui serait illégale.
Par ailleurs je doute que les gamins qui ont hacké le site en question aient un quelconque besoin de formation, à mon avis ils l'ont déjà ...

De plus, pour un innocent (dans tous les sens du terme) comme moi, trouver la bonne info c'est le parcours du combattant.
Par contre si j'étais un hacker, je ferai parti d'un réseau et je n'aurai qu'à poser la question aux membres de mon team pour arriver à des fins aussi peu subtiles que les attaques dont je parle.


Pour finir, et pour qu'il n'y ait aucun doute sur la première phrase de ma réponse : mes remerciement sont vraiment sincères et je suis reconnaissant envers tous les modérateurs qui passent du temps à assurer le bon fonctionnement de ce forum.

Patrick

[rogerlenoir]

Au fait, Puisque je tiens le clavier, je vourdrai poser juste une question qui demande une réponse par oui ou par non:

Est-ce que le hacker est passé par la base de donnée pour effacer les fichiers, ou est que qu'il y avait une faille possible du coté du ftp (par exemple même mot de passe et même login que ceux utilisés pour la connexion à la base) ?

Merci d'avance

[bretus]

Est-ce que le hacker est passé par la base de donnée pour effacer les fichiers, ou est que qu'il y avait une faille possible du coté du ftp (par exemple même mot de passe et même login que ceux utilisés pour la connexion à la base) ?

Le hacker est passé par là où tu ne l'attendais pas... Vu le niveau de gravité des failles que tu évoques, il n'est pas impossible que tu te retrouves avec d'autres failles.

Le plus probable pour qu'il ait pu supprimer des fichiers, c'est qu'il soit parvenu à exécuter du code PHP à ton insu.

Il n'y aurait pas des upload mal contrôlé sur ce site pour couronner le tout? Du style, tu t'attends à ce que les utilisateurs upload des images, ils peuvent uploader des fichiers .php?

[rogerlenoir]

Merci Bretus,

Me voilà un peu plus informé,
pour l'instant nous avons demandé au précédent développeur de corriger les failles de type injection, d'implanter un hashage des mots de passe

Une fois cela fait je vérifierai d'autres points tels que celui que tu énonces auquel je n'avais pas pensé. Donc doublement merci.

Plus je réfléchi, plus je me dis qu'il doit-être possible de provoquer l'effacement des fichiers à partir de la base de donnée.
Mais là ce serait la faille de saint Andréas

Est-ce que ça vaut le coup que je passe des heures pour me prouver que c'est possible, ou est-ce que je me trompe complètement et que la suppression des fichiers ne peut-être due que par exécution du php comme Bretus le suggère ?

Patrick

[Graimbault]

Bonjour rogerlenoir,

Est-ce que ça vaut le coup que je passe des heures pour me prouver que c'est possible, ou est-ce que je me trompe complètement et que la suppression des fichiers ne peut-être due que par exécution du php comme Bretus le suggère ?

Effacer des fichiers du serveur depuis la base de données... honnêtement je ne sais pas si c'est possible.

En revanche, je sais que la suppression des fichiers peut avoir différentes origines et que donc, l'exécution de code PHP peut en être une mais sûrement pas la seule! Comme tu le disais dans un précédent post, si le mot de passe de la BDD est le même que pour se connecter en FTP... bon ba là c'est archi simple! Même s'ils sont différents, si le couple utilisateur/mot de passe FTP est facile à deviner pour à bruteforcer (petite taille avec que des lettres minuscules): encore une fois c'est une porte d'entrée!

Il peut y avoir de multiples points d'entrée, par conséquent je ne te conseille pas de "passer des heures pour te prouver que c'est possible" mais plutôt de dépenser ses heures à passer en revue tous les points faibles apparants (et fréquents) des sites web.

PS: Il me semble qu'il est interdit (dans la loi) de stocker des mots de passe en clair dans une base de données. A confirmer...


Cordialement,

Graimbault

[rogerlenoir]

Merci Graimbault,

Je viens d'avoir confirmation, les mots de passe pour la bdd et le ftp étaient les mêmes (mdr)
C'est l'hébergeur qui gentiment vient de m'envoyer un mail pour me dire qu'il a changé les mdp et qu'ils sont à nouveau les mêmes (re-mdr)

je vais lui demander de changer ça

Maintenant que j'ai plus d'infos sur ce site je pense qu'on en a pas fini avec les failles ... vu le code.
De plus la base est hébergée sur le même serveur que le site (localhost) ... je n'aurai jamais pensé qu'un hébergeur pro fasse ça ...

En attendant que le développeur se réveille (c'est moins sur) je vais installer le script crawlprotect que j'ai trouvé sur ici et dont de nombreux clients d'ovh disent du bien.

Je vous tiens au courant de la suite et vous remercie tous

Patrick

[bretus]

Je viens d'avoir confirmation, les mots de passe pour la bdd et le ftp étaient les mêmes (mdr)
C'est l'hébergeur qui gentiment vient de m'envoyer un mail pour me dire qu'il a changé les mdp et qu'ils sont à nouveau les mêmes (re-mdr)

C'est pas ce qui me choque le plus, je ne pense pas que ça suffise... Assurez vous surtout qu'un utilisateur du site (dans la table des utilisateurs) n'aient pas le même de passe que la BDD ou le FTP.

PS : Vous n'avez pas accès aux logs pour voir ce qui s'est passé? Je commencerais par là perso, avec un peu de chance, il n'a pas pu les supprimer. Après, comme le dit Graimbault, il faut faire d'abord la chasse aux principales failles mais c'est assez titanesque sur du code non organisé... (vive MVC pour la revue de code!)

[rogerlenoir]

Voici les logs correspondant à l'attaque et relevés par l'hébergeur


196.206.63.223 - - [14/Apr/2013:00:01:22 +0200] "GET /fiche.php?id_equipe=41 HTTP/1.1" 200 1857 "http://is
oftwarez.com/scanner/scanner/" "Mozilla/5.0 (Windows NT 5.1; rv:21.0) Gecko/20100101 Firefox/21.0"

196.206.63.223 - - [14/Apr/2013:00:25:19 +0200] "GET /fiche.php?id_equipe=41+and+1%3D1 HTTP/1.1" 200 1857
"-" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727) Havij"

196.206.63.223 - - [14/Apr/2013:00:25:52 +0200] "GET /fiche.php?id_equipe=999999.9+union+all+select+0x3130
3235343830303536%2C0x31303235343830303536-- HTTP/1.1" 200 61 "-" "Mozilla/4.0 (compatible; MSIE 7.0; Windo
ws NT 5.1; SV1; .NET CLR 2.0.50727) Havij"

196.206.63.223 - - [14/Apr/2013:00:27:19 +0200] "GET /fiche.php?id_equipe=999999.9+union+all+select+0x3130
3235343830303536%2C%28select+concat%280x7e%2C0x27%2Cunhex%28Hex%28cast%28group_concat%28table_name%29+as+c
har%29%29%29%2C0x27%2C0x7e%29+from+%60information_schema%60.tables+where+table_schema%3D0x67646D6D32303131
%29%2C0x31303235343830303536%2C0x31303235343830303536%2C0x31303235343830303536%2C0x31303235343830303536%2C
0x31303235343830303536%2C0x31303235343830303536%2C0x31303235343830303536%2C0x31303235343830303536%2C0x3130
3235343830303536-- HTTP/1.1" 200 1969 "-" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; SV1; .NET CL
R 2.0.50727) Havij"
196.206.63.223 - - [14/Apr/2013:00:28:17 +0200] "GET /fiche.php?id_equipe=999999.9+union+all+select+0x3130
3235343830303536%2C%28select+distinct+concat%280x7e%2C0x27%2Cunhex%28Hex%28cast%28table_name+as+char%29%29
%29%2C0x27%2C0x7e%29+from+%60information_schema%60.tables+where+table_schema%3D0x67646D6D32303131+limit+17
%2C1%29%2C0x31303235343830303536%2C0x31303235343830303536%2C0x31303235343830303536%2C0x3130323534383030353
6%2C0x31303235343830303536%2C0x31303235343830303536%2C0x31303235343830303536%2C0x31303235343830303536%2C0x
31303235343830303536-- HTTP/1.1" 200 1309 "-" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; SV1; .NE
T CLR 2.0.50727) Havij"



196.206.63.223 - - [14/Apr/2013:00:28:18 +0200] "GET /admin/login.html HTTP/1.1" 404 - "-" "Mozilla/4.0 (c
ompatible; MSIE 7.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727) Havij"
196.206.63.223 - - [14/Apr/2013:00:28:18 +0200] "GET /admin/login.htm HTTP/1.1" 404 - "-" "Mozilla/4.0 (co
mpatible; MSIE 7.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727) Havij"
196.206.63.223 - - [14/Apr/2013:00:28:18 +0200] "GET /admin/home.php HTTP/1.1" 404 - "-" "Mozilla/4.0 (com
patible; MSIE 7.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727) Havij"
196.206.63.223 - - [14/Apr/2013:00:28:19 +0200] "GET /admin/controlpanel.html HTTP/1.1" 404 - "-" "Mozilla
/4.0 (compatible; MSIE 7.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727) Havij"
196.206.63.223 - - [14/Apr/2013:00:28:19 +0200] "GET /admin/home.asp HTTP/1.1" 404 - "-" "Mozilla/4.0 (com
patible; MSIE 7.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727) Havij"
196.206.63.223 - - [14/Apr/2013:00:28:20 +0200] "GET /admin/cp.php HTTP/1.1" 404 - "-" "Mozilla/4.0 (compa
tible; MSIE 7.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727) Havij"

[bretus]

Bonsoir,

Sans entrer dans le détail, un outil a scanné les vulnérabilités de votre site sur la page "fiche.php" et la variable "id_equipe".

PS : Je ne pense pas que ça soit une bonne idée de mettre le log ici. Désolé de m'être mal exprimé.

[rogerlenoir]

Bonjour,
Désolé j'ai du m'absenter un peu ...

Merci pour votre réponse. Oui j'avais bien compris comment le pirate était entré dans la base, ce que je ne comprends toujours pas c'est comment, à partir de là, a-t-il a pu effacer l'ensemble des fichiers déposés sur le serveur .

C'est vrai que j'aurai pu vous envoyer les logs en message privé (oups)

Patrick

[bretus]

Merci pour votre réponse. Oui j'avais bien compris comment le pirate était entré dans la base, ce que je ne comprends toujours pas c'est comment, à partir de là, a-t-il a pu effacer l'ensemble des fichiers déposés sur le serveur .

Est-ce que l'un des mots de passe de la table utilisateur correspondait au FTP? Si tu as le log FTP, regarde si quelqu'un s'y est connecté après 00:28 le 14...

Après, il y a d'autres possibilités... Il est peut-être possible de générer un fichier PHP à partir de MySQL par exemple (je ne savais pas que ça prenait de l'hexa pour les chaînes déjà, tout est possible après...)

Renseignes toi sur les failles PHP à éviter sur les sites de sécurité et passe en revue ton code : C'est pas dit que le prochain passe par le même chemin.

[rogerlenoir]

Bonjour (c'est le printemps chez moi, youpi !! ...)

Je n'ai pas accès au logs ftp et effectivement c'était une bonne idée que d'aller vérifier de ce coté là (mais je vais essayer de voir si je peux les avoir).

Les mots de passe utilisateurs n'étaient pas les mêmes que ceux utilisés pour le ftp.

En attendant, j'ai testé la séquence du pirate et la surcouche installée via crawlprotect bloque l'agression.

Pour ce qui est de la mise à disposition des logs à toute la communauté, je ne pense pas que ce soit dangereux pour le site en question puisque son adresse n'est pas présente.
Si tu penses que cela pose un problème malgré tout je demanderai à un modérateur de bien vouloir l'effacer.

Je fais encore quelques vérifs, j'installe le cryptage des mot de passe et puis j'empaquetterai le tout. Je ne pourrai pas tout vérifier en profondeur, je ne suis pas assez calé. (En cas de prochaine attaque je refilerai le bébé à un spécialiste, ou mieux je proposerai une refonte du site ... ce qui sera refusé puisqu'il a été réalisé y a 6 mois)

A+ pour la suite des évènements
Patrick

[rogerlenoir]

Je suis presque dans les temps !!!


Merci à tous ceux qui m'ont aidé dans cette aventure.

Patrick