Les systèmes de gestion de contenu sont ce que vous choisissez lorsque vous ne souhaitez pas créer et administrer un tout nouveau front et backend pour un site Web et si vos créateurs de contenu ne sont pas familiarisés avec le développement de code source. Lors de l'exécution de votre CMS Joomla, de nouvelles exigences en matière de fonctionnalité ou de conception pourraient survenir de votre part ou de celle de vos utilisateurs. Le moyen rapide et facile est d'installer un plugin qui fera la magie. Mais cela peut conduire à de nouvelles vulnérabilités dans votre système. En particulier, les téléchargements de fichiers sont un vecteur d'attaque possible. Dans cet article, nous parlerons des vulnérabilités via les fichiers et les plugins.
1. Sécurité du CMS Joomla : 3 faits qu'un développeur doit savoir
Lorsque vous développez et contribuez à un projet open source, vous devez suivre les meilleures pratiques, veiller à la sécurité, à l'interopérabilité et à la possibilité de code obsolète. Il existe des moyens d'atteindre ces objectifs. La première étape pour un bon morceau de code est de le vérifier pour les bibliothèques obsolètes et les vulnérabilités connues. Vous pouvez le faire à la main ou le vérifier avec une analyse de code statique comme RIPS, qui fait maintenant partie de SonarCube. Vous devriez également vérifier votre code à l'aide de CVE si possible. De plus, vous pourriez également être une cible pour les pirates si vous développez des plugins pour CMS. Comment? Si la qualité de votre code n'est pas à la pointe de la technologie en matière de sécurité et de vulnérabilités, votre travail acharné pourrait devenir un point d'entrée pour une Supply Chain Attack[1]. En dehors de ces deux faits, vous devez toujours connaître vos configurations. Le meilleur code et les plugins les plus sûrs ne peuvent pas vous sauver des conséquences d'une mauvaise configuration. Alors maintenant, vous pouvez vous demander : « Que faire de ces responsabilités lors du développement et de l'utilisation de plugins ? » Nous y reviendrons plus loin dans l'article après une introduction des vulnérabilités les plus courantes dans le téléchargement de fichiers. Parce que c'est une chose que vous ne pouvez pas contrôler lorsque vous utilisez un CMS avec plus d'un participant.
2. Vulnérabilités courantes et téléchargements de fichiers
Aucun système ne devrait s'appuyer sur la sécurité par l'obscurité. En particulier, un projet open source tel que Joomla offre la possibilité d'analyser la source et d'abuser du code vulnérable. Comme pour tout type de téléchargement de fichiers d'entrée utilisateur, il s'agit d'un vecteur d'attaque potentiel. Joomla offre la possibilité de télécharger des fichiers pour les utilisateurs autorisés en utilisant le gestionnaire de médias. Par défaut, les rôles d'utilisateur tels que Gestionnaire et Administrateur sont autorisés à télécharger. Outre les rôles par défaut, les rôles et groupes personnalisés avec les droits associés sont également préoccupants. L'Open Web Application Security Project (OWASP) souligne que les conséquences peuvent varier. Des exemples de conséquences sont une prise de contrôle complète du système, une surcharge de la base de données/système de fichiers, des attaques côté client ou des attaques côté serveur. L'OWASP distingue deux classes de problèmes [2]. La première classe se compose de problèmes de métadonnées de fichier, par exemple, le chemin d'accès au fichier stocké ou le nom du fichier en général. La deuxième classe contient des problèmes avec le contenu ou la taille du fichier.
Un exemple célèbre est la faille ImageMagick également connue sous le nom d'ImageTragick. ImageMagick est largement utilisé comme bibliothèque de traitement d'images et comme base de liaisons spécifiques au langage, y compris PHP imagick, rmagick et paperclip de Ruby, et imagemagick[3] de nodejs. Ainsi, le traitement des images sur le Web utilise le plus souvent cette bibliothèque. En 2016, une vulnérabilité grave a été trouvée, qui a permis l'exécution de code à distance ( CVE-2016-3714 ). L'extension Joomla à cette époque (Joomla 3.5) qui utilisait le populaire ImageMagick au lieu de la bibliothèque graphique GD aurait pu être affectée par cette découverte, en faisant confiance à une bibliothèque tierce, pour être honnête, bien établie.
Le deuxième exemple concerne une grave vulnérabilité Joomla découverte en 2015. David Jardin, le chef d'équipe de la Security Strike Team, a donné une conférence intéressante à ce sujet. Cette vulnérabilité est une chaîne créative d'attaques. La première attaque est une injection d'objet PHP. Un bogue dans PHP transforme les données de session invalides en quelque chose que PHP considère comme valide. Cela permettait à un attaquant de manipuler des données de session et donc d'injecter des objets falsifiés dans une session sérialisée. En utilisant le gestionnaire de déconnexion Joomla qui est appelé après la fin d'une requête, l'attaquant a pu exploiter une fonction d'initialisation d'un objet d'une bibliothèque appelée SimplePie, qui n'est plus utilisée. SimplePie a analysé une chaîne en tant qu'URL tant que la chaîne contient des guillemets doubles, sans générer d'erreur ni d'avertissement. La chaîne dans ce cas était du code PHP. SimplePie a également utilisé certaines fonctions de mise en cache, qui utilisaient la fonction PHP assert. Assert exécute ensuite le code. Cela se termine par un attaquant pouvant fournir une charge utile de requête falsifiée qui est décodée puis exécutée. Ceci est également appelé exécution de code à distance.
Les téléchargements de fichiers sont des vecteurs d'attaque potentiels. Le renforcement de la sécurité des entrées de l'utilisateur, par exemple des images, des fichiers texte, etc., est inestimable et absolument nécessaire. La version Joomla 4.0 comprend un remake du gestionnaire de médias. Une toute nouvelle interface utilisateur, un ensemble supplémentaire de fonctionnalités intéressantes et un défi du point de vue de la sécurité. Dans le cadre des Semaines de programmation Web de l'Université des sciences appliquées de Mittelhessen, nous avons essayé de mettre à l'épreuve la fonction de téléchargement du gestionnaire de médias. Chapeau, Joomla ! Tu as gagné cette fois. Nous avons essayé des attaques XSS, des bombes de fichiers, encodant du code malveillant dans des fichiers image, etc., mais rien d'utile n'en est sorti. Ou l'a-t-il fait ?
Globalement, le noyau Joomla semble vraiment sûr, et la réalité montre qu'il est rare d'identifier des vulnérabilités graves et il est encore plus rare que les vulnérabilités endommagent les utilisateurs avant que la JSST n'ait le temps de réagir. Mais qu'en est-il des fonctionnalités qui ne sont pas dans le noyau ?
3. Le problème de responsabilité des plugins et des dépendances
De nos jours, tout le monde est à la recherche des fonctionnalités, des fonctionnalités et des conceptions les plus récentes, les meilleures et les plus sophistiquées. Les utilisateurs de systèmes de gestion de contenu ne s'excluent pas de ces exigences. Mais l'intégration de toutes les exigences possibles est impossible pour les projets de base dans le CMS-World. La solution est commune : les plugins. Les administrateurs peuvent installer tous les plugins avec lesquels leurs utilisateurs souhaitent travailler. Cette option apporte beaucoup de personnalisation individuelle et encore plus de responsabilité. Alors que le projet Joomla-cms est continuellement développé, testé et révisé, les plugins hors du projet ne le sont pas nécessairement. En bref, chaque plugin pourrait provoquer une menace possible pour la sécurité d'une installation Joomla en cours d'exécution. Dans cet esprit, l'équipe de sécurité de Joomla a essayé de mettre en œuvre un mécanisme de vérification pour tester les plugins. En utilisant RIPS, qui fait maintenant partie de SonarCube, ils ont effectué une analyse de code statique avec les plugins. Du fait que chaque plugin peut être implémenté par quelqu'un qui n'a pas le temps ou les connaissances nécessaires pour suivre les meilleures pratiques de développement continu, les plugins peuvent contenir des bibliothèques obsolètes. Le code obsolète peut ou non inclure des exploits. Les plugins pourraient également ne pas être bien écrits en termes de temps d'exécution, de performances et d'efficacité. Tout cela peut conduire à des résultats lors de l'exécution d'une analyse de code. Néanmoins, cela pourrait également conduire à de nombreux résultats faussement positifs. Ainsi, le problème général est la masse des résultats faussement positifs qui conduit à un besoin de révision. L'examen doit être fait à la main pour comprendre ce que le programmeur a fait. Ni l'équipe d'attaque de sécurité de Joomla ni la communauté de base active n'ont la capacité de faire de tels examens sur chaque plugin qui a une conclusion. Maintenant, la question demeure, à qui incombe la responsabilité de la sécurité des plugins ? Bref, le vôtre. Si vous êtes l'administrateur d'une apparence Web basée sur Joomla, il est de votre responsabilité d'installer les plugins que vous installez et les conséquences sont également les vôtres. Une solution pour des plugins sûrs et bien écrits, sans une quantité de travail de révision impossible, pourrait être une vérification décentralisée. S'il y avait un moyen de donner un lot de plugins sûrs et bien écrits, cela marquerait leur qualité, les administrateurs ne seraient-ils pas impatients de les utiliser ? Cela nous amène à l'idée d'un vérificateur de plugin. Le vérificateur de plugin serait intégré comme une application Web, où tout le monde pourrait télécharger ses plugins, pour subir une vérification des bibliothèques obsolètes, des exploits, etc. Une analyse de code en ligne. Si un plugin réussissait le contrôle, il pouvait être admis dans une liste de plugins recommandés. Les plugins de la liste seraient vérifiés régulièrement par une tâche cron. En cas de non-respect de la recommandation, le téléchargeur serait informé par e-mail. L'idée est donc de faire des réalisations de sécurité pour les développeurs.
4. Vérification et validation intégrées des fichiers
La fonction de téléchargement de fichiers et sa capacité de vérification et de validation des fichiers sont historiquement développées. Les premières versions ne vérifiaient que les extensions de fichiers. Les formats connus tels que .png, .jpg, .gif, etc., ont été vérifiés. Plus tard, la vérification du type mime a été ajoutée. Mais la vérification du type mime est une arme à deux tranchants. Il est certainement utile d'avoir une valeur supplémentaire à vérifier pour déterminer le format de fichier, mais en réalité, la vérification du type mime est un jeu de devinettes et on ne peut pas toujours se fier aux résultats. C'est la réalisation est venu de l'expérience. Joomla avait une vulnérabilité qui activait XSS. Cette vulnérabilité était une interprétation incohérente des types mime. L'application PHP a interprété un fichier comme PNG, tout comme le serveur Web. Mais le navigateur a interprété le fichier comme JavaScript. Le fichier était un fichier JavaScript falsifié, qui ressemblait à un PNG. Rétrospectivement et avec la connaissance des meilleures pratiques de sécurité modernes, nous avons pu évaluer chaque type d'extension autorisé par défaut. La conclusion est que les extensions par défaut sont une sélection sécurisée de types d'extensions.
Il est toujours possible de tromper le mécanisme de vérification d'extension et de mime en forgeant des fichiers, qui sont constitués du nombre magique et de l'extension de fichier correspondante. Mais nous pensons, en raison du contexte de sécurité du gestionnaire de médias, que ce n'est pas problématique. Cela ne conduit qu'à des fichiers image cassés enregistrés dans le dossier /images de l'installation de Joomla. Nous avons essayé d'utiliser les fichiers d'une manière ou d'une autre, mais les en-têtes de sécurité du navigateur, le système de rôle Joomla, etc., nous ont empêchés de faire quoi que ce soit de significatif. En figue. 2 l'attaque est illustrée. L'idée était qu'un attaquant télécharge une image. En utilisant un lanceur d'attaque, l'administrateur charge l'image située dans /images. A noter que le chemin de l'image est prédéterminé puisque le nom de fichier reste le même. L'image est décodée et le code est exécuté. Et bien, ça n'a pas marché, tant mieux pour Joomla !
Les SVG sont une chose importante. SVG est un langage de balisage complexe basé sur XML. Il est utilisé pour décrire des graphiques vectoriels en deux dimensions. Mais il est également possible d'inclure des balises HTML script¿. Cela conduit à d'éventuelles injections de XSS. Si le SVG est nettoyé, par exemple, les balises script¿ sont supprimées, l'injection HTML pourrait toujours être possible. Comme si cela ne suffisait pas, les SVG nous permettent également de faire l'attaque du milliard de rires en utilisant XML Entity Processing. Un déni de service à emporter. « Les SVG ne sont pas que des images, mais des mini-applications » [4].
5. À emporter
5.1 Vulnérabilités antérieures : leçons apprises
Nous avons expliqué la vulnérabilité Joomla RCE dans la section 2. La JSST a évalué le processus de gestion de cette vulnérabilité particulière et a souligné trois réalisations comme leçons apprises.
La créativité
La créativité des attaquants est bilatérale. Le premier côté est l'exploration initiale d'une vulnérabilité potentielle. Cela exige souvent une bonne base de compétences en informatique, telles que les spécificités linguistiques, les connaissances en sécurité et la connaissance des applications ou du domaine. Cela permet à un attaquant de trouver différentes petites choses à utiliser comme vecteur d'attaque. En enchaînant ces découvertes, l'attaquant peut créer de puissants exploits. L'autre côté, ce sont les imitateurs. Ils apprennent en quelque sorte l'existence de cet exploit et l'appliquent simplement, le plus souvent sans même comprendre pourquoi cela fonctionne.
La coopération
Pour protéger les utilisateurs, les équipes de sécurité et les hébergeurs Web doivent travailler ensemble. Informer les hébergeurs Web des problèmes de sécurité est une tâche de la JSST.
La vitesse
Les utilisateurs ont environ 8 à 10 heures pour effectuer le correctif après la publication d'un correctif de sécurité. Habituellement, une grosse vague d'attaques démarre après cette estimation et tous ceux qui ne corrigent pas à temps sont vulnérables.
5.2 Pull-Requests et sécurité
Outre l'application typique de la règle des deux personnes, par exemple, plusieurs personnes examinant un PR, le pipeline GitHub effectue une analyse statique du code source pour les vulnérabilités, via RIPS. Le pipeline échoue si des erreurs de sécurité majeures sont implémentées. C'est encore une autre couche de sécurité, donc des choses dont vous ne pouvez pas vous passer.
5.3 Quelle est la prochaine étape ?
Depuis le rachat de RIPS par SonarCube, une évaluation de ce dernier est en cours. Mais il est toujours difficile de s'adapter aux nouvelles technologies. La base de code Joomla est assez volumineuse, c'est-à-dire plus ou moins 430000 lignes de code PHP et 49500 lignes de code JavaScript, les résultats faussement positifs sont difficiles à éviter. Mais pour prendre au sérieux toutes les vulnérabilités possibles, il faut examiner les résultats des découvertes. L'une des tâches de la JSST est de rendre ces outils applicables, réalistes et utiles, ce qui est un processus continu.
Une autre tâche importante est la mise en œuvre d'un concept de prévention des attaques de la chaîne d'approvisionnement. Une attaque de la chaîne d'approvisionnement cible le réseau de distribution. Quelqu'un pourrait modifier un composant de confiance dans la chaîne d'approvisionnement. Ces modifications pourraient altérer le produit résultant. Dans le cas des systèmes d'information, il peut s'agir d'une bibliothèque de fournisseurs utilisée comme dépendance dans Joomla. Le cadre de mise à jour (TUF) est un cadre et une spécification. En adoptant TUF, Joomla pourrait mettre en œuvre avec succès un système de prévention des attaques de la chaîne d'approvisionnement, ce qui nous permet à son tour de passer à l'étape suivante : un système de mise à jour automatique sécurisé pour Joomla.
Les références
[1] Qu'est-ce qu'une attaque de chaîne d'approvisionnement ? — Logiciel Check Point . (visité le 26/08/2021).
[2] Téléchargement de fichiers illimité — OWASP . (visité le 24/08/2021) .
[3] ImageTragick . (visited on 08/25/2021).
[4] Mario Heiderich. L'image qui m'a appelé - Injection de contenu actif avec des fichiers SVG .
