Faille de sécurité dans Joomla : Remote Admin Password Change
Une très grosse faille de sécurité concernant le logiciel php Joomla vient d'être rendue publique. En effet, elle est très facilement exploitable et permet d'accéder à l'interface d'administration de n'importe quel site utilisant ce cms en version inférieur à la 1.5.6.
1. La solution pour protéger son site web
La meilleure solution pour contrer cette faille de sécurité est de mettre à jour votre version de joomla avec la version la plus récente proposée sur le site officiel : www.joomla.org
2. Exploitation de la faille et explication
Pour exploiter cette faille, il suffit d'appeler l'url du site cible (adaptez target.com par le nom du site) :
http://target.com/index.php?option=com_user&view=reset&layout=confirm
Le site va alors vous proposer de réinitialiser le mot de passe administrateur et vous demander d'entrer un jeton (si vous avez le message “Vous n'êtes pas autorisé(e) à accéder à cette ressource” c'est qu'il s'agit d'une version 1.0.x de Joomla et que la faille ne marchera pas).
En théorie, ce petit bout de code est fourni par mail, lorsque l'administrateur clique sur "j'ai oublié mon mot de passe". Le problème ici, c'est qu'il existe une faille dans le code et si l'on rentre le caractère apostrophe (') :
... dans le champ du formulaire, Joomla vous propose de saisir un nouveau mot de passe administrateur :
Il est alors possible pour un hacker de mettre son propre mot de passe et ensuite se connecter à l'interface d'administration en utilisant l'url :
http://target.com/administrator/
Pour comprendre la faille de sécurité, il faut se rendre dans le fichier /components/com_user/models/reset.php à la ligne contenant ce code :
SELECT id FROM #__users WHERE block = 0 AND activation = '.$db->Quote($token)
Lorsque l'on fait une demande de réinitialisation de mot de passe et que l'on fournit notre jeton spécial (apostrophe), la requête SQL suivante est alors exécutée :
SELECT id FROM jos_users WHERE block = 0 AND activation = ''
Bref, si vous utilisez Joomla, je vous conseille de faire attention et de le mettre à jour rapidement.
Créé en 2005, Tux-planet est un site qui a pour ambition de regrouper des articles sur Linux et le monde des logiciels libres. 
31 Commentaires pour "Faille de sécurité dans Joomla : Remote Admin Password Change"
Flux des commentaires de cet article Ajouter un commentaireJ'ai pas testé, j'utilise pas Joomla, mais je comprends le principe de l'injection SQL.. et pour un CMS tel que Joomla, qui est je pense utilisé par pas mal de sites (de séries, en l'occurence) ça peut faire des dégâts..
Tu as testé sur un de tes sites j'espère ?
T'aimerais pas te retrouver avec ton espace admin contrôlé par un autre je parie
Bien vu ! C'est hallucinant mais je ne comprends pas pourquoi htmlentities() et mysql_real_escape_string() ne sont pas utilisées systématiquement...
La faille a-t-elle déjà été corrigée ? Tous les sites où j'ai tenté cette faille m'affichent ce même message :
Vous n'êtes pas autorisé(e) à accéder à cette ressource.
Vous devez vous connecter.
Vous devez vous identifier.
Bref, tant mieux.
@pickupjojo et @GamaniaK : j'ai testé sur des sites dont j'ai la responsabilité. Et ça fonctionne sans problème sur certain et j'ai le même message d'erreur que pickupjojo pour d'autre.
Je ne sais pas si elle a été corrigé donc, peut-être que le message "Vous n'êtes pas autorisé(e)" apparaît sur des configurations spéciales de Joomla.
En tous les cas, a mon avis il suffit d'utiliser la fonction php addslashes dans le code SQL pour corriger cela temporairement :
En faite, je confirme, c'est pas corrigé comme faille. Je viens de télécharger la dernière version stable (1.5.5) sur le site officiel et le code est le même que celui cité dans l'article.
Faille corrigée sur tous les sites que j'ai testé !
@pickupjojo et @weetabix : voilà je pense avoir trouvé, le message d'erreur "Vous n'êtes pas autorisé(e) à accéder à cette ressource" s'affiche si on essaye d'exploiter la faille sur un Joomla 1.0.x. Je vais mettre l'article à jour.
Une confirmation par mail avec un "code chiffré " dans l'url, ça n'aurait pas mangé de pain! je ne vois pas pourquoi on utilise pas ça ! avec un tel CMS.
Merci pour l'info.
Une nouvelle version de joomla vient d'être publié aujourd'hui (sont très réactif au passage), c'est la version 1.5.6 et elle corrige la faille.
En gros, ils ont modifier le fichier /components/com_user/models/reset.php en ajoutant ce code à la ligne 113, après le global $mainframe :
Perso, j'ai pas trop compris, le coup du test de la longueur du token, mais bon, c'est eux les experts.
ça me paraît bien léger comme correctif. J'espère que $token est filtré des commentaires SQL sinon un truc du genre : ' -- 32 caractères de commentaires en tant que token aura le même effet...
@Damien : ben oui justement, c'est cela que je ne comprends pas. Je m'attendais à un truc qui échappe les simples quotes, là on a une vérification de la longueur du token. C'est super bizarre, mais peut-être que cela fonctionne.
Sinon le CERTA vient de publier une alerte comme quoi la faille commençait déjà à être exploitée à grande échelle. Je plains les webmasters qui sont en vacances ....
Il y a même une autre possibilité tout aussi marrante pour exploiter la faille : désactivez le javascript de votre navigateur puis cliquez sur "Envoyer" sans rien entrer dans le champ "Code de vérification" ...
@pti-seb & @Damien :
Pour être un peu plus précis, le test de la longueur du token est suffisant dans le sens ou :
- Lors de la saisie du token par l'utilisateur, une fonction retire l'ensemble des caractères non alphanumériques (par conséquent la faille fonctionne également si vous rentrez n'importe quel caractère spécial).
- Une fois le traitement effectué, le contenu de la variable est echapée, et utilisé dans la requete sql.
Or si l'utilisateur n'as pas demandé de reset de son mot de passe la colonne "activation" est vide donc la requete ne pourra pas aboutir (vu qu'après l'application du patch il est nécessaire d'avoir un token d'une longueur de 32 caractères "valides" == alphanumériques ).
En espérant que cette explication aura été suffisamment claire
@Alexandre DE DOMMELIN : merci pour l'explication.
Sympathique la faille. Vite ! à vos mise à jour
Cette faille ne fonctionne pas sur un site utilisant le composant d'URL rewriting SmartSef, car il ré-écrit directement l'URL lorsqu'on clique pour valider le code jeton, on arrive alors sur une page d'erreur.
Un site que je gère a été piraté le 15 août. La page d'accueil a été changée et affiche actuellement une page en turc. La mise à jour 1.5.6 rétablira-t-elle la bonne page ?
Oui pour être une faille bien s'en est une grosse même....
@olivier834 : aucune idée. Cela dépend si les hacker l'ont effacé, ou si ils l'ont sauvegardé avant (cela se fait souvent). En tous les cas, il faut que tu mette à jour ton Joomla, ça c'est certain.
Personnelement je ne connaissais pas la faille, et je viens de me faire attaquer par quelqu'un de particulièrement sympa !
Sur une des plate-formes dont je suis responsable quelqu'un a utilisé la faille pour changer ma page d'accueil en me signalant que ma plate-forme n'était pas à jour et en m'inscitant à venir visiter ce site.
Pour reprendre la main sur ma plate-forme j'ai expérimenté la technique qui marche trés bien au passage !
J'ai upgradé ma plate-forme, espérons qu'il n'y ai pas d'autre faille et merci au gentil hacker.
@skateurinthedark : tu as de la chance, certaines personnes sont parfois très mal intentionné et en profite pour defacer l'intégralité du site, voir effacer les fichiers.
J'ai essayé sur un site crée avec la bêta de la 1.5...et cela ne marche pas !
Quand je tape l'adresse, j'obtiens:
"Bienvenue dans la section utilisateur de votre site ! "
Pourtant c'est un vieille version de Joomla et...bêta !
@Bekcs : cet exploit ne marche peut-être que pour la version stable ...
Faille toujours active, j'ai recenser plus de 200 site touchés avec une petite recherche google maison (et un outil fait main :p) et c'est hallucinant le nombre de site n'ayant pas pris la mise à jour, le plus marrant sont les sites de web agency qui se disent conseiller en audit sécurité lol!!! Pour l'URL rewrinting ca marche, maintenant il faut bien chercher
J'ai lu sur Reaweb.fr que les sites présentant cette faille pouvait être recherché facilement grâce à google. je me rappelle plus la syntaxe mais ca fait peur quand on voit que google en afiche des pages et des pages.
En faite si tu veux, ce n'est pas très dur, sois tu décortique les pages de joomla, sois tu tape la version en cherchant bien la phrase type et bingo ^^
Bonjour, voilà je gere un site qui aurait été piraté avec l'erreur 403 que dois je faire pour réctifier le problème
@mayzz : une seule solution, mettre à jour ton Joomla.
bonjour
j'ai exactement le même problème sur mon site joomla 1.5.14, svp indiquez moi comment faire pour supprimer cette faille de sécurité.
merci
en supprimant le fichier reset, plus aucun moyen de s'attaquer à cette faille...
Hahahahah Y'as pas. D'autre Faille Pks j'en ai Besoin ;D