Quel est le degré de sécurité d'un environnement d'informatique dématérialisée conforme aux normes CIS/AWS ?

Blogpost 29 avril 2021 par Roy Stultiens, Analyste sécurité chez Bureau Veritas Cybersecurity

Chez Bureau Veritas Cybersecurity, nous voyons des clients qui souhaitent se conformer aux normes du secteur ou aux référentiels de sécurité pour s'assurer que leur environnement cloud est correctement sécurisé. Dans les environnements cloud, l'un des référentiels les plus courants est celui du CIS (Center for Internet Security [1]). Ces référentiels apportent une valeur et une sécurité de base à un environnement, mais vous pouvez toujours être exposé à un risque d'attaque, comme le montre notre étude.

L'un de nos analystes en sécurité a mené une étude pour déterminer le degré de sécurité d'un environnement en nuage AWS entièrement conforme aux normes CIS et si cet environnement protège contre les erreurs de configuration et les vulnérabilités les plus courantes. Les résultats montrent qu'avec trois lignes de base couramment utilisées, 4 des 6 attaques les plus courantes peuvent être menées. Dans cet article, nous partageons les détails de cette recherche et fournissons des conseils sur les erreurs de configuration et les failles de sécurité les plus courantes afin de vous aider à sécuriser votre cloud.

Benchmarks/Baselines de sécurité couramment utilisés

Tout d'abord, les cadres de sécurité AWS les plus populaires ont été rassemblés car couramment utilisés par nos clients et issus de notre expérience en matière d'évaluation du cloud. Pour AWS, trois cadres de sécurité ont été identifiés, à savoir :

CIS Amazon Web Services Foundations benchmark v1.2 (2018) [2]
Ce benchmark est de loin le plus populaire et fournit 49 recommandations de sécurité sur l'IAM, la journalisation, la surveillance et la mise en réseau. La recommandation est soit de niveau 1, soit de niveau 2, le niveau 2 étant des mesures de défense approfondies qui pourraient avoir un impact sur la performance d'un service. Les recommandations sont génériques et peuvent être appliquées à tous les environnements AWS.
CIS AWS Three-tier Web Architecture benchmark v1.0 (2016) [3]
Le Three-tier benchmark se compose de 96 recommandations, spécifiées pour des services spécifiques, tels que EC2 (Elastic Computing) et les bases de données. Le document est axé sur l'utilisation de l'architecture à trois niveaux. La mise en œuvre de ce benchmark sur d'autres architectures nécessite des connaissances approfondies de la part de l'utilisateur.
Norme AWS Foundational Security Best Practices [4]
Cette norme est publiée par AWS et fait l'objet d'un développement constant. Au moment de la rédaction du présent document, elle comporte 70 recommandations en matière de sécurité, tandis que pendant les recherches, elle se composait de 31 règles. Toutes les règles sont spécifiques à un service et sont entièrement intégrées au AWS Security Hub.

Mauvaises configurations et/ou vulnérabilités courantes dans le Cloud/AWS

Bien que Bureau Veritas Cybersecurity utilise des repères de sécurité et des lignes de base dans ses évaluations du cloud, nos experts ont tendance à adopter une approche holistique plutôt que de vérifier uniquement ces lignes de base. Lors d'évaluations de clouds menées dans la vie réelle, de nombreuses configurations erronées et vulnérabilités différentes ont été trouvées. Voici une sélection des plus courantes :

Falsification des requêtes côté serveur (SSRF) sur EC2 [5]
Dans ce scénario, une instance de calcul AWS (EC2) est lancée avec des autorisations de lecture des buckets S3. Cependant, le webservice s'exécutant sur l'instance contient une vulnérabilité qui permet à un attaquant de laisser le serveur exécuter des requêtes en son nom. Un attaquant peut en abuser pour interroger le service de métadonnées d'instance d'AWS et extraire les identifiants que la machine utilise pour accéder aux buckets S3. Vous trouverez plus de détails dans cette vidéo.
Secrets stockés dans les données utilisateur des instances EC2 [6]
Les données utilisateur sur les instances EC2 sont souvent utilisées pour les scripts de configuration du premier démarrage. Il peut être tentant de stocker des secrets tels que des clés d'API ou d'accès dans les données utilisateur, de sorte qu'ils puissent être transmis à la machine pendant l'installation. Cependant, ces données ne sont pas chiffrées et peuvent être extraites à l'aide du service de métadonnées d'instance ou de la console AWS. Le stockage de secrets dans les données utilisateur n'est pas seulement un risque pour les attaquants extérieurs, les initiés peuvent également extraire des informations précieuses. Vous trouverez plus de détails dans cette vidéo.
Instantanés publics de volumes EBS [7]
Les volumes Elastic Block Store (EBS) sont les disques durs des instances EC2. L'utilisation d'instantanés pour pouvoir ramener la machine à un état antérieur est une bonne pratique courante. AWS permet aux utilisateurs de partager leurs instantanés, soit avec des comptes AWS spécifiques, soit avec tous les comptes (public). Les snapshots publics peuvent être clonés par tout le monde, les données résidant dans le snapshot ne sont pas sûres et peuvent facilement être extraites et analysées à la recherche de secrets. Consultez la recherche de Bishopfox.
Autorisations publiques de lecture/écriture sur les buckets S3
Les buckets S3 mal configurés sont peut-être la cause la plus connue des violations de données. Ces derniers permettent un stockage quasi illimité et peuvent être configurés pour autoriser l'accès public. Si cette configuration est faite, il suffit d'avoir le nom du bucket pour extraire toutes les données.
Vulnérabilités d'injection de code dans les fonctions Lambda [8]
Elles peuvent être utilisées pour toutes sortes de tâches, telles que l'étiquetage d'objets, le traitement d'images et les notifications. Pour mener à bien ces tâches, les fonctions reçoivent souvent des autorisations via des rôles IAM sur d'autres services AWS, tels que S3 ou EC2. Lorsque l'événement est déclenché, la fonction Lambda se déclenche et exécute le code programmé. Si ce code contient une vulnérabilité d'injection, un attaquant pourrait être en mesure d'extraire les variables système de la fonction. Cela inclut les identifiants AWS qui sont utilisés pour accéder à d'autres services AWS. Vous trouverez plus de détails dans cette vidéo.
Secrets stockés dans les variables d'environnement des fonctions Lambda
Les fonctions Lambda sont des services de calcul sans serveur qui surveillent l'environnement. Lors de la création d'une fonction Lambda, il est possible d'attribuer des variables d'environnement, qui peuvent être utilisées par le code à l'intérieur de la fonction. Souvent, ces variables incluent des secrets, tels que des clés d'API ou même des identifiants d'accès. Les variables d'environnement peuvent être extraites par un attaquant si une vulnérabilité d'injection de code existe dans le code. En outre, les attaquants internes peuvent lire les variables d'environnement configurées en texte clair.

Un environnement conforme vulnérable

Pour vérifier si les environnements en nuage conformes sont exposés aux attaques susmentionnées, nous avons mis en place un environnement de test AWS. Toutes ces vulnérabilités ont été développées en scénarios déployables à l'aide de Terraform. Terraform est un outil logiciel infra-as-code, qui permet aux utilisateurs de définir le code de l'infrastructure. Cela garantit que chaque fois que les scénarios sont déployés, ils sont exactement les mêmes et ne nécessitent pas de configurations manuelles.

L'environnement de test AWS a été configuré pour être conforme aux différents référentiels et normes de sécurité. Les ressources ont ensuite été déployées à l'aide de Terraform. Après le déploiement, l'environnement a été analysé pour s'assurer qu'il était toujours conforme aux normes de sécurité.

Résultats

Chaque attaque a été exécutée dans l'environnement de test. Les résultats sont présentés dans le tableau ci-dessous, où X indique que l'attaque n'est pas protégée et où, dans le cas contraire, le contrôle correspondant est affiché :

Les résultats indiquent que le benchmark de sécurité le plus courant, le benchmark CIS AWS Foundations, ne protège contre aucune des attaques mises en œuvre! Le cadre offre un environnement plus sécurisé, mais il manque des défenses approfondies pour les services AWS populaires et couramment utilisés tels que EC2, S3 et Lambda.

Le cadre à trois niveaux empêche d'avoir des instantanés EBS publics grâce aux contrôles 1.5 et 1.6, mais d'autres attaques ou configurations erronées sont toujours possibles. Les contrôles 1.5 et 1.6 garantissent que les volumes EBS sont chiffrés. Cela empêche les instantanés d'être partagés publiquement, puisque la clé de décryptage n'est pas accessible au public. Ce cadre est moins souvent utilisé car il est plus difficile à appliquer aux architectures génériques de cloud.

La norme AWS Foundational Security Best Practices offre une meilleure protection, notamment contre les buckets S3 exposés publiquement. Les contrôles S3.1 - S3.3 stipulent explicitement que les buckets ne doivent pas être accessibles au public en lecture ou en écriture. Cela permet d'éviter la principale raison des violations de données liées à l'informatique dématérialisée. De plus, le contrôle EC2.1 empêche les instantanés EBS, mais même avec cette ligne de base mise en œuvre, l'environnement est toujours susceptible de subir 4 des 6 attaques !

Conclusion

Cette étude donne un aperçu des raisons pour lesquelles les attaques susmentionnées sont couramment couronnées de succès lors de nos enquêtes sur l'informatique dématérialisée chez nos clients. Le fait de se conformer à un ou plusieurs cadres de sécurité pour l'informatique en nuage permet d'avoir un environnement sécurisé, mais ce n'est pas suffisant. Nos recherches ont permis d'identifier plusieurs attaques courantes et de les comparer aux lignes de base de sécurité connues pour les environnements AWS. Les résultats montrent que les cadres de sécurité existants n'offrent pas une protection adéquate contre ces attaques courantes. Il ne suffit pas d'être conforme pour disposer d'un environnement sécurisé : des contrôles supplémentaires doivent être effectués.

Cela ne signifie pas que les cadres étudiés ne doivent pas être utilisés ou qu'ils donnent de mauvaises recommandations. Au contraire, ces cadres fournissent un niveau de sécurité de base nécessaire avant de mettre en œuvre des mesures plus approfondies. Pour nos experts, les lignes de base constituent une bonne vérification des fruits les plus faciles à cueillir, tandis que leur créativité permet de tester votre défense en profondeur. Nous vous suggérons d'examiner votre environnement cloud au-delà de ces lignes de base pour vous assurer que vous êtes à l'abri de ces attaques courantes.

A propos de Secura

Écrit par Roy Stultiens. Roy est l'un des experts en cybersécurité du Bureau Veritas Cybersecurity. Passionné par la sécurité du cloud, il est un membre actif du groupe de connaissances sur le cloud. Avec ce groupe, il effectue régulièrement des pentests sur le cloud et partage ses expériences avec ses collègues et ses clients dans ce domaine en pleine évolution.

Notes de bas de page :

[1] Center for Internet Securtiy : https://www.cisecurity.org
[2] Livre blanc du CIS sur les fondements des services Web d'Amazon : https://d0.awsstatic.com/white...
[3] Livre blanc du CIS sur les servicesWeb à trois niveaux : https://d0.awsstatic.com/white...
[4] AWS Foundational Security Best Practices standard : https://docs.aws.amazon.com/se...
[5] Server Side Request Forgery (SSRF) sur EC2 : https://youtu.be/6U-DpyEoVRs...
[6] Secrets stockés dans les données utilisateur sur les instances EC2 : https://youtu.be/-p5yCrrsTFA
[7] Dufflebag : Uncovering Secrets in Exposed EBS Volumes : https://labs. bishopfox.com/tec...
[8] Vulnérabilités d'injection de code dans les fonctions Lambda : https://youtu.be/gl2hEmN67ms