22 mars 2022
Par Thyaga Vasudevan - Vice-président de la gestion des produits, Skyhigh Security
Le passage à une architecture cloud-native pour vos applications d'entreprise peut apporter une valeur commerciale considérable, en ajoutant de l'échelle et de l'agilité tout en déchargeant les tâches onéreuses telles que les correctifs et la mise à niveau de l'infrastructure du serveur.
Cependant, dans chaque environnement en nuage, qu'il s'agisse d'Amazon Web Services (AWS), d'Azure ou de Google Cloud, il existe une nouvelle catégorie de risques. Les menaces liées à l'informatique en nuage découlent du nouveau contexte et des nouvelles exigences de configuration que vous avez dans un environnement en nuage. Historiquement, les paramètres par défaut tels que l'accès public aux objets de stockage ont laissé les données sensibles à l'air libre, faciles à voler par toute personne cherchant ces faiblesses.
Il est facile de commettre des erreurs dans un nouvel environnement, où de nouveaux paramètres sont introduits en permanence au fur et à mesure que de nouvelles fonctionnalités sont ajoutées par les fournisseurs d'informatique en nuage. La configuration de votre environnement en nuage relève toujours de votre responsabilité. AWS et les autres fournisseurs n'ont aucun contrôle sur la façon dont vous utilisez leurs services. Ils ne sont qu'un modèle à partir duquel vous pouvez construire.
Ne pas comprendre les résultats de vos configurations et la façon dont vous créez des applications natives pour l'informatique en nuage peut avoir des conséquences catastrophiques. Et même les clients les plus avisés peuvent en souffrir.
L'exemple le plus frappant est celui de la faille subie par Capital One il y a près de trois ans : un pirate a eu accès aux numéros de sécurité sociale de 100 millions de personnes aux États-Unis et aux numéros d'assurance sociale de 6 millions de personnes au Canada. Le pirate a utilisé plusieurs techniques pour accéder aux données, mais il a surtout appris qu'une fonction de sécurité conçue pour protéger l'accès aux machines virtuelles - les instances d'Elastic Compute Cloud (EC) - a ajouté le pirate. Cette fonction est appelée Instance Metadata service ou IMDS.
Attaques sur les métadonnées d'instance
La version 1 d'IMDS (IMDSv1) a été publiée en 2012 pour permettre aux instances EC2 d'interagir de manière plus sécurisée avec d'autres services AWS. Au lieu de laisser les clés AWS sur l'instance, les clients peuvent désormais demander à l'instance EC2 d'interroger le service de métadonnées pour obtenir des informations d'identification et effectuer des appels API AWS vers d'autres services AWS. Par exemple, si une instance EC2 obtenait des données sur un client, elle pouvait utiliser IMDSv1 pour stocker ces données dans un seau Amazon Simple Storage Service (S3). C'est précisément cette capacité que l'attaquant a utilisée pour extraire des informations sensibles d'un bac S3 utilisé pour stocker des informations sur les clients de Capital One.
Lors de nos propres tests, nous avons pu reproduire la manière dont cette extraction de données pouvait fonctionner dans n'importe quelle application. Dans notre exemple, une équipe d'épidémiologistes a construit une application cloud-native dans AWS avec un tableau de bord public pour représenter visuellement les données montrant leurs progrès dans l'analyse du génome d'un virus.
Au cours de la phase de développement de cette application, l'équipe s'est heurtée à un problème. La plupart des ressources de leur nuage privé virtuel (VPC) étaient censées être cachées de l'internet. La seule ressource de leur VPC destinée à être visible par le public était le tableau de bord.
Le panier S3 hébergeant leurs données devait rester privé. Pour extraire les données de S3 vers le tableau de bord public, ils ont ajouté un proxy inverse, agissant en tant qu'intermédiaire. Il a suffi d'une recherche rapide sur Google et de quelques lignes de code pour l'ajouter à leur application.
Pour l'équipe d'épidémiologistes, le proxy inverse était une solution basique et élégante qui fonctionnait parfaitement pour leur cas d'utilisation. Ce qu'ils ne savaient pas, c'est que cette solution les exposait à une violation massive.
L'instance de calcul qui exécute le proxy inverse s'est vu attribuer un rôle IAM avec l'autorisation d'accéder à son seau S3 privé. Les informations d'identification permettant au proxy inverse d'accéder à S3 ont été obtenues à partir des métadonnées de l'instance.
Un pirate visitant le site et intéressé par ses données a remarqué que l'équipe avait référencé l'adresse IP du proxy inverse dans le tableau de bord. Il a alors vérifié s'il pouvait s'y connecter. Après avoir confirmé sa connectivité, l'attaquant a vérifié s'il pouvait accéder aux métadonnées de l'instance par l'intermédiaire du proxy inverse. Succès.
Par le biais du proxy inverse et des métadonnées d'instance, l'attaquant a découvert les informations d'identification relatives à l'espace de stockage privé S3 de l'équipe.
Maintenant, avec l'accès à la corbeille S3, l'attaquant pouvait voler les données hautement sensibles que l'équipe avait stockées pour leur application. Il lui suffisait de synchroniser le bac S3 cible avec son propre bac S3 dans un autre compte AWS pour s'approprier les données.
Ce type d'attaque n'est qu'une des 43 techniques décrites par MITRE dans son cadre ATT&CK pour les environnements en nuage : https://attack.mitre.org/matrices/enterprise/cloud/
Comment AWS atténue les attaques sur les métadonnées des instances
Pour améliorer la sécurité de ce service, AWS a publié IMDSv2, qui ajoute plusieurs nouvelles couches de protection.
Dans IMDSv2, les utilisateurs externes ne peuvent pas recevoir d'informations d'identification et seules les ressources de l'application peuvent les recevoir. Pour en savoir plus sur cette couche de protection et sur IMDSv2, cliquez sur le lien suivant : https://aws.amazon.com/blogs/security/defense-in-depth-open-firewalls-reverse-proxies-ssrf-vulnerabilities-ec2-instance-metadata-service/
Cependant, le défi reste que IMDSv1 est toujours d'actualité. Rien dans AWS n'empêche les clients d'utiliser IMDSv1, et vous pouvez toujours l'utiliser par défaut pour toutes vos instances EC2. Comme nous l'avons déjà mentionné, ce n'est pas à AWS de s'assurer que vous utilisez le nuage en toute sécurité. Cette responsabilité incombe uniquement au client.
Dans l'attaque que nous venons de décrire, le proxy inverse a été mal configuré pour permettre à des requêtes externes d'atteindre des ressources internes. Si l'équipe avait configuré son instance de calcul pour utiliser IMDSv2, l'accès non autorisé de l'acteur externe aurait été bloqué.
Comment Skyhigh Cloud Native Application Protection peut vous aider
Sur Skyhigh Security, nous avons plusieurs approches qui peuvent vous aider à détecter et à prévenir les attaques de ce type. Skyhigh Cloud Native Application Protection Platform (CNAPP) est notre plateforme de sécurité cloud-native qui vous permet de surveiller et de mettre à jour les configurations dans AWS, Azure, GCP ainsi qu'un large éventail de mesures de sécurité supplémentaires que vous pouvez découvrir ici.
Grâce à une intégration API directe avec AWS, Skyhigh CNAPP surveille en permanence Amazon CloudWatch - un service de surveillance des applications et de l'infrastructure - pour indiquer quelle version d'IMDS vous utilisez dans chaque instance EC2.
Lorsque CloudWatch enregistre une instance utilisant activement IMDSv1, Skyhigh CNAPP génère un incident de sécurité, vous notifiant de mettre à jour votre configuration vers IMDSv2, ce qui empêchera l'accès non autorisé à vos informations d'identification par des utilisateurs externes.
Incidents de politique du CNAPP Skyhigh pour la configuration de la version de l'IMDS
La meilleure pratique consiste à imposer l'utilisation d'IMDSv2 sur vos instances EC2 pour l'ensemble du code local et des utilisateurs. Une fois que vous aurez spécifié qu'IMDSv2 doit être utilisé, IMDSv1 ne fonctionnera plus. AWS fournit des instructions étape par étape sur la façon de configurer vos instances pour utiliser IMDSv2 ici.
Au-delà de cet exemple d'attaque, Skyhigh CNAPP vous permet de mettre en œuvre une série de bonnes pratiques pour protéger vos applications cloud-natives :
- Auditez continuellement vos configurations. Avec Skyhigh CNAPP, vous pouvez analyser les modèles AWS CloudFormation avant qu'ils n'entrent en production, puis détecter toute "dérive" dans vos configurations au fil du temps. Cela vous permet de détecter les mauvaises configurations et d'appliquer un modèle de moindre privilège pour l'autorisation des ressources.
- Appliquer la confiance zéro. Utilisez la confiance zéro comme méthodologie, où seules des ressources spécifiques sont autorisées à fonctionner et à communiquer entre elles. Tout le reste est bloqué.
- Recherchez les vulnérabilités du code. En particulier avec les modèles de distribution de logiciels ouverts comme Docker, il est important de surveiller en permanence les vulnérabilités de vos ressources applicatives.
- Détectez les anomalies et les menaces. Grâce à l'analyse du comportement des utilisateurs et des entités (UEBA), vous pouvez évaluer des millions d'événements dans le cloud afin de détecter les activités anormales et les menaces réelles telles que le vol d'informations d'identification.
- Exécutez la DLP sur les objets de stockage. Comme pour tout autre service en nuage que vous sanctionnez, votre réseau ou vos points d'extrémité, dans AWS, vous pouvez et devez classer vos données dans S3 et exécuter data loss prevention pour stopper les tentatives d'exfiltration.
Contactez-nous pour discuter de la mise en œuvre de ces mesures dans votre propre organisation.
Retour à Blogs