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

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.