Les enseignements du Codecov - Ce que nous savons jusqu'à présent

Il n'était pas nécessaire de le rappeler si tôt, mais la violation récemment annoncée de l'ensemble des outils de Codecov, qui soutient les processus d'intégration continue (CI) dans de nombreuses organisations, met à nouveau en évidence la vaste densité des interdépendances qui existent aujourd'hui et l'exposition aux attaques de la chaîne d'approvisionnement qui en découle.

En outre, la confiance souvent implicite dans les logiciels fournis par des fournisseurs de confiance signifie que les clients ne testent pas de manière adéquate ce que fait une mise à jour, à la fois en termes de ce qu'elle fait localement sur l'hôte, mais aussi en termes de connectivité réseau et de transfert de données. Cela signifie que, le plus souvent, le logiciel qui fonctionne dans les organisations n'est pas entièrement compris.

Quel est le rapport avec ce qui s'est passé avec Codecov ?

Codecov fournit des capacités de reporting qui peuvent être intégrées dans les pipelines de CI des clients - en particulier, leurs outils rendent compte de la quantité de code qui est exécutée dans le cadre des tests, ce qui permet d'identifier les lacunes dans le processus de validation. Ces mesures sont ensuite téléchargées sur leur plateforme SaaS pour l'établissement de rapports et d'analyses.

Le téléchargement des données est facilité par des scripts appelés collectivement "Bash Uploaders", qui sont exécutés dans le cadre du processus de CI. Ces scripts Uploader, s'ils sont manipulés, permettent à un attaquant non seulement de rediriger le téléchargement vers un serveur de son choix, mais aussi de spécifier les données qu'il souhaite inclure, rendant ainsi potentiellement accessible tout ce qui est disponible pour le processus CI.

Dans le cas de Codecov, la compromission initiale est due à une fuite des informations d'identification de Google Cloud Storage rendues disponibles par une erreur dans le processus de création de l'image Docker de Codecov. Ces informations d'identification ont permis à l'attaquant d'afficher une version modifiée du script Bash Uploader, qu'il a modifié pour lui permettre de recueillir le contenu de toutes les variables d'environnement disponibles pour le processus CI dans lequel il a été exécuté et de les télécharger sur son propre serveur.

Étant donné que ce script modifié était disponible directement sur le site de Codecov, on peut supposer que les clients lui ont fait confiance et qu'il a été téléchargé et intégré avec peu de validation. Les variables d'environnement dans le processus de CI sont généralement utilisées pour insérer des secrets pertinents dans le code afin d'accéder aux ressources dont il a besoin au moment de l'exécution. Le script Uploader malveillant y aurait donc accès et serait en mesure de les transférer à l'attaquant, lui fournissant ainsi une bonne récolte d'informations d'identification et d'autres informations sensibles.

Même sans accès permanent au réseau - et rien n'indique pour l'instant si la violation l'a établi - ces secrets constituent un trésor, car ils donnent accès à un certain nombre de ressources accessibles sur l'internet, telles que des espaces de stockage, des bases de données et d'autres services en nuage utilisés par les applications correspondantes. Ces derniers sont également susceptibles d'être compromis.

Au minimum, toute organisation qui pense avoir incorporé les scripts Bash Uploader compromis dans son pipeline CI doit, de toute urgence, réinitialiser tous les secrets auxquels il a accès. Cela nécessitera presque certainement un redéploiement des applications concernées afin de s'assurer qu'elles disposent des secrets mis à jour, mais le surcoût de cette méthode est préférable à la prolongation de l'exposition des informations d'identification volées.

Au-delà de l'exfiltration de secrets, l'accès privilégié permanent accordé à la filière CI est propice aux abus. Par définition, la responsabilité du pipeline est de générer de nouvelles versions de logiciels et de les publier dans des référentiels. La compromission de l'infrastructure du pipeline elle-même donne à l'attaquant la possibilité d'en modifier le contenu, voire d'y insérer des portes dérobées qui seront utilisées ultérieurement sur les systèmes en aval ou dans les artefacts générés. Quelle est donc l'ampleur de la reconstruction nécessaire pour avoir la certitude que toute trace de l'agresseur et de ses tentacules a été éliminée ?

Ensuite, il convient d'examiner l'accès au réseau disponible pour l'infrastructure de l'IC. En général, ils ont un accès direct à d'autres composants clés, notamment le système de contrôle des versions, l'infrastructure de surveillance, les tests automatisés, le processus de construction, la gestion de la configuration et le déploiement continu. De plus, avec l'utilisation intensive de composants FOSS, le pipeline CI aura souvent besoin d'un accès internet aux dépôts publics pour obtenir les dépendances pertinentes.

Avec les exigences de connectivité dense que requiert le pipeline CI, la segmentation peut-elle encore servir de contrôle de sécurité précieux ?

Lorsque l'on considère la valeur des micro-segmentationIl peut être présenté de deux manières :

1. La micro-segmentation permet de cloisonner les actifs de grande valeur, en veillant à ce que leur exposition au reste du réseau soit limitée, ce qui rend plus difficile pour un pirate de les atteindre et de les exploiter.
2. La micro-segmentation permet à chaque charge de travail d'avoir son propre micro-périmètre basé sur des règles d'accès au moindre privilège. Ainsi, en cas de compromission, la surface d'attaque qui lui est exposée est limitée à ce à quoi il est autorisé à se connecter, ce qui limite en fin de compte ce qu'un attaquant pourrait faire par la suite.

Une approche pour rendre ceci pertinent pour le pipeline CI ressemble à quelque chose comme ceci :

• Le pipeline de l'IC est sans aucun doute un actif de grande valeur qui devrait être réservé.
• Bien qu'il puisse avoir un certain nombre de dépendances internes et externes du point de vue de la connectivité, celles-ci doivent être bien comprises et bien définies.
• En utilisant ces informations, une politique de micro-segmentation basée sur une liste d'autorisationspourrait être élaborée pour s'assurer que le pipeline de CI n'a accès qu'à ces dépendances bien comprises et à partir d'elles.
• Si l'accès à l'internet est nécessaire, il ne devrait être autorisé que pour une liste de dépôts approuvés et non pour un accès illimité à l'internet. Cela limite l'accès à une liste explicitement définie de sites de destination et constitue un contrôle efficace et souvent simple pour atténuer les tentatives d'exfiltration de C&C et de données.

Cela permet d'éviter que des dispositifs non autorisés ou des ports et des protocoles non autorisés n'accèdent au pipeline de l'infrastructure de communication. Il garantit également qu'en cas de compromission du pipeline d'infrastructures critiques, l'exposition au reste du réseau est limitée. En outre, l'amélioration des contrôles de segmentation va souvent de pair avec une visibilité nettement meilleure des interactions entre les systèmes, ce qui fournit des données plus riches aux équipes de détection et de réponse aux incidents lorsqu'elles enquêtent sur des violations potentielles.

Chez Illumio, nous aidons les clients à tirer parti de la micro-segmentation pour établir ce confinement et cette surveillance. Contactez votre équipe pour savoir comment nous pouvons vous aider.