Sécurité : le processus de mise à jour de Drupal est-il dangereux ?

Courant novembre, un groupe de recherche a contacté l'équipe de sécurité de Drupal pour évoquer un problème lié au processus de vérification et de téléchargement des mises à jour du cœur et des modules. Le sujet a été débattu en interne et la menace a été jugée suffisamment sérieuse pour nécessiter des mises à jour mais avec un impact potentiel trop faible pour opacifier le processus. Début janvier, le lanceur d'alerte a donc publié un article traitant du sujet, et l'équipe de sécurité a posté une réponse quelques jours plus tard pour répondre à l'article publiquement.

Problème déclaré n°1 : lorsque le processus de recherche des mises à jour de Drupal échoue, Drupal indique que tous les modules sont à jour au lieu d'afficher un message d'alerte.

Lorsque vous disposez des permissions suffisantes, il est possible de consulter la liste des mises à jour disponibles pour le cœur et vos modules depuis votre interface d'administration. Par défaut, cette liste est mise à jour quotidiennement via l'exécution d'une tâche planifiée (cron) mais vous pouvez également lancer la vérification manuellement en cliquant sur un lien.

Ce que soulève le lanceur d'alerte c'est que lorsque cette procédure automatisée échoue, par exemple à cause d'une perte de connexion ou d'une surcharge momentanée des serveurs de drupal.org, aucun message d'erreur n'est affiché et, pire, votre site indique alors que tous les modules sont à jour.

Il est vrai qu'un message sur cette page serait bénéfique pour éviter tout malentendu concernant l'état des mises à jour du site. On repense notamment à l'unique faille hautement critique détectée depuis Drupal 7, surnommée « Drupageddon », qu'il aurait fallu corriger en moins de quelques heures pour pouvoir certifier que le site n'était pas vérolé. Cependant, l'équipe de sécurité de Drupal se veut rassurante car, même s'il n'y a en effet pas de message sur cette page, il y en a bien un sur toutes les autres pages de l'interface d'administration.

Bien qu'assez mineur, ce problème est actuellement en train d'être corrigé (EN) et la future version 8.0.3 devrait le résoudre sans grande difficulté. L'équipe de sécurité de Drupal rappelle tout de même qu'elle communique à propos de ces mises à jour par le biais de quatre autres canaux (leur groupe sur drupal.org, la newsletter dédiée, leur flux RSS et leur fil Twitter).

Problème déclaré n°2 : un attaquant pourrait forcer un administrateur à vérifier les mises à jour disponibles très fréquemment à cause d'une vulnérabilité « CSRF ».

Une vulnérabilité de « Cross-Site Request Forgery » (CSRF) consiste à inciter le navigateur de la cible à se rendre sur une page très précise de son propre site sans qu'il ne le sache. La plupart du temps, ce genre d'attaque s'opère par le biais d'une fausse image dont le chemin est en fait l'URL de la page à attaquer. Ainsi, lorsque le navigateur de la cible va tenter d'afficher l'image, il va en fait faire une requête sur la page en question qui va s'exécuter normalement. Lorsque le navigateur recevra le contenu de la page et se rendra compte qu'il ne s'agit pas d'une image, il n'affichera rien ou alors une indication d'une image brisée. Cette image peut être placée sur l'un des sites de l'attaquant sur lequel il espérera que vous passiez ou alors même sur votre propre site, dans un commentaire par exemple.

Ce que soulève ici le lanceur d'alertes est que ce type d'attaque pourrait avoir plusieurs conséquences. Tout d'abord, si cette page était trop souvent visitée volontairement ou pas par les administrateurs du site, cela pourrait surcharger le serveur et rendre le site inaccessible. Ensuite, si cette pratique était reproduite sur plusieurs sites différents, cela pourrait envoyer de nombreuses requêtes aux serveurs de drupal.org et ce coup-ci surcharger directement la source et impacter des milliers d'autres sites. Enfin, en maîtrisant le moment où cette requête pourrait être exécutée, un attaquant étant capable de compromettre un serveur DNS ou d'écouter le trafic du site pendant un bref instant pourrait synchroniser ses actions pour obtenir des informations importantes sans laisser de traces.

Outre le premier problème qui pourrait impacter les sites disposant de peu de ressources pour s'exécuter, les deux autres points semblent bien moins probables. En effet, l'équipe de sécurité de Drupal rappelle que des millions de clients se connectent chaque jour à l'infrastructure de drupal.org et que celle-ci est mise en cache derrière un réseau de contenu distribué (CDN). Il faudrait donc opérer une grande attaque coordonnée sur de très nombreux sites afin de générer suffisamment de trafic pour compromettre l'architecture de drupal.org.

Malgré tout, le problème est tout de même pris au sérieux et un correctif est en préparation. Étant donné que cela a un impact sur toutes les versions de Drupal et que le problème n'est pas critique, il se peut qu'il faille attendre quelques mois avant de le voir définitivement intégré.

Problème soulevé n°3 : les mises à jour de sécurité sont transférées de façon non-chiffrée et sans en vérifier l'authenticité, ce qui pourrait compromettre la sécurité du site, de la base de données et éventuellement du serveur.

Ce dernier problème est finalement le plus sérieux bien que sa mise en œuvre et sa correction soient plus complexes. L'URL à laquelle se connecte le site pour vérifier les mises à jour n'utilisant pas de connexion HTTPS, il est possible pour un pirate d'écouter et même de remplacer certaines données avec celles de son choix. Pour cela, il doit s'intercaler entre le serveur hébergeant le site et les serveurs de drupal.org. Ce type d'attaque, appelé « man-in-the-middle », est très difficile à réaliser dans des conditions de production normales (serveur hébergé sur un réseau professionnel et dont l'infrastructure n'a pas été compromise).

Ainsi, en admettant que le pirate soit capable d'intercepter le trafic entre votre serveur et ceux de drupal.org, il pourrait vous renvoyer une version totalement fausse du fichier indiquant quels modules sont à jour et lesquels ne le sont pas. Cela lui permettrait de leurrer l'administrateur du site en lui proposant de fausses mises à jour.

Pire encore, au moment du téléchargement du module le pirate pourrait également fournir une version modifiée par ses soins et contenant du code qui pourrait aller jusqu'à compromettre tout le serveur. Une fois le serveur compromis, il pourrait être utilisé comme plateforme d'envoi de spams ou comme vecteur d'attaque pour d'autres serveurs situés sur la même architecture.

Malgré la gravité de ce type d'attaque, il est très difficile à réaliser et le devient encore plus lorsque l'on respecte quelques règles de base de vigilance. Par exemple, au lieu de cliquer directement sur le lien fourni dans l'interface d'administration de Drupal, il est préférable de se rendre sur le site drupal.org pour y vérifier la véracité de l'information et y télécharger le module. En effet, alors qu'il est assez simple de leurrer un simple script PHP en fournissant un faux certificat SSL, la technologie HSTS (HTTP Strict Transport Security), implémentée par les navigateurs modernes, rend l'usurpation d'identité quasi impossible. Si un pirate essayait de se faire passer pour les serveurs de drupal.org, le navigateur le détecterait immédiatement et empêcherait l'accès au site compromis et aux téléchargements douteux en affichant une alerte.

En attendant l'implémentation potentielle d'une solution lourde mais définitive pour tous ces problèmes, l'équipe de sécurité de Drupal va travailler en collaboration avec l'équipe d'infrastructure pour activer et définir par défaut les URLs en HTTPS. Ils feront également en sorte que Drupal aille chercher l'état de ses modules en utilisant ce protocole sécurisé.  

Conclusion

C'est une bonne chose que les problématiques liées à la mise à jour de nos sites aient été dévoilées publiquement car cela a permis à tout l'écosystème de se remettre en question pour déterminer quel était le risque acceptable de ce genre de situation. Des produits comme Wordpress, permettant l'installation directe de plugins et de mises à jour avec une intervention minimale de l'administrateur ont été et sont encore particulièrement concernés. Au final cet article aura fait plus de bruit que de dégâts mais il nous aura permis d'approfondir un domaine souvent laissé de côté malgré la position centrale de ce processus de mise à jour dans notre travail quotidien.
 

Photo de couverture © Theen Moy