Introduction à la sécurité des environnements AWS

Magazine
Marque
MISC
Numéro
105
|
Mois de parution
septembre 2019
|
Domaines


Résumé

AWS est un vaste écosystème qui intègre un grand nombre de services en tout genre, traitant aussi bien de stockage, de calcul et de réseau que d’IoT, d’IA et de robotique.Nous allons nous intéresser à quelques éléments d’introduction à la sécurité des environnements AWS, en nous fixant pour objectif de disposer de toutes les connaissances nécessaires à la compréhension de la suite du dossier, qui traitera des techniques d’intrusion, d’élévation de privilèges et de post-exploitation au sein d’un environnement AWS, ainsi que des problématiques de détection et de réponse à incident.


Body

 

1. En quoi les environnements AWS posent-ils problème ?

AWS ne se réduit pas à un service de cloudcomputing mettant à disposition des machines virtuelles : les infrastructures que l’on y trouve sont bien plus complexes, et contiennent souvent des ressources sensibles. Il n’est pas rare, en effet, de voir des entreprises y déporter une partie significative de leur système d’information, allant parfois jusqu’à mettre en place une association entre leur réseau local et leur infrastructure cloud, notamment en fédérant les identités de leur Active Directory avec celles de leur compte AWS.

Pour être à la hauteur de ces enjeux, Amazon propose un nombre conséquent de services de sécurité, permettant de gérer les clés de chiffrement, de stocker les secrets, de filtrer les flux réseau, de détecter les attaques ou encore de contrôler les accès.

Bien que cette multitude de services garantisse, en théorie, un bon niveau de sécurité, elle présente un inconvénient majeur : sa grande complexité. De fait, les concepts de sécurité sont parfois très pointus, la configuration des mécanismes impliqués souvent exigeante et la maîtrise d’un environnement en perpétuelle évolution toujours difficile.

Par conséquent, dans la pratique, des défauts de configuration apparaissent régulièrement, créant ainsi les conditions de possibilité pour un attaquant de s’introduire dans l’environnement, ou d’y compromettre des ressources.

La criticité des environnements AWS, qui nous amène à nous y intéresser, tient donc d’une part de la nature sensible des ressources qu’ils hébergent, et d’autre part de la difficulté d’y maintenir un bon niveau de sécurité à mesure qu’ils évoluent.

2. La gestion des identités et des accès

Parmi tous les services de sécurité proposés par AWS, le gestionnaire d’identités et d’accès (IAM) est sans doute le plus important, du fait de sa dimension structurelle et de l’étendue de son champ d’application.

Nous aurons l’occasion de le rencontrer à de nombreuses reprises, prenons donc le temps d’en comprendre les grands principes.

2.1 Les entités

Le service IAM distingue deux typologies d’entité: les identités et les ressources.

2.1.1 Les identités

Les identités correspondent soit à un utilisateur – c’est-à-dire à une personne physique, soit à un groupe d’utilisateurs, soit à un rôle.

La notion de rôle est spécifique à AWS et doit être parfaitement comprise avant d’aborder les prochains sujets.

Un rôle est un ensemble de permissions « flottantes », que l’on peut accorder de manière temporaire à une identité ou à une ressource. En cela, un rôle peut être représenté par une casquette, indicatrice d’une fonction, qui peut être portée par les uns ou par les autres, sans que la fonction qu’elle représente ne soit liée de manière persistante à celui qui la porte. Ainsi, plutôt que d’ajouter un utilisateur ponctuel à un groupe de projet, on préférera lui attribuer un rôle lui donnant temporairement un accès limité à l’environnement de travail. Par ailleurs, dans la pratique, les rôles sont régulièrement utilisés pour mutualiser des droits associés à des ressources, celles-ci ne pouvant être ajoutées à un groupe.

Nous n’irons pas plus loin sur le fonctionnement des rôles pour le moment, mais aurons l’occasion d’apporter quelques précisions sur leurs modalités d’approbation dans l’article « Compromission des services exposés d’AWS ».

2.1.2 Les ressources

Une ressource est, selon les termes utilisés dans la documentation AWS, « une entité que l’on peut utiliser ». Cela concerne les espaces de stockage, les machines virtuelles, les clés de chiffrement, les modèles de déploiement, et bien d’autres choses encore.

D’une certaine manière, les ressources peuvent également être vues comme des sujets, dans la mesure où elles peuvent utiliser d’autres ressources. Par exemple, une machine virtuelle peut utiliser un espace de stockage ou une clé de chiffrement et, en cela, doit être désignée explicitement comme exécutante légitime des actions qu’elle réalise, au même titre qu’une identité.

2.2 Les politiques de sécurité

Tous les accès, qu’ils émanent indifféremment d’une identité ou d’une ressource, sont réglementés par des politiques de sécurité, également appelées stratégies de sécurité.

Une politique peut être attachée à un utilisateur, à un groupe d’utilisateurs, à un rôle (définissant ainsi la fonction qu’il représente), ou à une ressource.

Elle prend la forme d’un document JSON, constitué de la manière suivante :

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "Accès stratégies Administrateurs",
            "Effect": "Allow",
            "Action": [
                "iam:ListGroupPolicies",
            ],
            "Resource": "arn:aws:iam::1234:group/Administrateurs"
        }
    ]
}

Cette politique signifie que les entités auxquelles elle est attachée ont le droit (Allow) de lister les politiques de sécurité liées à un groupe (iam:ListGroupPolicies), et plus précisément au groupe « Administrateurs » du compte AWS identifié par le numéro 1234.

L’ARN, pour Amazon Ressource Name, est une typologie d’identification des éléments d’un environnement AWS, qu’il s’agisse indifféremment d’une identité IAM, d’une ressource, d’une politique de sécurité, ou encore d’une clé de chiffrement.

La forme générique inclut notamment le service concerné (ici IAM), l’identifiant du compte AWS (1234), le type de l’entité visée (groupe) et le nom de cette entité (Administrateurs).

3. Utiliser AWS

Il existe trois vecteurs d’administration d’un environnement AWS : l’application web dite « console », la bibliothèque de programmation boto3, et l’outil en ligne de commandes awscli. Les trois interagissent avec une API commune, qui agrège toutes les fonctionnalités existantes.

Seul l’accès à la console nécessite un couple (nom d’utilisateur, mot de passe) : les appels effectués depuis la ligne de commandes [1] utilisent, pour les utilisateurs (nous verrons plus tard qu’il n’en va pas de même pour les rôles), un couple de clés d’API (Access Key ID, Secret Access Key ID). Ces clés sont générées depuis la console, et doivent ensuite être configurées sur l’environnement local.

Nous supposerons tout au long du dossier que nous utilisons un environnement Linux.

Commençons par installer awscli, en utilisant l’utilitaire pip :

$ pip3 install awscli

Vérifions que l’outil est effectivement installé :

$ aws --version

aws-cli/1.16.118 Python/3.7.3rc1 Linux/4.19.0-debian-amd64 botocore/1.12.108

Tout semble bon ! À présent, nous allons configurer les clés d’API que nous avons générées depuis le service IAM de notre environnement AWS :

$ aws configure     

AWS Access Key ID []: AKIAI[...]XBLLXKSQ

AWS Secret Access Key []: oDe6L[...]MTpEfZlVz

Désormais, tous les appels à l’API que nous réaliserons au moyen de la commande aws seront effectués avec les permissions accordées à notre utilisateur.

Les commandes suivent le modèle suivant :

aws $service $appel $arguments

$service correspondant au service concerné par notre requête, $appel le nom de la méthode d’API utilisée, et $arguments aux arguments de la méthode.

Nous pouvons par exemple lister nos groupes, en interrogeant le service iam avec l’appel list-groups :

$ aws iam list-groups

{

    "Groups": [

        {

            "Path": "/",

            "GroupName": "Production",

            "GroupId": "AGPAJS[...]XP6PGEE",

            "Arn": "arn:aws:iam::1234:group/Production",

            [..]

        },

        {

            "Path": "/",

            "GroupName": "Admin_SiteA",

            "GroupId": "AGPA[...]BN2O",

            "Arn": "arn:aws:iam::1234:group/Admin_SiteA",

            "CreateDate": "2019-03-06T15:09:59Z"

        }

 ]

}

Le résultat nous indique que nous appartenons aux groupes « Production » et « Admin_SiteA ».

La liste de tous les appels à l’API, ainsi que leur documentation, est référencée dans le document AWS CLI Command Reference [1].

Conclusion

AWS propose de nombreux services de sécurité, mais ce nombre ainsi que leur complexité rend leur bonne utilisation difficile. Maintenant que nous avons en introduit les bases, je vous propose de découvrir quelques techniques d’intrusion dans l’article 2 « Compromission des services exposés d’AWS »du présent dossier.

Référence

[1] https://docs.aws.amazon.com/cli/latest/reference/

 

Sur le même sujet

Implémentation d’une architecture processeur non supportée sur IDA PRO et Ghidra

Magazine
Marque
MISC
HS n°
Numéro
21
|
Mois de parution
juillet 2020
|
Domaines
Résumé

Malgré le nombre d’outils aidant au désassemblage voire à la décompilation de programmes, il arrive parfois que les mécanismes ou les processeurs étudiés ne soient pas nativement supportés. Pour cette raison, certains outils proposent des API permettant d’implémenter une nouvelle architecture. Cet article détaillera les grandes étapes de ce travail pour deux outils majoritairement utilisés, à savoir IDA PRO et Ghidra.

Contrôles de suivi de la conformité RGPD et d’atteinte d’objectifs définis dans la politique de protection de la vie privée

Magazine
Marque
MISC
Numéro
110
|
Mois de parution
juillet 2020
|
Domaines
Résumé

Afin de mettre en application les exigences de contrôle de conformité (article 24 du RGPD), les directions générales, qu’elles aient désigné ou non un Délégué à Protection des Données (DPD), doivent mettre en œuvre des contrôles concernant les répartitions de responsabilités entre les acteurs impliqués par le traitement et l’application de règles opposables, l’effectivité des droits des personnes concernées, la sécurité des traitements et la mise à disposition des éléments de preuve pour démontrer la conformité des traitements de données à caractère personnel.

Stack Buffer Overflow

Magazine
Marque
MISC
HS n°
Numéro
21
|
Mois de parution
juillet 2020
|
Domaines
Résumé

Cet article retrace un historique des stack buffer overflow tels qu'ils étaient exploités au début des années 2000 puis passe en détail les protections logicielles et matérielles qui ont été mises en œuvre pour les faire disparaître, ainsi que les mesures créées par les attaquants pour les contourner.

L’empoisonnement de cache DNS : toujours d’actualité ?

Magazine
Marque
MISC
HS n°
Numéro
21
|
Mois de parution
juillet 2020
|
Domaines
Résumé

Le Domain Name System (DNS) est l’un des protocoles réseau centraux au bon fonctionnement de l’Internet moderne. Ce protocole permet la résolution de noms « symboliques » – les noms de domaine – en des ressources, notamment des adresses IP. Malgré son omniprésence dans notre quotidien, sa sécurisation a été incrémentale et laborieuse. Cet article traite d’une attaque aussi vieille que le DNS, l’empoisonnement de cache, contre laquelle les dernières avancées, comme DNS-over-HTTPS, pourraient permettre de se protéger enfin complètement. Ou le pourront-elles ?

Zero Trust : anti-SOC, tu perds ton sang froid ?

Magazine
Marque
MISC
Numéro
110
|
Mois de parution
juillet 2020
|
Domaines
Résumé

Les security operation centers, au sens large, sont aujourd’hui au cœur des systèmes d’information des entreprises. En revanche, beaucoup adoptent encore et toujours une approche traditionnelle de la sécurité du SI. Comment le paradigme Zero Trust va-t-il impacter nos supervisions ? Repensons un peu à toutes ces années de service pour voir ce que Zero Trust peut apporter au SOC, et réciproquement comment ces derniers peuvent accompagner la transition.

Par le même auteur

Compromission des services exposés d’AWS

Magazine
Marque
MISC
Numéro
105
|
Mois de parution
septembre 2019
|
Domaines
Résumé

Les infrastructures AWS intègrent souvent un périmètre exposé sur Internet. Au moyen de la compromission de ces actifs publiquement accessibles, nous allons conduire des attaques qui nous permettront de nous introduire dans un environnement AWS.

Élévation de privilèges et post-exploitation au sein d’un environnement AWS

Magazine
Marque
MISC
Numéro
105
|
Mois de parution
septembre 2019
|
Domaines
Résumé

Lorsqu’un attaquant parvient à s’introduire dans un environnement AWS, il ne peut opérer de manière directe que sur un périmètre limité. Voyons dans quelle mesure et par quels moyens il est possible d’y élever ses privilèges, et ce qu’il serait intéressant de compromettre.

Introduction à la sécurité des environnements AWS

Magazine
Marque
MISC
Numéro
105
|
Mois de parution
septembre 2019
|
Domaines
Résumé

AWS est un vaste écosystème qui intègre un grand nombre de services en tout genre, traitant aussi bien de stockage, de calcul et de réseau que d’IoT, d’IA et de robotique.Nous allons nous intéresser à quelques éléments d’introduction à la sécurité des environnements AWS, en nous fixant pour objectif de disposer de toutes les connaissances nécessaires à la compréhension de la suite du dossier, qui traitera des techniques d’intrusion, d’élévation de privilèges et de post-exploitation au sein d’un environnement AWS, ainsi que des problématiques de détection et de réponse à incident.