Clarification sur les inexactitudes du rapport de Checkpoint.

Un rapport de Check Point Research a été porté à notre attention concernant une faille de sécurité qui avait été corrigée en décembre 2015. Ce rapport a également été repris par Threat Post.

Les deux rapports contiennent de nombreuses inexactitudes et laisseraient entendre que la vulnérabilité détaillée est actuelle.
Cette déclaration sert à clarifier les faits relatif à cette question. De plus, nous voudrions assurer à notre base d'utilisateurs que, même si ces publications tentent d'affirmer qu'il s'agit d'un problème d'actualité, la vérité est loin de là.

Dans cet esprit, nous aimerions clarifier quelques points:

• Il n'y a pas de problème de sécurité actuel avec la classe JMail.
• Le problème sous-jacent, utilisé pour créer et stocker la porte dérobée (backdoor), est un problème de PHP plutôt que de Joomla.
• Une attaque réussie n’est possible qu’avec des versions de PHP et Joomla extrêmement obsolètes et datant de plus de 3 ans (les versions de PHP 5.4.45, 5.5.29, 5.6.13 et toutes les versions supérieures sont corrigées pour cette vulnérabilité). Veuillez consulter notre article récent sur l'importance de maintenir vos sites à jour ici.
• Des mesures d'atténuation pour Joomla 1.5, 2.5 et 3 ont été publiées il y a plus de 3 ans en décembre 2015. Des correctifs pour les versions EOL ont été publiés parallèlement à la version 3.4.7 de Joomla. Les correctifs pour les autres versions de Joomla sont toujours disponibles ici. Le projet Joomla a également distribué des règles WAF à de nombreux fournisseurs d’hébergement mutualisés au moment de la découverte afin de se protéger contre les exploits courants de cette vulnérabilité.
• Le fichier mentionné dans le rapport de Check Point n'est pas un fichier du noyau Joomla, il s'agit d'une copie de la classe d'origine utilisée par l'attaquant pour masquer une porte dérobée.
• Le fichier ne "remplace" pas la classe principale JMail.

Plus d'informations sur l'exploit

Le modèle décrit par Check Point est un classique : un attaquant exploite un problème de sécurité connu. Le problème date de plus de 3 ans et provient d'un problème de sécurité trouvé dans PHP, plutôt que du noyau de Joomla. Plus d'informations sur cette question peuvent être trouvées ici :

• https://developer.joomla.org/security-centre/639-20151206-core-session-hardening.html
• https://bugs.php.net/bug.php?id=70219

En exploitant ce problème, un attaquant peut incorporer une porte dérobée dans un site, qui peut être utilisée pour des activités malveillantes. Afin de rendre la détection aussi difficile que possible, les attaquants utilisent souvent des copies de fichiers d'application réels (dans ce cas, une copie de la classe de diffusion de Joomla) pour intégrer leur code d'exploitation. Ces copies ne seront jamais utilisées lors de l'exécution normale d'une application. Par conséquent, il n'y a pas de "substitution" comme indiqué dans le rapport; elles ont simplement utilisé le fichier pour masquer la porte dérobée.