Connect with us

Technologie

Comment un exercice d’équipe rouge a évité une nouvelle attaque de type SolarWinds

Published

on


Un acteur de la menace compétent peut facilement infiltrer l’environnement de développement d’une organisation et mener une attaque de la chaîne d’approvisionnement de type SolarWinds ou Kaseya en quelques jours, selon de nouveaux renseignements de Palo Alto Networks, qui avertissent que de nombreuses sociétés de logiciels ont été bercées dans un faux sentiment de sécurité de la chaîne d’approvisionnement dans le cloud.

Dans un rapport récemment publié sur l’état du marché de la sécurité dans le cloud, qui peut être téléchargé dans son intégralité ici, l’équipe unit 42 de l’entreprise a partagé l’histoire de la façon dont elle a réussi à pénétrer un important fournisseur de logiciels en tant que service (SaaS) et à « exécuter » une attaque de la chaîne d’approvisionnement en à peine 72 heures.

La société de logiciels, qui ne peut pas être nommée pour des raisons évidentes, a engagé les services de l’Unité 42 pour pénétrer dans son environnement de développement de logiciels cloud après avoir été effrayée par l’incident SolarWinds.

L’équipe rouge de l’Unité 42 a profité des erreurs de configuration dans l’environnement de développement pour prendre le contrôle du processus de développement logiciel du client de la même manière qu’un groupe de menaces persistantes avancées (APT) lié à la Chine a pu pénétrer la plate-forme de SolarWinds pour introduire une mise à jour de code contaminé.

« Les risques liés aux chaînes d’approvisionnement ont récemment fait l’objet de beaucoup d’attention dans les médias, ce que les discussions oublient souvent, c’est que les attaquants ne modifient pas nécessairement les référentiels de code source pour faciliter ces violations. Ils n’ont pas à le faire. Ils trouvent des faiblesses dans le pipeline de développement logiciel et les attaquent », a écrit Matthew Chiodi, responsable de la sécurité du cloud chez Palo Alto dans le préambule du rapport.

Les red teamers se sont fait passer pour des développeurs malveillants avec un accès limité à l’environnement d’intégration continue (CI) du client d’où ils ont essayé d’obtenir des droits d’administrateur vers l’environnement cloud plus large – bien que cela soit quelque peu différent de ce qui s’est passé chez SolarWinds, cela démontre de la même manière comment un attaquant ou un initié malveillant pourrait tirer parti d’un référentiel CI.

Pour commencer, les chercheurs se sont vu attribuer un rôle DevOps que le client donnerait généralement à tous les développeurs de son environnement, y compris l’accès à ses référentiels GitLab internes. C’était le premier échec du client – s’il avait suivi les meilleures pratiques recommandées en matière de séparation des tâches pour chaque développeur, l’exercice n’aurait peut-être pas aussi bien fonctionné.

Ressources cloud

À partir de là, les équipes rouges ont pu télécharger chaque référentiel GitLab à partir de l’emplacement de stockage du logiciel cloud du client. Ils y ont trouvé environ 80 000 ressources cloud individuelles, notamment des machines virtuelles (VM), des bases de données, des instances de stockage, une infrastructure réseau et des passerelles réseau dans 154 référentiels uniques. De manière cruciale, ils ont également trouvé 26 paires de clés de gestion des identités et des accès (IAM) codées en dur, dont cinq étaient des jetons de session, le reste des clés d’accès.

À partir de là, l’équipe rouge a augmenté ses privilèges à l’aide des clés IAM volées pour exploiter une mauvaise configuration dans une fonctionnalité Amazon Web Services (AWS) spécifique, iam:PassRole, qui lui a permis de créer une instance EC2 avec un accès administrateur à l’environnement cloud plus large.

Un tel accès établi, l’équipe rouge avait la pleine capacité d’effectuer n’importe quel nombre d’actions dans l’environnement cloud du client chanceux, ou de la malheureuse victime. Cela comprenait l’empoisonnement des opérations CI pour insérer du code malveillant dans leur pipeline de développement logiciel, bien que cela ne cadre pas dans le cadre de l’engagement, l’exercice ait été arrêté à ce stade.

Une analyse plus large des opérations de sécurité et de la réponse du client a ensuite été entreprise, ce qui a finalement fait apparaître l’activité suspecte au centre des opérations de sécurité (SOC) du client par le service GuardDuty d’Amazon, qui a fonctionné comme prévu mais n’a pas été correctement configuré sur tous les comptes AWS du client et n’a donc repéré qu’une petite fraction de l’exercice global.

Néanmoins, une fois alertée, l’équipe SOC a rapidement été en mesure d’identifier chaque clé IAM compromise utilisée par l’équipe rouge et a déployé efficacement ses outils d’orchestration, d’automatisation et de réponse de la sécurité (SOAR) pour désactiver les clés et désactiver l’accès.

Plan de sécurité

L’Unité 42 a par la suite beaucoup travaillé avec l’organisation confirmée pour mettre en œuvre un plan de sécurité « shift left », dont les éléments (détaillés dans leur intégralité dans le rapport) comprennent des contrôles d’accès plus stricts et basés sur les rôles pour les développeurs afin d’empêcher les référentiels DevOps de s’égarer; la mise en œuvre de règles de détection de la plate-forme cloud pour les demandes d’API sensibles provenant de l’extérieur de la portée réseau de l’organisation; et des règles de détection de plate-forme cloud pour les demandes d’API spécifiques à l’utilisateur dirigées vers des comptes de service IAM.

« Exercices de l’équipe rouge … démontrer un exemple de comment une mauvaise hygiène de sécurité dans la chaîne d’approvisionnement peut avoir un impact sur l’infrastructure cloud. Le client, dans ce cas, un grand fournisseur SaaS, maintient ce que la plupart considéreraient comme une posture de sécurité cloud mature. Cependant, les chercheurs de l’Unité 42 ont constaté que 21% des analyses de sécurité qu’ils ont effectués sur l’environnement de développement du client ont entraîné des erreurs de configuration ou des vulnérabilités, un nombre qui correspond carrément à la moyenne de l’industrie de 20% », a déclaré l’équipe de l’Unité 42 dans le rapport.

« Les chercheurs pensent qu’il est très probable que les techniques utilisées lors de l’exercice de l’équipe rouge pourraient être exécutées avec succès contre de nombreuses organisations développant des applications dans le cloud », ont-ils déclaré, bien qu’il soit également important de noter que cette voie d’attaque particulière n’était pas identique à celle utilisée contre SolarWinds.

L’équipe a déclaré que malgré de nombreux discours dans la communauté de la sécurité sur le modèle dit de virage à gauche, les organisations continuent évidemment à négliger la sécurité DevOps, en partie, pensent-elles, en raison du manque d’attention aux menaces de la chaîne d’approvisionnement.

Étant donné que les applications cloud natives ont une si longue chaîne de dépendances , telles que des outils open source et divers composants d’autres fournisseurs et développeurs, et que ces dépendances ont probablement aussi des dépendances, il est essentiel que les équipes DevOps et de sécurité gagnent en visibilité sur la « nomenclature » complète de chaque charge de travail cloud.

Trop de gens, ont-ils dit, semblent encore croire que l’analyse du code à la fin du cycle de vie du développement est suffisante, et tant que cette croyance erronée persistera, les environnements de développement cloud continueront d’être ciblés par les acteurs de la menace.

« C’était certainement le cas pour la violation de SolarWinds ainsi que pour ce que purent A été une violation majeure pour notre client a eu l’équipe de l’Unité 42 qui n’a pas identifié les vulnérabilités de la chaîne d’approvisionnement du client avant qu’un attaquant malveillant ne le fasse », ont-ils conclu.

Click to comment

Leave a Reply

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Tendance