L’intégration continue ? Une mine d’or pour les pirates
Les outils d’intégration continue semblent souvent configurés sans prise en compte de leur sécurité. Ils constituent alors une large porte d’entrée sur le système d’information.
Nikhil Mittal est un spécialiste des tests d’intrusion. Il est notamment à l’origine de Kautilya, une boîte à outils dédiée à ces tests, et de Nishang, un framework PowerShell dédié à la phase suivant la compromission initiale d’un environnement.
Intervenant régulièrement lors de conférences, Nikhil Mittal a profité de l’occasion offerte par l’édition européenne de Blackhat 2015, à l’automne dernier, pour souligner l’opportunité que les systèmes d’intégration continue représentent pour les pirates s’ils ne sont pas correctement protégés.
Des outils particulièrement sensibles
Dans sa présentation, il explique ainsi que « si un pirate parvient à accéder à un outil d’intégration continue, il prend le contrôle d’une partie substantielle du processus de compilation, du code source, et obtient un accès à privilèges élevés à toutes les machines exécutant les agents/esclaves ». Un accès exploitable « pour des déplacements latéraux à d’autres machines » de l’infrastructure. Et d’insister : « je n’ai pas rencontré un seul exercice d’intrusion ou engagement offensif où l’accès à un outil d’intégration continue ne conduisait pas à un accès administrateur du domaine ».
Pour sa présentation, Nikhil Mittal s’est penché sur Jenkins/Hudson, CruiseControl, Go, et TeamCity, mais à la recherche de vulnérabilités intrinsèques : l’exercice a consisté à s’intéresser au détournement de fonctionnalités et aux erreurs de configuration.
Des configurations standard vulnérables
Les premières remarques du chercheur laissent entrevoir une absence de prise en compte de la sécurité du côté des concepteurs de ces outils. Il relève ainsi que Jenkins ne gère pas d’authentification dans son installation par défaut. En cas de configuration requérant une authentification, l’outil n’intègre pas de protection contre les attaques en force brute, ni de règles relatives à la robustesse des mots de passe. En outre, l’outil s’exécute sous Windows avec un niveau de privilège très élevés.
Surtout, « si un utilisateur a la possibilité d’ajouter une étape de compilation (les utilisateurs non-administrateur peuvent le faire si c’est ainsi configuré), il peut exécuter des commandes et des scripts sur le système d’exploitation hôte », jusque sur les agents/esclaves de l’infrastructure. Le tout en profitant, le cas échéant, de toute la puissance de PowerShell.
Mieux : via le maître de l’infrastructure, un attaquant peut supprimer tous les contrôles de sécurité de la configuration Jenkins en en effaçant le fichier XML de configuration. La récupération d’identifiants ou encore de clés de chiffrement privées est également possible à partir du maître Jenkins.
Une ignorance complète de la sécurité ?
La situation n’apparaît guère meilleure avec TeamCity. Là encore, la robustesse des mots de passe ne peut pas faire l’objet de règles et l’outil s’exécute avec des privilèges élevés. Et la possibilité d’ajouter une étape de compilation se traduit par celle d’exécuter commandes et scripts sur le maître et les agents.
Comme pour Jenkins, un utilisateur autorisé à configurer des compilations sur le maître – « un administrateur projet, à moins d’une configuration différente » – « peut lire n’importe quelle clé privée SSH transférée pour les projets » : elles sont stockées en « texte clair ».
Surtout, les équipes de développement ne semblent pas se préoccuper des questions de sécurité : « les informations qui peuvent collectées à partir d’instances de TeamCity accessibles publiquement avec les privilèges invité sont ahurissantes » ! Et Nikhil Mittal d’assurer avoir ainsi découvert des identifiants de portails Web, de bases de données, des données d’employés, etc. La situation n’est guère meilleure pour Go ou CruiseControl.
Contrôler finement la configuration
Le chercheur formule alors plusieurs recommandations pour améliorer la posture de sécurité des environnements d’intégration continue, à commencer par le contrôle précis des droits des utilisateurs – en particulier pour l’ajout d’étapes de compilation – en encore ne pas exécuter d’agent de compilation sur le maître.
Bien sûr, Nikhil Mittal recommande aussi de contrôler la robustesse des mots de passe, d’interdire les accès invités, et de ne pas stocker d’identifiants ni de clés de chiffrement en clair sur le maître.
Et il semble illusoire de considérer que l’on est à l’abri de ce genre d’attaque : fin 2014, un environnement Jenkins exposé en ligne a été brièvement détourné… chez Facebook.