Le site cloud a bouleversé le contexte sur lequel les défenseurs ont l'habitude de s'appuyer pour comprendre la surface d'attaque. Les attaquants ne se déplacent plus le long d'un plan de réseau linéaire, d'un bien à un autre, où la visibilité peut être tracée à une couche prévisible de la pile du réseau. Sur le site cloud, chaque mouvement d'un attaquant doit être compris en relation avec l'infrastructure cloud sur laquelle il opère.
Dans ce billet, je souhaite clarifier les approches uniques nécessaires pour défendre les systèmes cloud en discutant de l'architecture qui sous-tend le site cloud, du modèle de menace qui en découle et, enfin, de la manière dont les attaquants abusent de ces systèmes.
Tout d'abord, un bref examen de l'architecture classique sur site et des points d'inflexion que les attaquants cherchent à exploiter. L'architecture de votre fournisseur de services cloud (CSP) vient se juxtaposer à une pile technologique traditionnelle. Je vous présenterai les bases de l'architecture cloud , le nouveau modèle de menace qui émerge et, par conséquent, les mesures prises par les attaquants pour infiltrer les ressources déployées sur cloud . cloud Pour conclure, une fois que nous aurons bien compris pourquoi cloud est différent, je vous présenterai une façon originale dont les attaquants abusent de l'environnement, ainsi que la façon dont les défenseurs doivent envisager la visibilité dans cloud.
Modèle de menace de la pile technologique traditionnelle
Il peut être utile de donner un bref aperçu de l'architecture des centres de données même si la plupart des lecteurs sont bien familiarisés avec un ensemble de technologies traditionnelles. Passer du temps à aborder le modèle de menace des architectures de centres de données facilite le juxta-positionnement que nous ferons plus tard par rapport à un modèle de menace cloud , mais permet également de nous rappeler les hypothèses intégrées que nous avons sur la façon de protéger les systèmes.
Examen des vecteurs de compromis initial.
- Les architectures classiques peuvent être truffées de ports de gestion exposés qui permettent aux pirates d'accéder directement à un serveur.
- Nous devons également modéliser les risques associés aux vulnérabilités de la couche application et la manière dont elles peuvent être exploitées pour accéder à la couche système d'exploitation.
- Parmi les autres points courants de compromission initiale d'un système classique, on peut citer les attaques de phishing, toujours d'actualité, les implants envoyés par courrier électronique et l'exploitation des vulnérabilités de la couche hôte.
Chacun de ces vecteurs peut être exploité par un attaquant, soit pour prendre pied dans un environnement, soit pour progresser dans un système à la poursuite d'un objectif - souvent la confidentialité des données.
Les techniques des attaquants sont dictées par les caractéristiques de la pile technologique.
Cela peut sembler une observation évidente, à savoir que les attaquants vivent de la terre et adaptent leurs méthodologies à la pile technologique avec laquelle ils se trouvent engagés. Malgré sa simplicité, cette vérité universelle permet d'expliquer la divergence des techniques utilisées lorsque les acteurs de la menace ciblent les systèmes sur site par rapport à l'infrastructure cloud .
Les systèmes sur site avec lesquels les adversaires s'engagent sont probablement installés avec des systèmes d'exploitation pleinement fonctionnels. Cette surface d'attaque peut être exploitée pour passer d'un poste de travail compromis à un serveur routable dans le centre de données de la victime.
Les serveurs ne fonctionnent pas en mode "air-gapped", ils sont reliés les uns aux autres par un réseau. C'est par l'intermédiaire de ce réseau que les attaquants peuvent se déplacer d'un hôte à l'autre.
On trouve souvent des règles de sortie permissives dans l'architecture traditionnelle des centres de données. C'est sur ce chemin de réseau sortant que les attaquants cherchent à établir une persistance par le biais de tunnels de commande et de contrôle et à exfiltrer des données hors d'un périmètre de réseau fiable.
Si vous remarquez, la progression de l'attaque sur site décrite dans le diagramme ci-dessus est déterminée par la surface dont dispose l'attaquant. Dans la section suivante, lorsque nous aborderons l'architecture cloud , vous remarquerez que les mêmes règles du jeu demeurent : la pile technologique informe les tactiques et les techniques employées par les attaquants pour atteindre leurs objectifs.
Cloud L'architecture et le nouveau modèle de menace
Le site cloud repose sur le concept d'infrastructure partagée, où les clients se voient accorder un accès granulaire à certaines couches de la pile d'infrastructure pour créer et maintenir des ressources. Un client de cloud dispose d'une autonomie totale pour créer des ressources IaaS, utiliser des services PaaS, transférer des données et créer une politique IAM (Identity and Access Management) pour régir l'accès - tout cela grâce à l'autorisation qu'il a déléguée à une petite partie de l'infrastructure gérée par les fournisseurs de services de cloud .
L'accès aux fonctionnalités est délégué et exposé au client par l'intermédiaire d'une couche d'API généralement appelée Cloud Control-Plane APIs.
Toutes les interactions de l'utilisateur final avec un environnement cloud passent par le plan de contrôle Cloud grâce à des milliers d'API accessibles au public. Les API du plan de contrôle permettent aux clients d'effectuer des tâches administratives telles que la création de nouveaux environnements, le provisionnement des utilisateurs, la maintenance des ressources et l'accès aux données stockées sur les services PaaS gérés.
La responsabilité de l'API du plan de contrôle est la suivante :
- Autoriser les appelants, s'assurer qu'ils ont les permissions nécessaires pour effectuer les actions demandées.
- Reproduire l'action dans le composant en aval. Une action peut consister à mettre sous tension une machine virtuelle, à copier un objet d'un bac à un autre ou à mettre à jour les autorisations d'un utilisateur.
Le site cloud est puissant !
En exposant toutes les fonctionnalités via un ensemble d'API publiques bien connues, les entreprises peuvent bénéficier d'une rapidité et d'une évolutivité inégalées. Construire sur cloud , c'est comme verser de l'essence sur vos cycles de développement et c'est pourquoi la grande migration vers cloud dans tous les secteurs est en cours malgré le coût souvent élevé de la migration et les coûts continus de l'infrastructure cloud .
Compte tenu de ce nouveau paradigme, comment devrions-nous modéliser les menaces qui pèsent sur les données stockées sur le site cloud?
Je pense qu'il est utile de se concentrer sur le compromis initial, car c'est un excellent moyen de mettre en évidence les similitudes et les différences entre les modèles de menaces on-prem et cloud .
Quelques vecteurs de compromis initial dans le site cloud devraient vous sembler familiers.
- La compromission initiale sur le site cloud peut être due à des ports de gestion ouverts sur des ressources IaaS. Nous savons tous qu'un port SSH ou RDP ouvert attire une attention indésirable. Dans le site cloud, ces risques subsistent.
- Par ailleurs, les vulnérabilités de la couche applicative restent tout à fait pertinentes. Un code non sécurisé déployé sur des applications web accessibles au public peut, au minimum, perturber les activités de l'entreprise et, au pire, donner aux attaquants un point d'ancrage dans votre zone démilitarisée (DMZ).
Toute expérience acquise sur place en matière de prévention et de détection des compromissions initiales via ces deux vecteurs vous sera utile dans l'environnement cloud. Les règles de prévention et de détection peuvent prendre une tournure légèrement cloud-native mais sont fondamentalement les mêmes dans un environnement cloud .
Mais qu'en est-il des API du plan de contrôle? Il s'agit de points d'extrémité publics où l'autorisation est configurable par le client. Cette surface d'attaque est totalement nouvelle, et c'est là que l'attaquant avisé profitera des commodités du site cloud pour atteindre ses objectifs.
Examinons ce que pourrait être la progression d'une attaque lorsqu'un attaquant exploite les API du plan de contrôle par opposition à une surface d'attaque sur site (voir le diagramme) :
- La compromission initiale par hameçonnage est une tactique populaire des adversaires car elle fonctionne souvent.
- L'impact des informations d'identification récoltées peut se déplacer vers le site cloud lorsque les informations d'identification sont utilisées pour authentifier et autoriser des activités dans des environnements cloud .
- Il est peu probable que les informations d'identification associées à la compromission initiale fournissent un chemin direct à l'adversaire. Par conséquent, l'une des nombreuses techniques éprouvées d'escalade des privilèges sur le site cloud peut être utilisée pour obtenir des autorisations supplémentaires.
- Les campagnes cherchent souvent à établir une certaine forme de persistance. Sur le plan de contrôle cloud , cette persistance sera très différente de celle que l'on trouve dans les locaux de l'entreprise. Sur le site cloud , la persistance ressemble souvent à un rétablissement de l'accès au compte par la manipulation de la politique IAM.
- En suivant la progression de l'attaque, nous sommes arrivés à un point où l'accès à la cible a été obtenu. Dans le site cloud , il s'agit simplement d'obtenir les autorisations IAM appropriées pour accéder aux données hébergées sur cloud .
- Enfin, dans ce scénario, les actions sur les objectifs consistent à exfiltrer des données hors de l'environnement. Là encore, les API du plan de contrôle cloud sont utilisées pour transférer des données de l'environnement de la victime vers un environnement contrôlé par l'attaquant.
L'ensemble de la séquence d'attaque, depuis la compromission initiale jusqu'à l'impact, a été orchestré par le biais des API accessibles au public du fournisseur de services cloud . À aucun moment la couche réseau ou la couche hôte n'est entrée en jeu. Aucun contrôle préventif ou capteur sur un réseau n'était possible.
Cloud-Exfiltration de données natives
L'une des principales caractéristiques de tout FSC est son réseau dorsal. Qu'est-ce qu'un réseau dorsal ?
- Il s'agit de la couche de service du fournisseur de services cloud - utilisée pour les tâches opérationnelles d'arrière-plan du CSP, le réseau d'arrière-plan utilisé pour communiquer avec l'infrastructure multi-locataire et maintenir la disponibilité.
- L'épine dorsale fait également référence au réseau utilisé par le FSC pour transférer les données des clients, par opposition au transport d'octets sur le web ouvert.
Ce réseau dorsal permet à de nombreux services gérés, tels que les référentiels de stockage cloud , d'être automatiquement routés vers tous les autres référentiels de stockage du CSP.
D'un point de vue tactique, si vous souhaitez déplacer des données d'un godet S3 vers un autre godet S3, il vous suffit d'obtenir les autorisations IAM nécessaires. Le chemin du réseau est déjà tracé sur le réseau de base des CSP (Cloud Service Provider).
En tant que consommateur de cloud , il n'est pas possible de mettre en œuvre des restrictions de réseau autour des données qui se trouvent dans cloud-native storage1, et vous n'avez pas de visibilité sur le réseau sur lequel elles circulent.
Par exemple, il n'est pas possible d'ingérer des journaux de couche réseau pour capturer le trafic entre deux buckets S3.
Cela constitue un ensemble de circonstances attrayantes pour un attaquant désireux d'exfiltrer des données d'un environnement cloud .
S'ils obtiennent les autorisations IAM appropriées, les données peuvent être déplacées du bac d'une victime vers un bac d'un compte contrôlé par l'attaquant en soumettant des demandes API de niveau 7 au plan de contrôle cloud .
Pour ce faire, un attaquant interagit uniquement avec les API du plan de contrôle cloud accessibles au public et exploite le réseau dorsal du CSP, une route réseau préconfigurée, non accessible au client.
Visibilité sur le plan de contrôle
Les données déplacées d'un bac à l'autre ne laissent pas le genre de traces auxquelles la plupart des défenseurs sont habitués.
- Les journaux de la couche réseau, qui peuvent révéler les paquets de données se déplaçant d'un seau à l'autre - vous n'y avez pas accès en tant que consommateur du site cloud .
- Le mouvement des données s'effectue sur le réseau de base pour lequel les clients de cloud n'ont aucune visibilité.
- Qu'en est-il de la visibilité de la couche hôte ?
- Cloud-Le stockage natif comme les buckets S3, les blobs de stockage Azure et autres sont tous des services gérés. Le client n'a pas accès au niveau de l'hôte ou du système d'exploitation, comme c'est le cas avec le modèle d'infrastructure en tant que service. Aucun agent ne peut être déployé sur les services gérés.
Il nous reste donc le plan de contrôle. Aucune des actions entreprises par un attaquant ne pourrait être identifiée par les capteurs traditionnels, mais les indicateurs de l'activité apparaissent dans les journaux rédigés par le plan de contrôle cloud .
Toutes les actions sur les ressources et les données hébergées par cloud sont autorisées par les API de proxy du plan de contrôle cloud et donnent lieu à une forme d'enregistrement.
- Les actions de vos développeurs lorsqu'ils créent leurs buckets sont enregistrées, l'ingestion et la lecture normales des données sont enregistrées et donnent lieu à des événements correspondants.
- À l'inverse, lorsque les malfaiteurs exploitent les API du plan de contrôle cloud , leurs actions sont enregistrées comme un seul et même événement.
Ces enregistrements d'événements racontent l'histoire de votre environnement cloud , qui a accédé à quoi, à partir d'où et avec quelles informations d'identification, mais pas les intentions de l'utilisateur. Pour déterminer si une action particulière est malveillante ou bénigne, il faut des indices contextuels supplémentaires et souvent une vision plus large de l'environnement.
Dernières conclusions
Quelques enseignements à tirer
- Les adversaires tireront parti de l'architecture unique de cloud et des services natifs de cloud pour les mêmes raisons que celles qui poussent les développeurs à utiliser cloud : c'est rapide ! Il est évolutif ! Et les API du plan de contrôle cloud les aident à atteindre leurs objectifs.
- Le plan de contrôle est l'endroit où nous pouvons trouver des preuves d'activité, malveillante ou non, dans un environnement cloud . La surveillance basée sur le réseau et sur l'hôte ne vous fournira pas la visibilité dont vous avez besoin.
[1] Contrôles des services VPC (Virtual Private Cloud) : Seul Google Cloud offre une fonctionnalité permettant d'appliquer des périmètres autour des services gérés, non liés aux VPC https://cloud.google.com/vpc-service-controls#section-6