Bonjour,

un de mes clients a une vieille version de mambo pour son site.
(pour tous ceux qui me diront : il n'a qu'à mettre la nouvelle version, je le sais bien mais ça prend du temps, donc de l'argent qu'il ne veut pas investir alors que le site est en projet de refonte.
Pour info, il a une version 4.5). Je ne sais pas vraiment si une mise à jour est aisée. La dernière release est la version 4.6.2)
Après recherche, les patchs ne sont plus disponibles (il semblerait que la version 4.5 1.0.5 date de 2004 )


Il m'a confié son site, développé par la belle-mère de la cousine de sa femme
Je m'occupe de faire survivre son site avant sa refonte, MAIS...

Il vient de se faire attaquer et s'est retrouvé avec une nouvelle page d'accueil
pour info, il a un hébergement mutualisé OVH.



Si j'ai bien compris, la variable register_globals étant à ON, l'attaquant a pu passer des variables au script via l'URL.

Je lui ai remis son site d'aplomb en mettant de le .htaccess :
SetEnv REGISTER_GLOBALS 0

Mais j'aurai aimé tester l'attaque précédente pour vérifier cette bidouille.
Mais il me semble que le log me donne l'url incomplète...

C'est suffisant.

Ensuite, si tu ajoutes la fin du fichier .htaccess (les 10 lignes) les lignes suivantes, ça devrait aller :

########## Begin - Rewrite rules to block out some common exploits
## If you experience problems on your site block out the operations listed below
## This attempts to block the most common type of exploit `attempts` to Joomla!
#
# Block out any script trying to set a mosConfig value through the URL
RewriteCond %{QUERY_STRING} mosConfig_[a-zA-Z_]{1,21}(=|\%3D) [OR]
# Block out any script trying to base64_encode crap to send via URL
RewriteCond %{QUERY_STRING} base64_encode.*\(.*\) [OR]
# Block out any script that includes a <script> tag in URL
RewriteCond %{QUERY_STRING} (\<|%3C).*script.*(\>|%3E) [NC,OR]
# Block out any script trying to set a PHP GLOBALS variable via URL
RewriteCond %{QUERY_STRING} GLOBALS(=|\[|\%[0-9A-Z]{0,2}) [OR]
# Block out any script trying to modify a _REQUEST variable via URL
RewriteCond %{QUERY_STRING} _REQUEST(=|\[|\%[0-9A-Z]{0,2})
# Send all blocked request to homepage with 403 Forbidden error!
RewriteRule ^(.*)$ index.php [F,L]
#
########## End - Rewrite rules to block out some common exploits

merci pour les infos.

J'ai réagi trop vite.
Comme le site fonctionne à nouveau, mon client a encore décalé la refonte du site !

Si j'avais su, j'aurais remercié les hackers... et j'aurais dit que cette version de mambo était vraiment trop vieille.

oui t'as été trop rapide lucky lucke ;-)

Dans un pareil cas, c'est toujours bon pour la compréhension de la situation que le client reste un peu dans son jus...

Quand on joue l'ange gardien pour ses clients, et que cela se fait sans qu'il en aie pleinement conscience, il ne peut pas accorder de valeur a vos actes puisqu'il n'a rien vu passer

Ce qui m'amuse lorsque que je reçois des appels d'offres, c'est les contraintes imposés pour le choix d'un CMS, et on trouve souvent :

1. fonctionnalités, parmi celles dont on a besoin, il en faut le plus possible, y compris et surtout la possibilité d'avoir une IHM au top niveau,
2. stabilité et robustesse, sans cela, on ne peut pas développer des compléments ni faire de paramétrages en confiance,
3. modularité, pour pouvoir gérer des mises à jour et segmenter les problèmes, respecter la charte de codage et documenter son code,
4. communauté, si il n'y a personne pour soutenir le projet et y contribuer alors il n'a pas d'intérêt. Les innovations vont beaucoup trop vite,
5. licence libre : la possibilité juridique de l'utiliser et le modifier sans avoir de droits à payer.

Alors que l'on sait à l'avance que les mises à jours ne seront jamais faites, ou uniquement quand comme ton client il y a un problème. Ne nous leurrons pas, les clients ont souvent tendance à appliquer le précepte “Tant que cela marche, je ne touche plus”, certes, mais internet n’est pas figé et certaines personnes disposent du temps nécessaire pour chercher à nuire gratuitement.

Par contre, tu peux argumenter que comme il y a un petit malin qui à déjà pirater son site et que mambo commence sérieusement à être ancien, et que toi tu as corrigé uniquement la faille pour cette intrusion, le pirate ou d'autres peuvent recommencer avec d'autres failles, et oui, cette faille n'était certainement pas la seule.

Par défaut, lorsqu'une nouvelle version est disponible, je refuse de passer les correctifs, je propose directement la migration, si le client refuse, je le mets en garde dans la commande j'inclus une clause indiquant qu'il ne peut me rendre responsable de ne pas avoir fait le nécessaire pour sécuriser son site