Le Bulletin Cyber – Avril 2021

Découvrez l’édition du mois d’avril de notre Bulletin Cyber, un condensé des dernières attaques par ransomware et les différents aspects de sécurisation des actions utilisateur.

La sécurisation des accès cloud à haut-privilèges, la PRIORITE des CISOs en ce temps de crise

Les restrictions liées à la crise sanitaire COVID-19 ont constitué une réalité inattendue pour les organisations de toutes tailles. Du jour au lendemain, les entreprises ont été contraintes d’adopter, en urgence, des solutions de digital Workplace, proposer des solutions d’accès distant aux salariés et partenaires, et surtout, favoriser la souscription à des services cloud qui leur permettent à la fois de combler les manquements de leurs SI et de réduire considérablement le time-to-market.

Cette accélération de la mise en place des différents services cloud (IaaS, PaaS ou SaaS) a modifié la physionomie des cyberattaques. A l’ère du cloud, les cyber-attaquants ne cherchent plus nécessairement à compromettre un système mais plutôt une identité. Dans les environnements purement on-premise, une attaque prend du temps et requiert plusieurs mouvements latéraux (de système en système) avant de parvenir à une élévation de privilège. En revanche, bien que la démarche reste la même dans les environnements cloud, le ciblage d’identifiants ou clés APIs spécifiques raccourcit considérablement le chemin d’attaque.

Dans cette édition du bulletin cyber, nous allons nous intéresser à deux types d’attaques qui ciblent des identités sur des environnements cloud : 

• Le vol des identifiants à privilèges avec comme exemple le dump de secrets cloud depuis GitHub
• Une attaque reposant sur l’exploitation d’une mauvaise configuration du service cloud IAM

Le vol des identifiants à privilèges, une cible prioritaire des attaquants

Les vols d’identifiants sont devenus la cible prioritaire des cyber-attaquants. Selon le dernier rapport de Verizon « Data Breach investigations 2020 » [1], 80% des cyberattaques impliquent l’utilisation d’identifiants volés.

La cible préférée des cyber-attaquants sont ou les accès de comptes individuels (comme des administrateurs systèmes et réseaux, des DBA, d’info-gérants, des gestionnaires de plateformes virtualisés, les administrateurs des environnements cloud) ou des comptes applicatifs ou de machines (non-humains) comme des objets IoT, des iBots, scripts d’automatisation DevOps, etc.

La compromission ou le vol des identifiants de ces identités à haut-privilèges donne un avantage considérable aux cyber-attaquants. Dès lors qu’ils réussissent à compromettre un compte à privilèges quelconque, il n’est question que de quelques minutes pour qu’ils exercent un contrôle total sur le SI à travers des mouvements latéraux, verticaux et d’élévation de privilèges : c’est la raison pour laquelle la sécurisation des accès à haut privilèges est devenue l’une des priorités fortes des CISOs.

Pour la réalisation de cette attaque, les attaquants s’appuient en général sur plusieurs techniques qu’ils adaptent en fonction de chaque cible. Par exemple, pour s’emparer des identifiants individuels, les cyber-attaquants s’appuient sur de l’ingénierie sociale, des Keyloggers ou le vol d’identifiants depuis la mémoire (processus LSASS de Windows par exemple). Tandis que pour les accès applicatifs ou machines, ils ciblent prioritairement les identifiants codés en dur dans les référentiels de code sources tel que GitHub, les fichiers de stockage des secrets cloud utilisés par interface CLI (AWS CLI) et également les fichiers de configuration d’outils d’automatisation CI/CD tels que Jenkins.

La mauvaise configuration des services cloud, une vulnérabilité de plus en plus convoitée

L'adoption croissante des services cloud a métamorphosé les systèmes d’informations qui sont devenus de plus en plus riches, complexes et surtout vulnérables aux cyberattaques.

La nature dynamique du cloud conduit souvent à une mauvaise configuration d'autorisations et de droits associés à des identités ou utilisateurs. Compte-tenu de l'ampleur des déploiements et de la rapidité du changement, il est très compliqué de garantir et maintenir le principe du moindre privilège en associant à chaque identité uniquement les autorisations dont elle a besoin. Ce principe du moindre privilège est couvert par le service de gestion des identités et des accès (Cloud IAM).

Ce service cloud IAM est fourni par l’ensemble des CSP (AWS, Azure, Google, etc.). Il a pour principal objectif d’assurer l’authentification des utilisateurs et gérer leurs autorisations sur les services et les ressources. Bien que les services cloud IAM soient conçus de manière sécurisée par les fournisseurs de services cloud (CSP), ils sont fréquemment mal configurés par les clients pour plusieurs raisons :

• Le manque de compétences sur ce type de composant assez complexe : par exemple, AWS et Azure ont plus de 5 000 autorisations possibles et actions qui peuvent être attribuées.
• Les équipes DevOps priorisent le déploiement des applications (time-to-market), et ceci parfois au détriment de la sécurisation des identités et des accès.

Il faut être conscient que les dommages, engendrés par une mauvaise configuration du service IAM, peuvent avoir un impact destructeur sur l’ensemble de la plateforme cloud. Un cyber-attaquant qui exploite ce type de vulnérabilité pourrait à partir d’un accès standard (développeur par exemple) s’attribuer les permissions du super administrateur cloud à travers des mouvements latéraux et d’élévations de privilèges. En d’autres termes, il sera en capacité de lancer des attaques dévastatrices : vol de données sensibles, destruction d’environnement, ransomware, etc.

A titre d’exemple, une attaque contre une banque américaine spécialisée dans la vente de crédits à la consommation, immobilier et dans la gestion des cartes de crédit a coûté 80 millions de dollars à l'entreprise en raison de configurations IAM trop permissives. En exploitant une vulnérabilité dans AWS WAF (Web Application Firewall), l’attaquant a réussi grâce à des mouvements latéraux à compromettre Amazon Elastic Compute Cloud (EC2) et S3 Buckets.

Exemple d’attaque reposant sur un vol de secrets & une mauvaise configuration des rôles AWS IAM [2]

Pour illustrer les deux types d’attaques présentés ci-dessus, nous allons mettre l’accent sur une attaque identifiée par le laboratoire « Unit42 » et reposant sur un vol de secrets codés en dur dans GitHub et d’une mauvaise configuration des rôles AWS IAM [3].

Avant de présenter la chaîne d’attaque, il est important d’expliquer la notion de rôle IAM dans AWS.  Un rôle IAM AWS, reposant sur le concept RBAC, est une identité IAM conçue pour regrouper des permissions communes à un groupe d’identités ou de services. Les mandataires (utilisateurs AWS, utilisateur fédéré, service ou application) qui ont besoin des mêmes permissions assumeront le même rôle.

Lorsqu’un mandataire assume un rôle IAM, il reçoit des accès temporaires (Token) qui lui donnent accès aux permissions/ressources rattachées au rôle en question. Une fois le « Token » expiré au bout de 12 heures maximum, la demande d’un nouveau « Token » est nécessaire pour maintenir l’accès aux ressources.

Figure 1 : attaque basée sur un vol de secrets depuis GitHub et une mauvaise configuration des rôles AWS IAM

• Le cyber-attaquant scanne les dépôts de code dans GitHub à la recherche de secrets AWS codés en dur.  En effet, des développeurs - inconscients des risques majeurs auxquels ils exposent leurs entreprises - codent en dur des secrets dans leurs projets. Cette pratique est plus courante dans les équipes DevOps qui déposent leurs codes dans des référentiels cloud tels que GitHub. Ces secrets pourraient être facilement scannés via l’API GitHub et identifiés à travers des expressions régulières. Selon une publication de chercheurs de la North Carolina State University [4], plus de 100 000 référentiels GitHub exposent leurs secrets. Bien que ce chiffre soit alarmant, cette étude ne concernait que 13% des dépôts GitHub et les jetons d'accès (Access Token) d'un nombre limité de fournisseurs cloud.
• L’attaquant se connecte à AWS via les secrets (AccessKeyId, SecretAccessKey) dérobés depuis GitHub et vérifie ses permissions en utilisant l’API IAM d’AWS [5].
• Le cyber attaquant découvre que l’identité dérobée dispose de la permission IAM:PassRole sans restrictions ni conditions : 
  

En d’autres termes, l’attaquant pourrait attacher n’importe quel rôle à n’importe quel service à condition de respecter les « Trust Policy ». Cette dernière désigne, pour chaque rôle, la liste des mandataires « service dans notre exemple » qui pourrait l’assumer.  La « Trust Policy » suivante stipule que le service EC2 peut assumer le rôle auquel est rattachée cette permission : 

• Ensuite, l’attaquant recherche des rôles de service qui disposent de plus hauts privilèges tout en vérifiant leur Trust Policy. A chaque fois qu’il trouve un rôle de service avec plus de privilège que l’identité avec laquelle il s’est connecté, il le rattache à l’instance du service EC2 et escalade ses privilèges.
• Finalement, l’attaquant trouve des rôles de service avec des permissions « Administrator Access ».
• L’attaquant assigne « l’Administrator Access » Rôle à une VM provisionnée dans l’instance EC2.
• Il se connecte à la VM et lance des appels API au service metadata d’AWS pour récupérer le token de session via l’URL  « http://169.254.169.254/latest/meta-data ». Ce token de session offre à l’attaquant les droits les plus élevés sur le système visé.

En synthèse, cet « exploit » (vulnérabilité pour laquelle existe un mode opératoire d’attaque connue) a été rendu possible à cause de l’exposition des secrets dans GitHub et la mauvaise configuration des politiques d’autorisations du rôle « développeur ». En effet, il n’avait aucune condition sur l’action « PassRole » pour la restreindre au cas d’usages autorisés pour les développeurs. De plus, AdministratorAccess a été attribué à plusieurs rôles IAM qui ont facilité l’élévation de privilèges. Avec AdministratorAccess, un acteur malveillant pourrait exfiltrer des données sensibles, perturber le fonctionnement de l'entreprise ou verrouiller toute l'infrastructure avec un ransomware.

Comment se prémunir contre cette attaque ?

Pour se protéger contre ce type d’attaque, ci-dessous une liste non exhaustive des 5 mesures que nous pensons utile de prendre en considération : 

Pour aller plus loin

Les dirigeants, les conseils d'administration et les responsables de la cybersécurité ne sont pas toujours informés des menaces que suscitent les nouvelles formes émergentes de cybercriminalité. Ce bulletin propose une vision claire de ces menaces, qu’elles soient sectorielles, informatiques ou mobiles. Il présente les dernières tendances ainsi qu’une version synthétique des rapports proposés chaque semaine à nos clients. N’hésitez pas à nous contacter pour plus d’informations

Nos atouts

• Le Lab : 600m2 dédiés à la recherche et au développement à l’innovation et à la transformation numérique.
• War Room : Un environnement hautement sécurisé exploitant des solutions collaboratives et des technologies propriétaires innovantes.
• Cyber Teams : L’équipe EY France cybersécurité est composée d’experts pluridisciplinaires, proposant des solutions nouvelles pour résoudre des problématiques stratégiques pour nos clients.
• CyberEye : Une solution leader de Cyber Threat Intelligence solution, apportant une connaissance précise des cybermenaces pouvant toucher les entreprises.
• ASC and CTI : Nos 63 Advanced Security Centers, situés dans de nombreux pays, partagent des renseignements opérationnels et centrés vers les entreprises pour notre Cyber Threat Intelligence.

Ce qu’il faut retenir :

Les restrictions liées à la crise sanitaire COVID-19 ont constitué une réalité inattendue pour les organisations de toutes tailles. Du jour au lendemain, les entreprises ont été contraintes de notamment favoriser la souscription à des services cloud : l’accélération de la mise en place de ces derniers (IaaS, PaaS ou SaaS) a modifié la physionomie des cyberattaques. Dans cette nouvelle édition du Bulletin Cyber, les experts EY reviennent sur deux types d’attaques qui ciblent des identités sur des environnements cloud : le vol d’identifiants à privilèges et la mauvaise configuration du service cloud IAM.

[1] https://enterprise.verizon.com/content/verizonenterprise/us/en/index/resources/reports/2020-data-breach-investigations-report.pdf

[2] https://securityboulevard.com/2020/12/understanding-the-2019-capital-one-attack/

[3] https://unit42.paloaltonetworks.com/iam-roles-compromised-workloads/

[4] https://www.ndss-symposium.org/wp-content/uploads/2019/02/ndss2019_04B-3_Meli_paper.pdf

[5] https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/index.html

[6] https://docs.aws.amazon.com/fr_fr/IAM/latest/UserGuide/reference_policies_elements_principal.html