Forensic et remise en condition

MISC

HS n°

octobre 2022

Par

Tag(s)

cloud

détection

De plus en plus d’entreprises ont entamé une migration de leurs services dans le cloud, mais n’ont bien souvent pas pris en compte dès le départ le sujet du forensic et plus largement de la réponse à incidents. Bien que l’environnement soit différent du classique On-Prem, les enjeux restent les mêmes, être en mesure de détecter et d’investiguer le plus rapidement possible les ressources compromises.

Les équipes de réponses à incidents ont désormais des processus matures sur des environnements On-Prem, mais qu’en est-il des environnements cloud de type IaaS ou PaaS ? Cet article a pour objectif de présenter les bonnes pratiques pour être prêt à intervenir dans ce nouvel écosystème tout en tentant de rester agnostique du fournisseur cloud. En effet, il est courant qu’une entreprise déploie ses services chez plusieurs fournisseurs de services cloud, chacun avec leurs spécificités. Nous nous focaliserons dans cet article sur les trois fournisseurs majeurs, Amazon, Google et Microsoft, afin de donner des éléments tangibles au lecteur, éléments qu'il faudra adapter au contexte d'autres fournisseurs. Cet article n’a donc pas vocation à présenter sous un angle technique comment intervenir, mais plutôt une remise en condition afin d’anticiper le jour où surviendra un incident dans ces environnements. Des liens vers des ressources externes seront proposés aux lecteurs désireux d’approfondir le sujet d’un point de vue technique.

1. Préparation

À l’instar d’une réponse à incident On-Prem, il est primordial de bien se préparer pour aborder avec sérénité ces moments qui sont suffisamment stressants pour ne pas avoir en plus à gérer comment intervenir. Dans le cas d’une équipe interne ou d’un prestataire externe, différentes étapes préparatoires seront donc nécessaires.

1.1 Les parties prenantes

Tout comme probablement établi pour un SI On-Prem, il est préférable d’avoir défini avec les différentes parties prenantes des environnements cloud les personnes responsables des décisions, celles en charge de réaliser une action, mais aussi de définir quelles équipes doivent être embarquées, etc. (certains verront ici une matrice [RACI]). Cela permettra le jour J de savoir qui valide et qui peut réaliser une action de cloisonnement/isolation des ressources impactées. Il est également recommandé de préparer des fiches contacts qui identifient les personnes ayant les capacités d’intervenir, quels que soient le jour et l’heure. Un système d’astreinte autre que les équipes SoC/CERT est-il bien en place ? Les propriétaires des identifiants et du MFA du compte racine sont-ils identifiés ? D’ailleurs, le compte racine a-t-il bien un MFA activé ?

1.2 Gestion des accès

Comment aborder sereinement une investigation sans avoir anticipé en amont les accès permettant de mener à bien les analyses et remédiations ? La création et la gestion des accès est une étape cruciale à prendre en considération afin que les personnes habilitées puissent accéder aux ressources nécessaires.

Chaque organisation propose des moyens d’accès différents à ses environnements cloud. Certaines mettent en place un accès uniquement depuis le réseau On-Prem, d’autres autoriseront un accès depuis un ordinateur portable via un lien VPN dédié ou encore depuis un environnement de rebond dédié.

Cependant, il est également nécessaire de réfléchir aux moyens d'accès dans le cas du worst-case scenario. Comment gérer les accès cloud si le système d’information traditionnel fait également partie du périmètre de l’incident ? Existe-t-il un contournement possible pour accéder aux ressources cloud ? Quelles sont les capacités de création de nouveaux accès dans un mode dégradé ?

Ce n’est pas le jour où un incident surgit que doit s’effectuer la gestion des accès à l'organisation avec les permissions adéquates. Le minimum vital serait d’octroyer aux équipes sécurité l'accès aux logs et si possible un accès global reader qui permettra d’effectuer des opérations de lecture aux ressources impactées.

1.3 Connaissance de l’environnement

Tout comme maîtriser ses diagrammes d’architectures, matrices de flux, les comptes et règles de contrôle d'accès au SI traditionnel, il doit en être de même pour les environnements cloud. Un des avantages de déployer son infrastructure dans le cloud réside dans l’inventaire continu de toutes les ressources déployées. Par exemple, depuis le portail Azure il est possible de lister toutes les ressources associées à une région. Amazon propose même le service [Workload Discovery] qui permet de générer un diagramme sur la base de l'infrastructure déployée ainsi que Config qui détermine, contrôle et évalue les configurations des ressources AWS.

De la même manière, il est préférable que les équipes de réponse à incident aient une bonne compréhension du fonctionnement des mécanismes de gestion des accès (IAM pour Identity & Access Management dans le monde cloud) proposés par chaque fournisseur cloud utilisé. AWS propose par exemple le [Security Token Service] qui permet d’octroyer des privilèges temporaires pour un utilisateur IAM via l’appel à AssumeRole. GCP propose l’équivalent à travers l’emprunt de l'identité d'un compte de service via des identifiants de courte durée [short-lived credentials]. La bonne maîtrise de ces mécanismes rendra plus aisée l’interprétation d’un compte usurpé et utilisé pour du mouvement latéral. Il est à noter qu’AWS versionne les politiques IAM et peut permettre dans certains cas une élévation de privilèges en restaurant une version plus permissive.

Il en va de même concernant les services utilisés par les équipes métiers. En effet, l’approche des collectes et analyses ne sera pas la même si l’environnement repose principalement sur des machines virtuelles (AWS EC2, Azure VM, Google Compute Engine) ou s’il repose sur des orchestrateurs managés (Kubernetes via EKS, AKS, GKE). Ceci est encore plus flagrant sur des services de type PaaS tels que AppService ou Elastic Beanstalk. Anticiper les capacités d’analyses liées à ces services accélèrera d’autant plus la résolution de l’incident.

1.4 Entraînement

Bien que les environnements cloud existent maintenant depuis quelques années, les entraînements DFIR (Digital Forensics and Incident Response) cloud et outils dédiés aux analyses ou tests d’intrusion n’ont fait leur apparition que récemment. Une bonne manière de s’exercer pour un prix défiant toute concurrence repose sur les outils de simulations d’attaque basés sur des infrastructures vulnérables. En effet, un des avantages du cloud réside dans la capacité de déployer un environnement réplicable par tous grâce au paradigme de l'Infrastructure As Code (IaC). Il devient alors possible de dérouler des scénarios d’attaque et de tester ses capacités de détection et d'analyse.

De plus en plus d’outils de simulation reposent ainsi sur l’utilisation de Terraform pour déployer des infrastructures volontairement vulnérables. C’est le cas notamment de [cloudgoat] qui permet de déployer en une fraction de seconde dans AWS différents scénarios. L’un d’entre eux reproduit notamment la fuite de données de la banque [CapitalOne] en 2019, reposant sur l’exploitation d’une SSRF permettant la récupération de clés AWS d’un rôle IAM. Pour s’exercer aux investigations autour de Kubernetes, [kubernetes-goat] permet de déployer des clusters volontairement vulnérables. Enfin, un outil comme [Stratus Red Team] permet de reproduire de manière atomique des comportements malveillants à destination des fournisseurs AWS, Azure ou de clusters K8s. L’outil permet ainsi de tester ses capacités de journalisation, mais également d’aider à la création de règles de détection.

D’autres outils plus orientés pentest existent également comme [pacu] pour AWS, [Microburst] pour Azure ou encore [kdigger] pour Kubernetes. Il est vivement recommandé d’utiliser ces outils dans des environnements de test afin de déceler dans les logs les actions effectuées.

2. Détection et analyses

À l’instar d’un environnement On-Prem, détecter et analyser dans le cloud nécessite d’activer les bons journaux avec une rétention adéquate, mais aussi d'implémenter les bonnes pratiques et les bons outils pour les analyses. Il faut oublier d'emblée l’utilisation d’un Tableau TX1 pour une acquisition, tout comme un dd ou DFIROrc ne seront pas les plus adéquats selon la ressource compromise. Enfin, l’utilisation d’une machine d’analyse sous stéroïdes On-Prem avec des outils comme SIFT, plaso, Axiom, X-Ways ou Sleuthkit, ne seront pas les plus judicieux à utiliser dans le cas d’une réponse à incident dans le cloud. S’il est bien une recommandation à prendre en compte dès le début que ce soit en termes de journalisation ou d’analyse, c’est que ce qui se passe dans le cloud, reste dans le cloud ! En effet, les vendeurs de solutions cloud facturent chèrement la bande passante sortante, et tout rapatriement de données aura un coût fonction de la taille de l’infrastructure. Faire l’acquisition des block storages pour les rapatrier sur une machine d’analyse ne sera pas non plus une bonne pratique. Cette section détaille les possibilités offertes par les fournisseurs cloud en termes de journalisation ainsi que des recommandations pour les capacités d’analyse.

2.1 Journalisation et alertes

Les logs systèmes et réseaux représentent la première source permettant d’identifier et de définir la portée de l’incident (scoping). Qu’en est-il chez les fournisseurs de cloud ? La bonne nouvelle c’est que différentes sources de journalisation sont mises à disposition. Plus précisément, ils enregistrent par défaut les événements liés au control plane et proposent également d’activer le suivi des événements liés au data plane qui peut engendrer un surcoût.

Concrètement, quelle est la différence entre control plane et data plane ? Afin d’apporter une réponse, la journalisation liée à un service de type object storage (S3 chez AWS par exemple) sera pris comme exemple.

2.1.1 Control plane

Les journaux liés au control plane enregistrent les événements relatifs à la gestion d’un object storage. Cela comprend par exemple, les actions de création, de listing et de suppression du bucket ainsi que les ACL, les politiques, le cycle de vie ou le chiffrement associés à ce bucket.

Pour remettre dans le contexte d’un incident, si un attaquant a pour objectif de détruire les données, les évènements de type DeleteObject (pour AWS) seront enregistrés et fourniront un premier moyen de pivoter sur l'identité ayant effectué l’action.

2.1.2 Data Plane

Les journaux liés au data plane enregistrent toutes les interactions avec les données. Cela comprend, entre autres, les actions de création et suppression d’objets dans un bucket.

Toujours dans le contexte d’un incident, les actions d’un attaquant ayant pour objectif d’exfiltrer les données contenues dans un bucket seront enregistrées au niveau du data plane. Les événements de type GetObject (pour AWS) permettront de pivoter sur l’origine de l’action comme par exemple, l’instance utilisée pour l’exfiltration.

Chaque fournisseur de services cloud propose sa solution de monitoring. AWS fournit le service [CloudTrail] qui regroupe le control et le data plane (ce dernier devant être activé explicitement). Azure divise la supervision du control plane via [Activity log] et [Resource logs] pour le data plane et même Azure AD log pour toutes les activités liées à Azure AD. Google propose son service [Cloud Audit Logs] qui inclut les actions de control plane et data plane.

2.1.3 Machines virtuelles

Qu’en est-il des événements liés aux machines virtuelles ? Différentes possibilités sont offertes via l’utilisation d’un agent développé par le fournisseur cloud ou par le recours à des agents tiers. Azure propose par exemple l'intégration de Defender pour les conteneurs et les machines virtuelles. AWS et GCP proposent l'intégration d’antivirus ou EDR via leur marketplace. Enfin, d’autres éditeurs proposent des agents dédiés reposant sur eBPF tel que [Datadog] ou [AquaSec].

2.1.4 Orchestrateurs et conteneurs

De plus en plus d’entreprises ont adopté les services d’orchestration de conteneurs dans le cloud. Cependant, les fournisseurs cloud proposent une version gérée de ce type de service et une partie des infrastructures sous-jacentes n’est pas accessible à son utilisateur. Pour un orchestrateur managé reposant sur Kubernetes, il ne sera possible d’accéder qu’aux pods et à son ou ses conteneurs associés. Afin d’investiguer les composants control plane (API Server, etcd…) qui ne sont, de facto, pas accessibles, il est nécessaire d’analyser les journaux d’audit mis à disposition par les fournisseurs cloud. Enfin, à l’instar des machines virtuelles, il est souvent possible de déployer un agent pour tracer les événements des conteneurs. Encore une fois, chaque fournisseur aura une solution recommandée.

2.1.5 Réseau

Il est primordial de monitorer les différentes ressources de son environnement cloud, mais qu’en est-il de ce qu’il se passe sur le réseau ? Chaque fournisseur cloud propose sa solution de monitoring réseau via les journaux de flux réseau qui consistent à collecter les métadonnées du trafic à intervalle régulier. Cette fonctionnalité est donc l'équivalent du plus connu netflow. Selon le fournisseur, il sera possible d’appliquer les flow logs sur l’interface d’une machine virtuelle, pour un sous-réseau donné ou un réseau virtuel (VPC) entier. Bien que ce service soit attrayant, il est recommandé de les activer avec parcimonie et sur des ressources judicieuses afin d’en maîtriser les coûts. Il peut parfois même être préférable de les activer uniquement lors d’une réponse à incident pour la supervision de circonstance.

2.1.6 Cloud SIEM

Les bons journaux activés, quels sont les moyens mis à disposition pour agréger, corréler et alerter lorsqu’advient un événement malveillant ? Tout dépend du fournisseur cloud. Azure propose une solution SIEM via [Azure Sentinel] et GCP à travers [Chronicle]. AWS ne propose pas une solution SIEM clé en main, mais permet d'agréger et de requêter les différentes sources de logs avec le service [CloudWatch]. La détection de comportements malveillants et les alertes associées reposent sur [GuardDuty]. AWS recueille les alertes de tous ses services sécurité à travers [Security Hub].

2.2 Analyses

Un comportement malveillant a été détecté et les analyses doivent commencer, mais comment faire ? La section suivante revient sur certaines contraintes liées aux environnements cloud et recommandations pour un environnement d’analyse.

2.2.1 Contraintes

Il existe certaines contraintes inhérentes aux environnements cloud qui peuvent impacter les capacités d’analyse.

2.2.1.1 Régionalité

La localisation des ressources impactées doit être prise en considération. Si l’incident impacte une machine virtuelle située dans une région en Amérique du Nord et que l’environnement d’analyse est déployé en Europe centrale, l'accès au block storage ne sera pas directement possible. Il sera donc nécessaire d’effectuer une étape intermédiaire de création d'instantanés puis de restauration dans la région idoine. Idéalement, il est préférable de déployer ses outils d'analyse au plus proche des ressources impactées.

2.2.1.2 Chiffrement

Dans le cas de figure où les analyses nécessitent d’investiguer un block storage chiffré, les permissions d'accès aux clés de chiffrement seront nécessaires afin de pouvoir effectuer la copie d’un instantané. Il est donc recommandé d’ajouter dans sa checklist les bonnes permissions aux comptes d’analyse.

2.2.1.3 Volatilité

Le choix des services utilisés impacte la volatilité des données et par conséquent les capacités d’analyse. Les entreprises ont migré vers le cloud afin de rationaliser les coûts d’exploitation, mais également pour provisionner on-demand les ressources en fonction de la charge. En cas de forte demande, comme un jour de Black Friday, des instances vont être créées et détruites à la volée plusieurs fois. Un élément présent dans la chaîne d’attaque ne sera peut-être plus existant au moment des investigations et ne pourra donc plus être collecté. Enfin, un attaquant ayant les privilèges adéquats pourra sans difficulté effacer ses traces en détruisant les block storages d’une machine virtuelle ou les volumes associés aux conteneurs rendant la collecte caduque.

2.2.2 Environnement d’analyse

Afin de mener à bien une réponse à incident, il est préférable de déployer un environnement d’investigation qui contiendra les outils utiles aux analyses. Il est vivement recommandé d’utiliser les concepts d’Infrastructure as Code proposés par les différents fournisseurs cloud pour déployer un laboratoire d’analyse que ce soit avec [Amazon Cloud Formation], [Azure Resource Manager] ou [Google Deployment Manager]. Il est également possible d’opter pour une solution indépendante telle que [Terraform]. Certains [runbooks] existent déjà et seront utilisables facilement modulo quelques modifications. Certains CERT ont également développé des outils de déploiement d’environnement d’analyse reposant sur les API mises à disposition par les fournisseurs cloud. Afin d’isoler son environnement d’analyse, l’utilisation d’un VPC dédié (Virtual Private Cloud) avec les bons Security Groups associés est vivement conseillée. Dans la continuité des bonnes pratiques, il ne faudra pas oublier d’activer la journalisation pour cet environnement sensible.

En plus d’analyser les ressources impactées et en fonction du type d’incident, il est également possible de capturer le trafic réseau d’une machine virtuelle. AWS permet de capturer tout le trafic ou une partie via des filtres, de l’encapsuler dans un en-tête VXLAN puis de l’envoyer vers une destination choisie. GCP propose le même type de fonctionnalité. Azure propose [Network Watcher packet] capture qui enregistre le trafic d’une machine virtuelle au format cap qui pourra ensuite être injecté dans son dissecteur préféré. Pour une vue plus globale du trafic, au niveau d’un sous-réseau ou d’un VPC, l’activation des flow logs sera utile comme discuté dans la section journalisation. Enfin, pour améliorer les analyses, il est également possible d’enregistrer toutes les requêtes DNS effectuées.

Détailler quels outils utiliser et comment investiguer sort du scope de cet article et nécessiterait un hors-série à part entière. Bien que l’analyse d’une machine virtuelle revient peu ou prou à une investigation classique, l’analyse d’un orchestrateur tel que Kubernetes requiert une approche complètement différente. D’autant plus si l’analyste est confronté à un cluster managé ne permettant pas l'accès aux nœuds sous-jacents.

3. Isolation et remédiation

Différents mécanismes d’isolation peuvent être utilisés au cours d’une réponse à incident. L’approche la plus évidente consiste à bloquer les flux réseaux. Il sera ainsi possible d’appliquer des règles firewall à différents niveaux, directement sur l’interface d’une machine virtuelle, un sous-réseau donné ou un VPC de manière plus générale. Azure permet d’isoler une interface ou un sous-réseau grâce aux Network Security Groups. AWS propose l’utilisation de Security Group uniquement au niveau d’une instance et de Network ACL pour un sous-réseau ou un VPC.

Isoler une ressource est un bon début, mais quid d’un attaquant encore présent dans l’environnement ayant les privilèges pour supprimer l’isolation ou voulant détruire une ressource ? Là encore, certaines solutions permettent de restreindre la modification de ressources en basculant celles-ci en lecture seule ou en bloquant la suppression. Azure propose la solution la plus simple via sa fonctionnalité [Azure Locks]. Celle-ci permet par exemple de basculer en lecture seule les actions de gestion. Toutefois, les actions effectuées au niveau du data plane ne seront pas bloquées et il sera donc toujours possible d'accéder ou de modifier un fichier présent dans un blob storage. AWS ou GCP ne proposent pas d’équivalent et nécessitent d’attribuer une politique de lecture seule aux utilisateurs IAM compromis.

Une fois l’incident contenu et endigué, il est nécessaire de réviser sa posture en termes d’IAM et d’exposition des ressources. Il y a de fortes chances que l’environnement cloud repose sur un concept IaC permettant de déployer à nouveau les ressources impactées en ajoutant les mécanismes de sécurité nécessaires.

Conclusion

Comme présenté au cours de cet article, le DFIR dans le cloud nécessite une certaine adaptation des équipes de réponse à incidents tant sur la préparation que sur les aptitudes d’investigations et de remédiations dans ces environnements dynamiques. Les solutions pour les équipes Blue Team sont en pleine effervescence et les outils dédiés aux équipes offensives sont de plus en plus nombreux. Aborder de manière exhaustive tous les sujets liés à une investigation dans le cloud n’est pas chose aisée. Certains sujets comme une attaque de type supply-chain abusant des images de machine virtuelles (AMI) ou des registres de conteneurs (ECR) n’ont par exemple pas été abordés. Le nombre de services proposés par les fournisseurs évolue constamment et nécessite donc une veille permanente.