L’intégration continue ? Une mine d’or pour les pirates

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.