Chez Microsoft, il y a des traditions. Comme ne pas documenter les comportements critiques de leurs services cloud, ou encore créer des rôles “integrated” tellement permissifs qu’on dirait des backdoors officielles. Et grâce à l’équipe de Token Security, on découvre aujourd’hui le grand gagnant du loto de la cybersécurité : Azure’s Role Roulette™. Félicitations, vos droits « en lecture seule » permettent désormais de vous faire dépouiller comme un serveur Exchange en 2010.
🧩 Chapitre 1 – Le rôle “Reader” : pour lire, oui, mais surtout vos secrets réseau
Prenons un rôle banal : Reader. En théorie, ce rôle est censé permettre la consultation des ressources Azure. Oui mais voilà : dans Azure, lecture = voir les secrets, les configurations sensibles, les clés de chiffrement, et les PSK VPN. Et pas qu’un peu.
Token Security a décortiqué plusieurs rôles “built-in” (comprendre : ceux que tout le monde utilise car « officiels ») et découvert que certains permettaient de récupérer les clés VPN partagées (PSK). Oui, vous avez bien lu. Le rôle Reader, celui que vous assignez aux stagiaires pour faire joli, donne accès à des secrets réseau utilisables pour pivoter vers vos infra internes.
🔓 Chapitre 2 – Une vulnérabilité API en prime ? Mais bien sûr !
Parce que Microsoft ne fait jamais les choses à moitié, une faille dans l’API Azure permettait — jusqu’à récemment — de récupérer la PSK VPN via un simple appel API. Pas besoin de flag CTF ou d’exploitation obscure : un appel bien placé, et hop, vous voilà avec les clés du château.
Microsoft a discrètement corrigé la faille en la classant « Important » (ça change de « Critical », vous voyez, c’est plus chill). Cerise sur le gâteau : la récompense bug bounty a été de 7 500 $. Ce qui, avouons-le, est probablement le prix d’une demi-heure de consulting Azure sur leur Marketplace.
🧨 Chapitre 3 – Quand deux failles font une compromission
Là où c’est beau, c’est que la combinaison des deux faiblesses (rôles trop larges + API mal protégée) permettait à un utilisateur lambda de :
- Lister les connexions VPN et leurs configurations ;
- Appeler l’API pour exfiltrer la clé PSK ;
- Se connecter au VPN d’entreprise ;
- Et entrer dans le réseau interne comme un touriste en sandales au Louvre.
Bref, une prise de contrôle d’environnement d’entreprise, offerte par un « reader », sans élévation de privilèges. Vous vouliez du Zero Trust ? Vous aurez du Zero Clue.
📚 Chapitre 4 – La réponse Microsoft : documenter, surtout ne rien corriger
Face à cette pépite, Microsoft a choisi la réponse la plus passive-agressive de l’histoire du cloud :
“Nous avons mis à jour la documentation pour alerter les utilisateurs sur les risques de sur-permission des rôles intégrés.”
En d’autres termes : « Débrouillez-vous. On vous avait rien promis. »
Pas de changement dans les rôles. Pas d’audit automatique. Pas même une alerte dans le Security Center. Juste un petit paragraphe discret dans la doc.
🔍 Chapitre 5 – Le chaos hérité d’Active Directory
L’écosystème Azure AD, c’est comme un fichier Excel qu’on trimballe depuis 20 ans : plein de macros, de noms bizarres et d’héritages mal compris. Chaque service Azure est conçu par une équipe différente, chaque rôle donne plus que prévu, et la doc semble avoir été écrite par des IA fatiguées.
Sur Reddit et HackerNews, les experts ne mâchent pas leurs mots :
“Un rôle Reader qui lit les secrets VPN, sérieusement ?!”
“700 Mo de scripts Python pour az cli ? Microsoft, arrêtez de fumer vos pipelines CI.”
✅ Chapitre 6 – Que faire ? (à part pleurer dans un coin)
Vous utilisez Azure ? Voici vos nouvelles obligations de survie :
- Évitez les rôles intégrés, sauf si vous aimez le danger.
- Créez vos propres rôles personnalisés (custom roles) avec le strict minimum de permissions.
- Scoppez vos accès au niveau le plus bas possible : groupe de ressources, ressource unique.
- Logguez toutes les actions sur les secrets, surtout dans les services réseau.
- Audit complet des affectations de rôles dès que possible.
Ah, et bien sûr, changez immédiatement vos clés VPN si vous avez utilisé ces rôles. Au cas où quelqu’un d’autre ait déjà visité vos locaux virtuels.
🧨 Épilogue – Microsoft, l’art de l’auto-sabotage version cloud
La sécurité sur Azure, c’est comme un jeu de société dont les règles changent toutes les semaines, mais où le seul pion, c’est vous. La vérité, c’est que les rôles intégrés sont une dette technique active, une sorte de malware officiel déguisé en fonctionnalité.
On ne vous le répétera jamais assez : faites le ménage vous-mêmes, car Microsoft ne le fera pas pour vous.
🧠 Vous aimez ce genre d’article ? Partagez-le à vos admins Azure, ou mieux, à votre DSI. C’est le moment de parler de rôles personnalisés — avant que ce ne soit un attaquant qui le fasse pour vous.
