ALERTE: TRES IMPORTANT

[diety]

Comme dit par l'auteur, pour empêcher l'expoitation de ce script, il suffit d'utiliser le safe mode de PHP ou plus simplement d'après cette page de désactiver la fonction proc_open() de php.

Peut-etre.
En général, activer le save_mode sous php restreint les possibilités de créer des répertoires, des fichiers, l'écriture etc. C'est une bonne chose. Concevoir un CMS avec safe_mode activé demande plus de rigueur aux concepteurs/programmeurs.

Maintenant il faudrait savoir si ce CMS ici-présent est conçu pour fonctionner avec save_mode activé ou pas. S'il l'est, c'est bon. S'il ne l'est pas, il y a de forte chances que, save_mode activé, il rencontrera des problèmes pour fonctionner normalement.

Juste désactiver la fonction proc_open(..) me paraît déjà moins risqué, et encore. Si le PostNuke (ou comment s'appelle le CMS ici?) en a besoin, encore problème. De toute façon, on s'en aperçevra rapidement, on peut toujours essayer.

Sur la même page sur le safe_mode, on lit aussi une remarque pertinente:

Note that safe mode is largely useless. Most ISPs that offer Php also offer other scripting languages (mostly Perl), and these other languages don't have the equivalent of PHP.
In other words, if PHP's safe mode won't allow vandals into your web presence, they will simply use Perl.

Je traduis: La plupart des hébergeurs qui offrent PHP offrent aussi d'autres langages dont Perl qui n'ont pas l'équivalent de PHP. Autrement dit: si le safe_mode pour PHP est activé, quelque vandale va simplement utiliser Perl.

[tux12]

Juste désactiver la fonction proc_open(..) me paraît déjà moins risqué, et encore. Si le PostNuke (ou comment s'appelle le CMS ici?) en a besoin, encore problème. De toute façon, on s'en aperçevra rapidement, on peut toujours essayer.

On est d'accord. Juste une piste je disais.

Dans tous les cas ça ne nous dit toujours pas comment le script à été injecté sur le serveur. Une vulnérabilité du PostNuke?
J'ai trouvé une page de liens vers des scanners de vulnérabilités qui permettraient de tester le code du site.

Merci Diety pour ces précisions

[diety]

Dans tous les cas ça ne nous dit toujours pas comment le script à été injecté sur le serveur. Une vulnérabilité du PostNuke?

Je me suis posé la même question. Je pense que oui.

C'est des amateurs (dans le sens passionnés) qui scrutent le code de divers CMS pour trouver une entrée, puis ensuite ils n'ont que l'embarras du choix, car ces logiciels sont très largement utilisés.

Une fois j'ai eu un problème semblable, j'avais un forum php dont la maintenance a été arrêté (donc plus de mises à jour), et c'était par un champ d'un formulaire qu'ils avaient réussi à écrire sur le serveur - passage du code php à une variable du formulaire qui "abusait" d'une fonction php mal sécurisée, donc ils connaissait parfaitement la faille du forum. (Ils avaient installé carrément un outil d'administration à distance avec interface graphique pour hackers, puis ils ont "fait leur vie chez moi" les salauds. )

J'ai découvert le désastre par un message de mon hébergeur ("votre domaine est désormais sur une liste noire de spammers, veuillez régler le problème rapidement sinon on résilie le contrat...") J'ai fait le ménage, et le comble: impossibilité d'éffacer "leurs" fichiers car ils étaient "propriétaire". J'étais admiratif de leur travail. Bon on apprend toujours.

Merci pour la page de "scanner de vulnérabilité", c'est intéressant!

[tristesir]

Autre piste:
La version de Postnuke utilisée par Actu semble être 0.7.2.6
Mais en se rendant sur le site de Postnuke on s'aperçoit que la dernière version stable est 0.7.6.4 (qui date du 20/11/2006) et une version 8.00 est pressentie comme RC (candidate release)

Je suppose que phpbb n'est pas mis à jour non plus.

[Monolecte]

Merci pour les infos!

[tristesir]

Par curiosité j'ai fait un passage sur un des autres sites infectés et j'ai constaté, sauf erreur, que les cybercriminels avaient changé le script ou en avait ajouté un autre.