Admin Tools pour Joomla! - Bulletin de sécurité, Mai 2018

Résumé

Il existe deux problèmes de divulgation d'informations étroitement liés dans Admin Tools. L'installation de la version 5.1.0 s'adressera aux deux. La plupart des sites ne peuvent pas être piratés à distance mais divulgueront très probablement des informations privilégiées à un pirate qui s'est déjà infiltré sur le site. Les personnes coincées dans des versions plus anciennes devraient lire ce document pour les procédures d'atténuation.

Gardez à l'esprit que les sites utilisant notre configuration recommandée, appliqués par l'assistant d'installation rapide, présentaient un risque modéré: certains noms d'utilisateur et mots de passe étaient enregistrés dans la base de données et éventuellement dans le fichier journal de débogage réservé aux super utilisateurs et aux systèmes de fichiers l'accès à votre site. Bien que ce ne soit pas idéal, ce n'est pas un risque énorme, c'est-à-dire que vous ne pouvez pas être piraté à distance. Sur une minorité de sites et uniquement à la suite d'une configuration manuelle, il est possible que dans certains cas un fichier journal accessible à distance contienne à la fois des noms d'utilisateur et des mots de passe, ce qui pose de graves problèmes de sécurité.

 

Ce document est publié sur notre site et dans les notes de publication de la nouvelle version d'Admin Tools.

Découverte des problèmes

Au cours de notre audit GDPR interne, nous avions déjà identifié deux problèmes de sécurité et de confidentialité affectant les versions d'Admin Tools au moins antérieure à la version 3.1.0. Ces problèmes ont été découverts entre mars et avril 2018 et nous avions déjà appliqué des correctifs pour eux entre avril et mai 2018.

Les 8 et 9 mai 2018 nous avons été contactés par le Joomla! Vulnerable Extensions List (VEL) sur ces deux problèmes de sécurité potentiels, y compris des informations supplémentaires sur les cas d'utilisation où ils pourraient soulever de graves problèmes de sécurité. Alors que pour la plupart des sites, les atténuations mises en place par d'autres fonctionnalités d'Admin Tools, appliquées par défaut lors de l'utilisation de l'Assistant Installation rapide, suffisent à minimiser ou atténuer complètement l'impact de ces problèmes, les cas d'utilisation sont suffisamment graves pour justifier une version de sécurité immédiate. Pour cette raison, nous publions Admin Tools 5.1.0 aujourd'hui, 10 mai 2018.

Nous tenons à remercier le Joomla VEL pour leur contact, leur temps et leur service au Joomla! communauté.

Problème 1 - Consignation des mots de passe en clair des échecs de connexion

Si vous avez activé l'option permettant de consigner les mots de passe de connexion ayant échoué, sachez qu'ils sont stockés en clair dans le journal des exceptions de sécurité #__admintools_exceptions sur votre site. Cette fonctionnalité a été supprimée de la nouvelle version d'Admin Tools, mais des informations peuvent toujours être présentes sur votre site.

Cette information est automatiquement supprimée lors de la mise à jour vers Admin Tools 5.1.0. Si vous ne pouvez pas mettre à jour Admin Tools, nous vous recommandons de vous rendre sur la page Journal des exceptions de sécurité, de filtrer en raison de l'échec de connexion et de supprimer tous les enregistrements qui vous sont présentés. Nous vous recommandons également de supprimer automatiquement les anciens enregistrements d'exceptions de sécurité en définissant les «Entrées du journal des exceptions de sécurité maximale» sur une valeur différente de zéro dans le plug-in System - Admin Tools. Une valeur entre 1000 et 10000 devrait offrir un bon équilibre entre la minimisation des données et la sécurité pour la plupart des sites.

Ce problème avait été découvert de manière indépendante par nous en avril 2018 lors de notre audit interne de conformité au GDPR et avait déjà été traité lorsque nous en avions été informés par la VEL.

Problème 2 - Possibilité de divulgation d'informations sur des serveurs mal configurés via le fichier journal de débogage

Les versions précédentes d'Admin Tools stockaient un journal de débogage avec une extension .log dans le répertoire logs de Joomla!. Par défaut, ce répertoire est accessible par le Web. Toutefois, si vous utilisiez la Protection par mot de passe administrateur d'Admin Tools ou le fichier .htaccess / nginx.conf / web.config OU si vous placiez votre dossier logs en dehors de votre racine Web, vos fichiers journaux n'étaient jamais accessibles sur le Web. La configuration par défaut appliquée par l'Assistant de configuration rapide des outils d'administration consiste à désactiver l'accès Web au dossier des journaux (ce qui est toujours une bonne idée pour des raisons de sécurité). Notez que le journal de débogage contient toutes les informations de la demande en cours de blocage. Si la requête bloquée contient des noms d'utilisateur et des mots de passe (par exemple, vous avez utilisé l'exception Traiter les échecs de connexion comme sécurité, la connexion administrateur Forbid ou les fonctionnalités d'utilisateur de modification du moteur), ils ont également été enregistrés.

Dans la version 5.1.0 d'Admin Tools, le journal de débogage est désactivé par défaut. De plus, les fichiers journaux de débogage existants sont supprimés lorsque vous installez une mise à jour vers Admin Tools ou lorsque vous désactivez le journal de débogage dans la page Configure WAF.


Agerix maintenance préventive JoomlaProtégez et optimisez votre site Joomla! avant qu'il ne soit trop tard !

En plus de ce qui précède, le type de fichier journal de débogage est devenu une extension .php et nous avons mis une instruction die () pour empêcher l'accès au fichier même si votre répertoire logs est accessible par le Web. Cependant, cela a une implication très sérieuse sur certains hôtes. Le fichier journal de débogage contient toutes les informations de la requête bloquée. Si la requête bloquée est une tentative de piratage légitime, c'est-à-dire pour laquelle Admin Tools est prévu pour bloquer, vous disposez désormais d'un fichier journal inerte avec une extension .php contenant les signatures du code de piratage. Certains hébergeurs ont des scanners automatisés qui peuvent mal interpréter ce fichier et le considérer comme piraté ou suspect. En fonction de l'hébergeur, vous pouvez recevoir un avertissement, le fichier peut être supprimé ou renommé ou votre site peut être suspendu. Si le fichier est renommé avec une extension .1, il sera rendu accessible sur le Web, ce qui ira à l'encontre de l'utilisation d'une extension .php et pourrait vous mettre en péril (sauf si vous avez déjà déployé un .htaccess ou unefonctionnalité de protection par mot de passe à l'administration pour empêcher l'accès au fichier journal comme expliqué précédemment). Dans les deux cas, si votre hébergeur vous fait des misères à propos de ce fichier, demandez-lui de lire les informations d'en-tête sur le fichier où nous expliquons pourquoi le fichier est sûr et qu'il doit être mis en liste blanche. S'ils refusent de le faire, vous devrez désactiver le fichier journal de débogage dans la page Configurer WAF (par défaut, il est désactivé) ou aller voir un autre hébergeur. Il n'y a rien d'autre à faire.

En règle générale, nous vous recommandons de ne pas activer le journal de débogage sauf si vous essayez de résoudre un problème. Une fois le dépannage terminé, désactivez le journal de débogage.

Cette question avait été découverte de façon indépendante par nous en mars 2018 et avait déjà été partiellement traitée en mai 2018 avant que nous soyons contactés par le VEL. Sur le contact de VEL nous avons changé l'extension du fichier journal en .php et introduit la suppression automatique des fichiers journaux existants lorsque cette fonctionnalité est désactivée.

Atténuation dans la version 5.1.0

Cette section reprend certaines des informations des paragraphes précédents dans un format plus concis.

  • La version 5.1.0 n'offre plus l'option de journaliser les mots de passe de connexion qui ont échoué. Cette fonctionnalité a une utilisation très limitée et c'est une mauvaise pratique de sécurité.
  • Lors de l'installation d'une mise à jour, les enregistrements de connexion ayant échoué sont supprimés si l'option d'enregistrement des mots de passe a été activée.
  • Lors de l'installation d'une mise à jour, le journal de débogage en texte brut existant avec une extension .log (et la rotation des journaux avec l'extension .log.1) est automatiquement supprimé de votre site.
  • Le fichier journal de débogage a maintenant une extension .php et une instruction die pour empêcher l'accès direct. Cela PEUT causer des problèmes avec certains hôtes s'il est activé.
  • L'activation du fichier journal de débogage est désormais une option distincte, désactivée par défaut. Dans le passé, il était lié à la journalisation globale (exceptions de sécurité de journal dans la base de données) qui est toutefois nécessaire pour fournir un blocage IP automatique.
  • Par conséquent, les nouvelles installations sont sécurisées par défaut et les installations existantes sont automatiquement sécurisées lors de l'installation de la nouvelle version d'Admin Tools.

Atténuation pour les anciennes versions

Si vous ne pouvez pas effectuer la mise à niveau vers Admin Tools 5.1.0, nous vous recommandons de prendre les mesures suivantes pour atténuer tout impact sur la sécurité des problèmes susmentionnés:

  • Désactivez la fonction Inclure le mot de passe dans l'e-mail de connexion échoué dans la page de configuration du WAF
  • Utilisez la fonction de protection d'accès à l'administration par un fichier .htaccess ou la fonction de protection par mot de passe administrateur empêchera l'accès au répertoire des journaux
  • Si vous souhaitez désactiver complètement le fichier journal de débogage, vous pouvez modifier le fichier plugins / system / admintools / util / exceptionshandler.php, rechercher la ligne privée logSecurityExceptionToFile ($ reason, $ extraLogInformation, $ txtReason, $ tokens) et ajouter un nouveau ligne APRÈS le premier retour de lecture de l'accolade; Veuillez noter que cela désactive complètement le fichier journal de débogage.

Considérations générales sur la sécurité des fichiers journaux Joomla

Joomla! stocke les fichiers journaux en texte brut dans son répertoire logs. Par défaut, il se trouve dans le dossier administrator / logs de votre site. Comme il est sous votre racine Web, il peut être consulté sur le web sur un Joomla par défaut! installation.

Joomla! stocke ses propres fichiers journaux sous forme de fichiers .php avec un nom de fichier prévisible et une instruction die sur le dessus. Bien que cela empêche l'accès direct au Web à chaque fichier, il présente un risque de sécurité majeur. Par exemple, il existe deux problèmes de sécurité concernant cette pratique :

  • Il permet la découverte de journaux en essayant d'accéder à l'URL prévisible de chaque fichier journal sur le Web. Même si cela ne semble pas important, cela permet à un attaquant de déterminer avec une très bonne certitude si le mode Débogage de votre site est activé. À son tour, cela peut être utilisé pour exploiter la différence dans le comportement de Joomla lorsque le mode débogage est activé.
  • Plus grave encore, si votre serveur est mal configuré pour vider le contenu des fichiers .php au lieu de les exécuter, vous avez une sérieuse vulnérabilité de divulgation d'informations. Cela peut se produire soit pour l'ensemble de la racine web, soit simplement pour le répertoire logs en raison d'une mauvaise directive .htaccess / nginx.conf / web.config, d'une mauvaise configuration de la partie hôte, etc. Ces erreurs peuvent durer de quelques secondes à plusieurs jours dans le monde réel.
  • Comme les fichiers journaux sont dans une localisation prévisible et un nom prévisible, un attaquant peut exploiter une vulnérabilité d'accès au fichier dans une extension ou un script indépendant sur votre site pour vider le contenu des fichiers journaux, déclenchant un événement de divulgation d'informations.

Pour ces raisons et pour d'autres raisons plus ésotériques, nous considérons que le comportement de journalisation par défaut de Joomla est intrinsèquement non sécurisé. Ce que nous avons toujours recommandé est de déplacer votre répertoire Joomla logs en dehors de la racine web, c'est-à-dire dans un répertoire au-dessus de public_html. Cela atténue tous les problèmes ci-dessus. Bien sûr, les fichiers journaux peuvent toujours être sauvegardés si l'attaquant a la possibilité d'exécuter du code PHP arbitraire sur votre site. Toutefois, dans ce cas, ils ont "pwned" votre site, c'est à dire qu'ils ont un accès complet et peuvent faire ce qu'ils veulent, y compris l'ajout de code pour intercepter les connexions et envoyer le nom d'utilisateur et mot de passe à leur serveur. Par conséquent, nous pouvons affirmer que déplacer le répertoire des journaux de votre site en dehors de la racine Web est l'atténuation la plus pratique et la plus adéquate.

Une atténuation partielle peut être fournie en bloquant complètement l'accès Web au répertoire logs au niveau du serveur Web. Lorsque vous utilisez le .htaccess Maker dans Admin Tools avec sa fonctionnalité Backend Protection, voici ce que vous faites; l'accès web au répertoire logs est complètement bloqué. La fonctionnalité Administrateur Password Protect fonctionne également à cet effet. Comme vous avez besoin d'un mot de passe pour accéder au dossier / administrator (et à tous ses sous-dossiers, y compris les journaux), vous bloquez l'accès direct aux fichiers journaux sur le Web. De plus, si vous utilisez nos journaux et la fonction de fixateur de répertoire temporaire, vous bénéficiez également du même type de protection, même si vous n'utilisez pas le concepteur de .htaccess ou le mot de passe pour protéger les fonctions administrateur : un fichier .htaccess pour empêcher l'accès direct au Web sur le répertoire log. En cas de doute, utilisez cette fonction pour fournir des informations de base sur le comportement du répertoire des journaux de Joomla.

On peut dire que la meilleure atténuation est quelque chose que la plupart des sites ne peuvent pas faire : en utilisant un serveur de journalisation séparé. Ce sera possible avec Joomla! 4 et son support pour la technologie de l'enregistreur PSR-3. Cependant, c'est compliqué à installer. Ceux d'entre vous qui en ont besoin savent déjà ce que cela signifie. Tout le monde devrait juste se concentrer sur l'atténuation pratique et entièrement adéquate de l'utilisation d'un répertoire de logs en dehors de la racine web. Vous pouvez le configurer via la page de configuration globale de Joomla.

Nous attirons votre attention sur le fait que notre documentation indique depuis 2010 que le répertoire des logs Joomla par défaut n'est pas sécurisé et doit être sécurisé.

A chaque nouvelle version d'Admin Tools, l'agence Agerix traduit intégralement les notes de version (changelog) et ajoute des commentaires et explications afin que l'ensemble des utilisteurs puissent avoir une lecture plus simple de ces changements. Ces notes de version sont lisibles sur le site, ou bien disponible par flux RSS ou par Newsletter. Si vous voulez tout savoir sur le prochaines mises à jour n'hésitez pas à vous abonner !

Certification Joomla

Tous les membres de l'équipe Agerix ont obtenu leur certification administrateur joomla!

certification administrateur joomla

 

Abonnez-vous à nos newsletters

Confidentiel Agence Agerix © 2017 S.A.R.L au capital de 8500 euros. RCS Bordeaux 812 619 062.
A.P.E 6202A N° identification T.V.A FR42812619062 Prestataire de formation n° 75 33 10531 33

Agerix
Addresse: 4 rue Jean Moulin 33310 Lormont, France ,
Tel:( 33 5) 35 54 92 03 , Fax:( 33 9) 72 14 74 74 , E-mail: contact(at)agerix.fr

agerix.fr n'est ni affilié à Open Source Matters ou au projet Joomla!® ni approuvé par eux.
Le nom Joomla! et le logo sont utilisé sous licence limitée accordée par Open Source Matters, propriétaire de la marque aux États-Unis et autres pays.