Aujourd’hui, les cyber-attaques font partie de notre quotidien et deviennent de plus en plus nombreuses et sophistiquées.
Par ailleurs, nous évoluons vers des Systèmes d’Information construits sur une diversité d’environnements de plus en plus vaste, notamment grâce au Cloud, maintenant omniprésent dans les SI des entreprises. Cela leur permet d’élargir leurs capacités mais, d’un point de vue sécurité, accroît la surface et les risques d’attaques.
Des techniques classiques de protection et de détection contre les intrusions existent déjà et se développent de manière exponentielle. Celles-ci sont efficaces pour les attaques les plus courantes mais ne sont bien souvent pas ou peu adaptées aux spécificités du Cloud.
Ainsi, des questions se posent sur l’utilisation de stratégies proactives, telle que la Deceptive Security, permettant de garder une longueur d’avance sur les attaquants. Notamment dans le cadre de Cyber-Résilience : comment utiliser ce genre de technologie sur des environnements de types traditionnels et Cloud ?
Dans quels cas utiliser des techniques de Deceptive Security ? Est-ce que les solutions de Deceptive Security dans le Cloud sont développées aujourd’hui ? Y a-t-il des stratégies spécifiques à envisager dans le cadre d’un environnement Cloud comparé au traditionnel ?
Nous répondrons à ces questions dans une mini-série de 2 articles. Dans le premier article, nous vous montrions comment développer et évaluer votre stratégie de leurre. Dans le second article, nous présentons un exemple pratique de sécurité trompeuse dans AWS.
Postulats initiaux et choix du scenario
Grâce à l’expertise Wavestone et aux ressources partagées par notre CyberLab, nous avons conçu un scénario simple pour illustrer l’utilisation de leurres en environnement Cloud AWS. L’exemple détaillé dans la suite est inspiré par un scénario CTF (Capture The Flag) dessiné par l’équipe du CyberLab pour illustrer la propagation latérale d’un attaquant.
De même manière que dans les scénarios traités précédemment, où nous utilisions la Deceptive pour la détection d’attaquants déjà introduits au sein du SI, il s’agit encore une fois d’éviter d’attirer des attaquants opportunistes sur notre réseau dans une optique de Deceptive « de recherche ». Ainsi, nous postulons une infection initiale quelconque, fortement probable (à fortiori dans des environnements Cloud peu maitrisés), et nous concentrons sur la détection de l’intrus en cours de déploiement sur le réseau.
L’application de cette démarche à un environnement AWS n’est pas innocent. Un des apports du Cloud repose en effet dans la gestion des identités simplifiée et la délégation aisée des accès, mais cet atout peut toutefois tourner à l’avantage d’attaquants en cas d’exposition involontaire de ressources ou de création de liens dangereux entre zones de niveau de sécurité différents. Les mesures de durcissement et de prévention ne manquent pas et sont généreusement promues par les fournisseurs Cloud eux-mêmes mais ces vulnérabilités demeurent le lot des comptes et souscriptions peu durcis, dont l’administration obéit trop souvent à des règles encore informelles.
Le scénario d’attaque et de leurrage associé reposera donc sur ce principe de liaison entre deux comptes AWS, ici conçus comme un environnement de production et un autre de développement, moins critique. Nous nous placerons dans un scénario où une relation d’approbation permet de se propager depuis le compte de développement vers le compte de production, via l’endossement d’un rôle cross-account.
Scénario de leurrage
Description du scénario
Partons de l’idée selon laquelle un utilisateur non autorisé a obtenu des accès sur une machine EC2 (domainIntegrated-EC2) au sein du compte de test (infection initiale). Après une première connexion réussie, il tente d’accéder à des ressources couramment utilisées telles que Amazon Simple Storage Service (Amazon S3) ou essaye d’élever ses privilèges en assumant d’autres rôles (rôle chaining) liés au rôle auquel il a accès.
Ce scénario de propagation latérale est une technique d’attaque courante dans les environnements Cloud en raison de la nature de leur architecture et du modèle de responsabilité du cloud computing, où le client est responsable de la sécurisation de ses applications, de ses données et du contrôle d’accès (alors que le fournisseur veille à la sécurité de l’infrastructure sous-jacente).
Tel qu’illustré ci-dessous, les attaques de propagation latérale tirent parti des faiblesses des contrôles de sécurité du client, telles que des autorisations mal configurées ou l’application de mécanismes d’authentification trop faibles, pour obtenir un accès non autorisé à d’autres ressources dans l’environnement.
Scénario du point de vue de l’attaquant
0. Après avoir compromis une machine EC2 « domainIntegrated », l’attaquant s’aperçoit qu’un rôle lui est associé (« Semi-Admin-role ») :
Enumération de la machine EC2 domainIntegrated
Il énumère ensuite les droits du rôle « Semi-Admin-Role » : 
Enumération des droits du rôle Semi-Admin-Role
Tout d’abord ce rôle a des privilèges de modification sur une ressource du compte « AWS – SHARED » : il peut en effet endosser (sts :assumeRole) et modifier (iam :UpdateRole) un rôle intitulé « LambdaAuto ». Il peut ensuite endosser (par « role chaining », étape 5 du schéma ci-dessus) un autre rôle nommé « SecurityAudit» dans un compte différent, intitulé AWS MASTER.
L’attaquant réalise par ailleurs qu’il peut également assumer directement un autre rôle (« IAM-RO-Role ») du compte AWS – MASTER. Ce dernier rôle attire particulièrement son attention car le compte MASTER suggère par son nom un périmètre d’action bien plus important que le simple compte SHARED, et le rôle IAM-RO-Role évoque un périmètre de vision étendu sur les ressources de ce compte.
- L’attaquant endosse le « SemiAdmin-role » qui lui permet par la suite d’assumer le rôle « IAM-RO » et tenter d’autres actions qui lui permettront de bien analyser son champ de vision.
- En effet, après avoir assumé le rôle « IAM-RO », il procède à une énumération de l’IAM où il s’aperçoit des rôles et des utilisateurs dans son champ de vision :
Liste des rôles dans le champ de vision du rôle IAM-RO
Liste des utilisateurs dans le champ de vision du rôle IAM-RO
Le rôle « SecurityAudit » attire particulièrement son attention grâce aux privilèges que ce nom suggère et la description du rôle qui donne des informations sur lesdits privilèges :
Description du rôle SecurityAudit
Toutefois, l’attaquant n’a qu’un accès en lecture sur les ressources listées. Il va donc chercher si certaines de ces ressources sont accessibles en écriture depuis le compte SHARED où il a de hauts privilèges. Par exemple, si certains rôles du comptes MASTER peuvent être endossés par des rôles du compte SHARED :
Liste des rôles pouvant être assumés depuis un compte externe (ici le compte SHARED)
L’attaquant investigue la relation d’approbation du rôle « SecurityAudit », qui justement, autorise un endossement par le rôle « LambdaAuto » du compte SHARED.
3. De retour sur le compte SHARED, l’attaquant n’a plus qu’à vérifier que l’autre pendant de cette relation d’approbation, c’est-à-dire que le rôle « LambdaAuto » autorise bien dans sa politique d’approbation l’endossement du rôle « SecurityAudit ». Ce n’est pas le cas, mais le rôle « SemiAdminRole » lui permet de configurer cette autorisation.
4. Une fois la politique d’approbation du rôle « LambdaAuto » modifiée, il peut maintenant assumer le rôle « LambdaAuto ».
5. Puis, il endosse (par role-chaining) le rôle « SecurityAudit », le véritable leurre.
Role chaining de l’attaquant
Après sa tentative d’endossement du rôle « SecurityAudit » dont il espère les privilèges d’auditeur sécurité (annoncés en étape 1), l’attaquant se retrouve en réalité sans réels pouvoirs, par exemple :
Exemple d’un accès refusé depuis le rôle SecurityAudit
Création des leurres
Le schéma ci-dessous révèle à présent les ajouts de leurres aux différentes étapes de l’attaque et leur configuration par le défenseur :
Scénario du point de vue du défenseur
0. Le rôle « Semi-Admin-Role » est le point d’entrée dans le scenario de leurrage. Il peut donc être associé à toute ressource susceptible d’être compromise (ici l’EC2 « domainIntegrated ») pour rediriger l’attaquant vers les leurres.
Aucune alerte n’est configurée à ce niveau car la connexion du rôle Semi-Admin-Rôle à l’ensemble des ressources du compte SHARED rend probable le déclenchement d’un endossement involontaire et, par suite, d’alertes faussement positives.
1. Une fois le rôle IAM-RO assumé, l’attaquant est donc invité dans un compte entièrement dédié au leurrage et se familiarise avec les ressources alentour, obtenant ainsi une vue d’ensemble complète de tous les rôles et utilisateurs du compte.
2. En peuplant le champ de vision de l’attaquant, non seulement avec le leurre principal « SecurityAudit », mais également avec d’autres rôles et utilisateurs factices, nous nous assurons que l’aspect du compte semble crédible et que notre leurre-clé, le rôle SecurityAudit ne soit pas isolé.
Nous ajoutons ainsi au sein du compte :
- Des Users : différents noms d’utilisateurs attrayants pour l’attaquant.
- Le rôle « LambdaFunction » : ce rôle est créé pour la simulation d’une fonction Lambda qui fait appel aux services AWS.
- Le rôle « LogsAndS3Bucket » : un rôle créé avec objectif de faciliter l’accès aux services de journalisation et aux ressources de stockage S3 au sein du compte.
- Le rôles « taskExecutionRole » : le rôle d’exécution des tâches pouvant être utilisé pour différents objectifs et services associés au compte.
3. Le rôle « SemiAdminRole » a volontairement été configuré avec la permission (iam :UpdateRole) sur le rôle « LambdaAuto » lui permettant de modifier ce rôle et donc d’ajouter la relation d’approbation vers le rôle « SemiAdminRole ». Pour des raisons de surveillance, une première alerte peut être déclenchée à ce niveau lors de la mise à jour de la relation d’approbation de « LambdaAuto » permettant au « SemiAdminRole » de l’assumer.
4. Le rôle « LambdaAuto » est créé volontairement comme la porte d’entrée vers le rôle « SecurityAudit », une fois sa relation d’approbation modifiée grâce aux privilèges du rôle « SeminAdminRole ».
5. Le rôle « SecurityAudit » est volontairement configuré avec une relation d’approbation autorisant le rôle « LambdaAuto » du compte SHARED à l’assumer.
6. A cette étape, l’attaquant avait supposé qu’il obtiendrait des droits d’auditeur de sécurité. Cependant, une politique de contrôle de sécurité (SCP) très restrictive a été appliquée, ne lui accordant aucun privilège sur le compte. 
La politique interdisant toutes actions depuis le rôle Security-Audit-Role
Chaîne d’alerting
Une chaîne d’alerting dans le cloud AWS fait référence à un moyen de communiquer des notifications ou des alertes générées par les services AWS aux utilisateurs ou aux équipes responsables de la gestion de ces services, leur permettant de prendre des mesures rapides pour résoudre les problèmes et minimiser les interruptions de service.
Pour configurer une chaîne d’alerting, vous devez d’abord configurer les services AWS pour générer des alertes lorsque certains événements se produisent, comme un serveur en panne ou une application dépassant un seuil spécifique d’utilisation du processeur. Une fois ces alertes générées, elles peuvent être envoyées à la chaîne d’alerting appropriée en fonction des préférences de notification configurées par l’utilisateur ou l’équipe responsable de la gestion du service.
Afin de détecter l’attaquant, nous utilisons les services AWS suivants pour créer la chaine d’alerting :
- CloudTrail pour traquer les actions réalisées sur le compte AWS compromis ;
- EventBridge pour détecter tout événement « AssumeRole » du rôle « SecurityAudit » et déclencher une alerte ;
- Simple Notification Service (SNS) pour envoyer l’alerte par e-mail avec les informations recueillies lors de l’attaque.
Illustration de la chaîne d’alerting
Etapes de création de la chaîne d’alerting :
Configuration de CloudTrail
La première étape de la création d’une chaîne d’alerting sur AWS consiste à activer CloudTrail (s’il n’est pas activé) dans votre compte AWS. CloudTrail enregistre toutes les activités et calls API dans votre compte, ce qui peut être utile à des fins de sécurité, de conformité et de dépannage.
Partant des logs générés dans CloudTrail, nous avons créé une règle EventBridge qui envoie des notifications au service SNS chaque fois que le rôle « SecurityAudit » est assumé (type d’événement : AssumeRole).
Création d’une règle EventBridge
Une règle permet de surveiller des types d’événements spécifiques et lorsqu’un événement correspondant se produit, il est routé vers le service associé à la règle et traitant l’événement (ici le service SNS).
Le modèle d’événement permet de détecter tous les événements du type « AssumeRole » se produisant dans le compte utilisé et déclencher l’alerte. Afin d’éviter les faux positifs lors du déclenchement des alertes, nous avons affinés le modèle d’événement pour qu’il soit aussi précis que possible pour correspondre aux événements qui nous intéressent.
De ce fait, il sied d’inclure des champs pertinents, tels que la source de l’événement, le type de détail ou des valeurs spécifiques, pour affiner les critères de correspondance. Cela permet de réduire les risques que des événements non liés déclenchent la règle.
Le modèle d’événement détectant tous les événements « AssumeRole » sur le rôle « SecurityAudit »
Le service Eventbridge doit donc être préalablement lié à la cible SNS.
La cible liée à la règle EventBridge
Configuration d’une rubrique SNS
A cette étape, une rubrique SNS est créée et liée à un abonnement d’un point de terminaison par mail authentifié par la suite. Le sujet SNS sera la cible de la règle EventBridge. Après la création du sujet, on procède à l’abonnement par e-mail en sélectionnant l’adresse de messagerie comme protocole (point de terminaison) où on souhaite recevoir les alertes.
On pourrait envisager d’autres cible que mail pour la réception de l’alerte (ServiceNow, SIEM, etc…).
Détails de la rubrique SNS
Personnalisation de l’alerte
Afin de personnaliser le contenu de l’alerte et de n’afficher que les éléments importants recherchés, la fonction Transformateur d’entrée d’EventBridge a été utilisée.
Elle permet de personnaliser le texte d’un événement avant qu’il ne soit transmis à la cible. Pour ce faire, il sied de définir des variables JSON pour référencer des valeurs dans la source d’événement d’origine.
Configuration du transformateur d’entrées
Pour notre cas, les variables répertoriées ci-dessous constitueront le message de l’alerte :
Création du transformateur d’entrée
Modèle d’entrée
Le modèle d’entrée va utiliser les variables définies précédemment au sein du message d’alerte final :
Création du modèle d’entrée
Ainsi, après endossement du rôle « SecurityAudit », une alerte est envoyée au point de terminaison créé :
Exemple du contenu de l’alerte par mail
Coût des services AWS utilisés
AWS offre une approche de paiement à l’utilisation pour la tarification de ses services cloud. Avec AWS, vous ne payez que les services dont vous avez besoin, tant que vous continuez à les utiliser et ce, sans contrat à long terme. Vous ne payez que les services que vous utilisez, et si vous cessez de vous en servir, aucun coût additionnel ou frais de résiliation ne vous sera facturé.
Les services déployés dans le cadre de ce scénario n’ont pas vocation à être utilisé sauf dans le cas d’une intrusion donc d’un incident de sécurité. Les coûts associés sont donc négligeables.
Evaluation du leurre avec la matrice PARCS
Plusieurs critères permettent d’évaluer un leurre et voici les résultats de notre analyse au regard de la matrice PARCS :
- Pertinence : 4/4
« Diverses approches peuvent être adoptées pour efficacement repérer la compromission initiale d’une instance EC2 et la propagation latérale d’un attaquant Dans notre contexte, selon les ressources à notre disposition, une stratégie envisageable consiste à surveiller les opérations en analysant les journaux, ce qui permettra de détecter des actions malveillantes. Ces observations pourraient ensuite être utilisées pour générer des alertes destinées aux administrateurs. Par exemple, une alerte pourrait être déclenchée en cas de tentative d’intrusion via une attaque de force brute sur le service RDP des instances EC2 au sein de notre environnement AWS, grâce à GuardDuty.
De plus, il serait possible d’utiliser une combinaison de services AWS tels que CloudTrail et EventBridge pour établir des règles de détection et d’automatisation des interventions en réponse à des activités spécifiques, notamment celles liées aux accès entre comptes (cross-account) et créer des règles de détection qui surveillent tous les événements d’endossement afin de déclencher les actions en cas d’événements correspondant.»
- Attractivité : 4/4
« Le leurre se distingue par un compte dédié, augmentant ainsi de manière significative son pouvoir d’attraction. En ayant accès aux métadonnées de toutes les ressources à sa portée, l’attaquant peut également vérifier divers niveaux de privilèges ce qui renforce substantiellement la crédibilité. Grâce à la capacité de visualiser les dates et heures des dernières utilisations des ressources dans son champ de vision, il peut en déduire que ces ressources sont rarement utilisées. Dans cette optique, une fonction lambda est mise en œuvre pour automatiser l’exécution de différentes ressources ou leur authentification, garantissant ainsi des preuves d’utilisation récentes. »
- Risqué : 4/4
« L’autorisation accordée au rôle IAM-RO ne confère des privilèges IAM à l’attaquant que dans le contexte d’un compte purement fictif. Grâce à une configuration appropriée de la SCP en amont, toutes les tentatives d’actions du rôle Security-Audit seront également contrées. Les seuls éléments délibérément introduits dans un environnement réel sont les rôles Semi-Admin et Lambda-Auto, qui sont soumis à des politiques rigoureuses empêchant toute attribution de droits ou de privilèges en cas de tentative d’utilisation malveillante. Ces politiques incluent un accès en lecture seule (IAMReadOnlyAccess) et une restriction empêchant toute modification des autorisations liées au rôle du compte, tel que défini par la SCP. »
- Crédibilité : 3/4
« La crédibilité du leurre peut être remise en question en raison des ressources disponibles à sa disposition et des limitations potentielles, notamment une Inline Policy qui restreint les autorisations et les actions possibles. Il est important de prendre en compte ces éléments, car ils peuvent susciter des doutes chez les attaquants et compromettre l’efficacité du leurre. Il est donc crucial de mettre en place des mesures qui rendent le leurre aussi réaliste et convaincant que possible, en veillant à ce qu’il ait accès aux ressources et aux autorisations pertinentes pour créer un scénario crédible. »
- Scalabilité : 3/4
« En fonction de la taille d’une infrastructure, il devient envisageable de mettre en place un déploiement et une maintenance fluides des composants, grâce à l’emploi de scripts automatisés habilités à exécuter des opérations sur les ressources. Toutefois, il est essentiel de garantir une surveillance minutieuse de l’intégralité des ressources afin de consolider la sécurité face à d’éventuelles atteintes et d’assurer une réaction rapide pour défendre un périmètre étendu. »
En conclusion, la mise en œuvre d’un tel scénario de Deceptive Security dans le Cloud, offre une approche pour améliorer sa sécurité globale. Cela contribue à restreindre la capacité d’un attaquant à explorer et à se propager à travers le réseau en présentant des chemins trompeurs, en retardant leur progression et en permettant une détection et des réponses plus rapides. Les leurres, qui ressemblent à des cibles attrayantes, détournent l’attention et les ressources des attaquants des véritables actifs, ce qui accroît les chances de détection précoce.
De plus, les mécanismes d’alerte jouent un rôle crucial en fournissant des informations rapides sur les intrusions potentielles aux équipes de sécurité, ce qui permet une réponse rapide aux incidents et limite l’impact des attaques.
En combinant ces stratégies de défense, on renforce la posture de sécurité globale des environnements Cloud, on améliore leur résilience face aux cybermenaces en constante évolution et on garantit l’intégrité et la confidentialité des données sensibles.
En utilisant ces mesures de sécurité trompeuses, les entreprises peuvent renforcer leur défense contre les cyberattaques. Toutefois, il est important de noter que la Deceptive Security ne remplace pas les solutions de cybersécurité standard existantes et que la protection contre les cyberattaques nécessite l’utilisation de techniques de sécurité complémentaires pour une défense optimale.
ANNEXES – Services AWS
Les définitions suivantes sont issues de la source : AWS documentation → docs.aws.amazon.com.
SCP – Politiques de contrôle de services : Les politiques de contrôle de services sont un type de politique permettant de contrôler de manière centrale les autorisations. Cela permet de veiller à ce que les grandes directives soient respecter pour tous les comptes AWS de l’organisation.
EC2 – Elastic Compute Cloud : AWS EC2 permet de louer des serveurs (des instances EC2) pour répondre au mieux aux besoins de la charge de travail.
STS – Security Token Service : AWS STS permet de demander des informations d’identification de sécurité temporaires pour les ressources AWS. Cela permet d’attribuer un accès temporaire aux ressources via des appels API, la console AWS ou le CLI (Console Line Interface) AWS.
À noter : Chaque jeton STS possède un cycle de vie, défini lors de la création de celui-ci, pouvant aller entre 15 minutes et 36 heures.
CloudTrail : AWS CloudTrail est un service qui enregistre les actions effectuées par un utilisateur, un rôle ou un service AWS.
Fonction Lambda : La fonction Lambda est un service permettant d’exécuter du code.
SNS – Simple Notification Service : Amazon SNS est un service web permettant de gérer l’envoi de messages (SMS, e-mails, HTTP.S, etc.).
Merci à Charles BULABULA pour sa contribution à cet article.
