Un compte de test Microsoft piraté disposait de droits administrateur

• L’intrusion chez Microsoft est plus grave qu’un simple vol de compte, car un ancien compte de test sans MFA a permis d’accéder aux e-mails de hauts dirigeants ainsi que des équipes sécurité et juridique
• Le groupe lié à l’État russe Midnight Blizzard a exploité des identifiants faibles par password spraying pour se connecter à un « legacy non-production test tenant account »
• Les attaquants ont utilisé les autorisations d’une application OAuth dans le tenant de test compromis pour obtenir le rôle full_access_as_app dans Office 365 Exchange Online
• L’attribution de full_access_as_app nécessitant des droits administrateur, des critiques estiment que ce compte de test relevait d’une erreur de configuration lui accordant des privilèges excessifs dans l’environnement de production
• Un compte de test allant à l’encontre du principe du moindre privilège, combiné à du password spraying via des proxys résidentiels, complique la détection traditionnelle fondée sur les indicateurs de compromission

---

Du compte de test à l’accès aux e-mails

• Des hackers étatiques russes ont exploité des identifiants faibles par password spraying pour se connecter à un « legacy non-production test tenant account »
• Ce compte de test n’était pas protégé par une authentification multifacteur
• Ils ont ensuite obtenu des droits permettant d’accéder aux comptes e-mail de hauts dirigeants de Microsoft ainsi que d’employés des équipes sécurité et juridique
• Le groupe d’attaque Midnight Blizzard a abusé du protocole d’authentification OAuth pour conserver un accès persistant à des comptes e-mail privilégiés
  • Il a créé une application malveillante dans le tenant de test compromis
  • Il a accordé à cette application le droit d’accéder à toutes les adresses e-mail du service de messagerie Microsoft Office 365
  • Il a attribué à une application OAuth de test existante le rôle full_access_as_app d’Office 365 Exchange Online

Un ancien compte de test doté de droits administrateur

• La mise à jour de Microsoft indique qu’une « legacy test OAuth application » disposait d’un accès élevé dans l’environnement d’entreprise de Microsoft
• Selon Kevin Beaumont, pour attribuer le rôle full_access_as_app à une application OAuth, le compte doit disposer de droits administrateur
• Beaumont décrit cette configuration comme « une erreur de configuration assez importante en production »
• Des critiques jugent difficile d’imaginer une raison valable d’accorder et de conserver des droits aussi étendus sur un ancien compte de test legacy
• Microsoft a refusé d’expliquer pourquoi le compte de test avait été configuré ainsi au départ, et pourquoi cette configuration avait été maintenue après qu’il est devenu legacy

Une configuration contraire au principe du moindre privilège

• Cette configuration enfreint le principe du moindre privilège, selon lequel un compte ne devrait disposer que des droits minimaux nécessaires à l’exécution de ses tâches
• Le problème central est qu’il est difficile de comprendre pourquoi un compte de test legacy devait disposer de droits administrateur
• Beaumont compare la situation à la présence d’un utilisateur Domain Admin de systèmes de production dans un domaine de test dépourvu de sécurité, de MFA, de pare-feu et de supervision
  • Un utilisateur Domain Admin dispose de droits administrateur complets sur les appareils connectés au réseau, y compris les contrôleurs de domaine et Active Directory
  • Comme il s’agit du type de compte le plus puissant du réseau, il doit être isolé et ne devrait que rarement faire partie des systèmes de production
  • Si un tel compte reste sans surveillance, sans mot de passe robuste ni mesures de sécurité standard, les dommages peuvent être importants

Compromissions d’autres organisations et password spraying furtif

• Microsoft a détecté que Midnight Blizzard avait aussi compromis d’autres organisations, et en a informé les organisations touchées
• Hewlett-Packard Enterprises a également déclaré que son réseau avait été piraté par Midnight Blizzard
  • Cette intrusion a eu lieu en mai
  • Elle n’a été découverte et bloquée qu’en décembre
• Le password spraying utilisé pour accéder au compte de test a été mené sur un nombre limité de comptes, avec peu de tentatives par compte
• Les attaquants ont rendu leur activité malveillante moins visible grâce à une infrastructure distribuée de proxys résidentiels
  • Ils se connectaient depuis des adresses IP de bonne réputation
  • Ils utilisaient des adresses IP situées dans des zones géographiques attendues
  • Leur trafic semblait se fondre dans celui d’utilisateurs légitimes

Les limites de la détection traditionnelle par indicateurs de compromission

• L’utilisation de proxys résidentiels n’est pas une technique nouvelle et a également été observée lors de l’attaque de la chaîne d’approvisionnement SolarWinds en 2020
• L’attaque SolarWinds est elle aussi attribuée à Midnight Blizzard
• Les proxys résidentiels acheminent le trafic via un grand nombre d’adresses IP d’utilisateurs légitimes, ce qui rend la détection traditionnelle fondée sur les indicateurs de compromission difficile en pratique
• Midnight Blizzard est un groupe que les gouvernements américain et britannique disent opérer pour le compte du SVR, le service russe de renseignement extérieur
• Le même groupe est suivi sous d’autres noms, notamment APT29, the Dukes, Cloaked Ursa, UNC2452 et Dark Halo

[GN⁺]

Commentaires de Hacker News

• Ça rappelle un ancien piratage de Roblox dont j’avais entendu parler. Il y avait un site de staging non opérationnel où l’inscription utilisateur était possible, avec une bannière disant que « rien ici n’est permanent »
  Un nouveau compte administrateur avait été ajouté en production, puis quelqu’un s’est inscrit sur le site de staging avec le même nom d’utilisateur avant d’utiliser ce cookie et ce token pour détourner le compte de production et compromettre le site
  Si des tokens chiffrés sont générés à partir du nom d’utilisateur ou de l’ID utilisateur sans utiliser de secret distinct entre production et staging, ou si le site de staging communique avec des services externes au point de se mélanger avec l’attribution de privilèges en production, ce genre de problème ne doit probablement pas être si rare

  • J’avais autrefois implémenté une API d’expédition pour l’e-commerce, intégrée à DHL et autres. J’ai oublié de basculer vers le serveur de production, donc pendant plusieurs mois on a expédié avec des étiquettes générées par l’API de test, les colis sont bien partis, et rien n’a été facturé
    Dès qu’on s’en est aperçu, on l’a signalé honnêtement
  • C’est pour ça qu’il existe un champ d’audience dans les tokens

• Dans les grandes entreprises, la frontière entre développement et production est bien plus poreuse que les gens aiment l’imaginer
  Si on pense à une journée typique, on se connecte à son PC, on consulte ses e-mails, puis on se connecte au portail Azure avec les mêmes identifiants. Au final, tout est rattaché au même tenant, et le compte est aussi relié à GitHub et aux comptes cloud
  Des Groups et des Teams se créent un peu partout, et ce qui a été mis en place pour utiliser Teams ou OneDrive avec des permissions douteuses reste dans l’annuaire d’entreprise en étant à peine distinguable des groupes de sécurité
  De temps en temps, on reçoit un e-mail automatique du genre « est-ce encore nécessaire ? », mais le message est opaque, et dans une très grande entreprise il n’y a souvent personne à qui demander. Le helpdesk ne répond que deux jours plus tard, et on ne va pas non plus demander à John Savill sur Twitter, alors on clique simplement sur confirmer et on passe à autre chose
  Au final, le tissu de l’organisation commence à se déchirer, et l’attaquant entre avec un peu de chance par un point faible, puis se déplace latéralement dans le tenant pour prendre ce qu’il veut
  Comme l’a dit un CISO avisé, les hackers ne s’introduisent pas, ils se connectent

  • Il est intéressant de voir à quel point l’hypothèse de ce qui serait « typique » ici est audacieuse
    Comme si tout le monde utilisait forcément le cloud Microsoft, Skype, Twitter, OneDrive, etc., avec en plus un nom de personne glissé au passage pour faire vrai

• À propos de la remarque de Kevin Beaumont selon laquelle « seuls les comptes disposant de privilèges administrateur peuvent attribuer à une application OAuth le rôle full_access_as_app, presque équivalent à un accès total. Quelqu’un a commis une assez grosse erreur de configuration en production », même sans connaître les détails du système, ça ne semble pas être le vrai cœur du problème
  Il ne devrait même pas être possible de faire ce genre d’erreur. Les personnes qui ont conçu et exploité le système auraient dû rendre cela impossible, et c’est là que se situe la responsabilité
  Si vous construisez et exploitez une usine avec un bouton qui électrocute tout le personnel, et que quelqu’un appuie dessus par erreur, il est assez clair de voir où est le problème

  • Il est fort possible que ce ne soit pas un problème technique. Il y avait probablement une vingtaine de bonnes pratiques et de garde-fous techniques pour empêcher ça, mais ces garde-fous n’ont de sens que si l’organisation, le leadership et la bureaucratie s’en préoccupent
    Pendant des années, on m’a demandé à plusieurs reprises d’ignorer politiques, procédures, règles et lois pour donner des droits super admin/root à des VIP qui n’en avaient absolument pas besoin
    Aujourd’hui, tout empire encore plus parce que tout le monde cumule les fonctions, travaille à temps partiel, a deux rôles, trois rôles, etc.
    J’ai même vu un contrôle d’accès basé sur les rôles avec plus de rôles que de permissions réellement attribuables. À ce stade, le but même du RBAC s’effondre. Attribuer les droits individuellement aurait été plus rapide, mais ce n’était pas autorisé parce qu’alors les rôles n’apparaîtraient pas dans les rapports
    Ce genre de chose ne vient pas des équipes techniques, mais d’un mauvais leadership
    J’ai autrefois conçu une extension du système de permissions RBAC d’un ERP interne pour atténuer ce problème. On avait créé un type « exception de permission », afin que les personnes ayant besoin de droits en dehors de leur rôle puissent être affectées de cette manière, et qu’on puisse générer un rapport listant celles autorisées à effectuer des tâches hors de leur fonction
    Au final, ce n’était qu’un simple drapeau ajouté à la permission, mais ça marchait bien. Les RH examinaient chaque trimestre les exceptions de permission pour les supprimer, et au lieu qu’un helpdesk à temps partiel défasse les permissions au hasard par tâtonnements, le contrôle restait entre les mains de personnes compétentes
  • Je me demande comment on pourrait concrètement rendre une erreur de configuration impossible

• Il existe une montagne de certifications de sécurité très élégantes censées protéger les entreprises et les secteurs à partir de risques quantifiables, mais c’est assez comique de voir que des bonnes pratiques rationnelles et réfléchies, écrites dans un livre à 36 dollars sur Amazon, sont totalement ignorées
  On a l’impression que la sécurité est devenue une sorte de campagne avec des rubans

  • La sécurité est un processus, pas un produit
    Ceux qui vendent la sécurité comme un produit sont des charlatans
  • Même si moi j’ai des certifications sécurité, il est possible que 1 000 autres employés n’en aient aucune
    Les employés ordinaires ne s’intéressent pratiquement pas à la sécurité en tant que telle, ils font simplement leur travail
    Il y a trop de serveurs, d’applications et de configurations pour que les seuls employés sensibilisés à la sécurité puissent tout examiner
    Si on observe assez longtemps, dans n’importe quelle entreprise, quelque chose qui ne devrait pas être exposé finira un jour par l’être. C’est exactement le travail des groupes de hackers : continuer à chercher des failles
    Comme l’entreprise doit continuellement créer de nouveaux serveurs et de nouvelles configurations pendant son activité, ce n’est pas un problème qu’on règle une fois pour toutes
  • Je me demande de quel livre il s’agit

• Quand j’arrive dans un nouveau poste, je déteste quand quelqu’un me donne un tas de privilèges en disant « c’est plus simple comme ça ». Il ne faut pas faire ça
  Non seulement cela expose l’entreprise à une compromission, mais en plus cela me transfère une responsabilité dont je ne veux pas. Je pourrais casser quelque chose d’important par erreur, et si quelque chose se fait pirater, les gens pourraient me soupçonner simplement parce que j’avais ces privilèges

  • Quand on pense à la quantité de comptes et de permissions à gérer, sur plusieurs services, pour chaque employé, on peut aussi avoir l’impression que cette dérive est une évolution naturelle
    En pratique, on vit une sorte de pop-up de sécurité Windows XP au niveau des services. À chaque étape d’une tâche, on vous demande de vous authentifier auprès d’un autre système, et il peut falloir plusieurs jours avant d’obtenir les bons identifiants avec les bonnes permissions
    D’un point de vue humain, on peut comprendre que les équipes support finissent par abandonner et donnent d’un coup tous les comptes et toutes les permissions aux nouvelles recrues

• Ce qui manque dans cet article, c’est que si un compte non productif dispose de privilèges d’administrateur sur le domaine de production, tout dépend de la manière dont les auteurs définissent la « production »

  • À mon avis, c’est le point essentiel. L’article et les citations parlent d’« erreur », mais dans une organisation grande et complexe comme Microsoft, une mauvaise attribution des droits me paraît inévitable.
    Du coup, se focaliser sur l’angle « à un moment donné, quelqu’un a fait une erreur dans une entreprise de 220 000 personnes » n’aide pas beaucoup.
    En revanche, dans la plupart des entreprises, il existe normalement une séparation nette et solide entre les systèmes de production et les systèmes de test. Il devrait être pratiquement impossible d’accorder à un compte de test un accès à la production, donc l’enquête devrait surtout chercher à comprendre comment cela a pu arriver

• J’ai vu pire. Je travaillais dans un cabinet d’avocats où les administrateurs et les associés avaient un accès administrateur à absolument tout.
  Après réinitialisation du mot de passe, le mot de passe par défaut était « passme », parce que le mot de passe d’origine était trop long à retenir. Ils devaient le changer après s’être connectés au serveur.
  Un pirate a compromis certains de leurs comptes, a touché à diverses choses et a volé des données. Certains comptes de test avaient aussi des privilèges d’administrateur.
  Heureusement, je n’y travaille plus. J’étais programmeur-analyste et je n’avais que les droits administrateur sur mon propre PC pour faire tourner Visual BASIC 6.0

• Ce schéma ressemble davantage à la règle qu’à l’exception dans tout l’écosystème Microsoft, mais le fait que Microsoft lui-même ait procédé ainsi est particulièrement embarrassant.
  L’équipe sécurité de Microsoft a consacré des efforts considérables à des outils et à la documentation des bonnes pratiques destinés à éviter ce type d’incident majeur.

  • Je me demande comment le compte de test initial a été compromis. Il est possible qu’il n’y ait pas eu de MFA et qu’il y ait ensuite eu un mouvement latéral après un password spraying via le flux OAuth ROPC.
    L’obligation de MFA dans M365 est assez mauvaise. C’est un système payant.
  • Ce genre de chose arrive partout. Chez beaucoup de gens avec qui j’ai travaillé, la manière de tester consistait presque toujours à donner le maximum de privilèges. Je ne sais pas, ça ressemble à une sorte de débogage au fusil de chasse.
    Le problème plus grave, c’est que les gens oublient ensuite. On crée cinq comptes de test avec des privilèges administrateur, et personne ne s’en aperçoit jusqu’à ce que quelqu’un réalise un audit des droits utilisateurs à l’échelle de l’entreprise

• Une entreprise où j’ai travaillé autrefois stockait tous les mots de passe des serveurs et bases de données de production dans un fichier texte du dépôt de code. Le grand architecte ne voulait simplement pas avoir à mémoriser les mots de passe.
  Quand j’ai expliqué au CTO à quel point c’était stupide, il m’a répondu : « nous faisons confiance à nos employés » et « nous avons passé l’audit de sécurité ».
  Je ressens encore les effets du facepalm

  • Moi non plus, je n’aime pas les mots de passe de base de données. Ils se cassent bien trop vite.
    Ce n’est qu’une contrainte pénible, pas une fonction de sécurité. Je n’utilise pas un mot de passe du genre « c00lz500 » ; je mets carrément une chaîne vide, par exemple.
    À la place, j’utilise des pare-feu et un réseau interne