En se remémorant un ancien piratage de Roblox, un utilisateur raconte qu’il était possible de s’inscrire sur un site de staging non productif, avec une bannière disant « tout ici n’est pas permanent ». Lorsqu’un nouveau compte administrateur a été ajouté au compte de production, quelqu’un s’est inscrit sur le site de staging avec le même nom d’utilisateur, puis a utilisé les cookies et les jetons pour prendre le contrôle du compte de production et compromettre le site. Il n’est pas difficile d’imaginer que ce type de problème soit loin d’être rare : lorsqu’on génère des jetons chiffrés à partir d’un nom ou d’un identifiant utilisateur sans secret distinct entre production et staging, ou quand le site de staging communique avec des services externes qui confondent les permissions de production et de staging.
La frontière entre développement et production dans les grandes entreprises est bien plus poreuse que ce que les gens imaginent. 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 (le tout soutenu par le même tenant). Le compte est relié à GitHub et aux comptes cloud.
Pour permettre le travail dans Teams ou OneDrive, des groupes et des équipes aux permissions difficiles à comprendre sont créés un peu partout, et ils restent dans l’annuaire de l’entreprise sous forme de groupes de sécurité presque impossibles à distinguer.
On reçoit parfois des e-mails automatiques demandant si l’on utilise encore quelque chose dont on a besoin, mais les messages sont opaques, et dans une très grande entreprise il n’y a personne à qui poser la question (le help desk met deux jours à répondre, et on ne peut pas non plus contacter John Savill sur Twitter), donc on clique simplement sur confirmer et on continue.
Au final, la structure se fissure et un attaquant finit par avoir de la chance sur un point faible, ce qui lui permet d’obtenir ce qu’il veut à travers tout le tenant.
Comme l’a dit un jour un CISO avisé, les hackers n’entrent pas par effraction, ils se contentent de se connecter.
Dans l’industrie de la cybersécurité, on appelle couramment cela un « whoopsie ».
Le chercheur et expert en sécurité Kevin Beaumont a souligné sur Mastodon qu’un compte capable d’attribuer le rôle full_access_as_app à une application OAuth devrait avoir des privilèges d’administrateur. Selon lui, « quelqu’un » a commis une erreur de configuration assez majeure en production.
Je ne connais pas les détails du système, mais je doute que ce soit là le vrai problème, et je suis surpris qu’un expert affirme que c’en est un. Il ne devrait pas être possible de faire une telle erreur. Les concepteurs et les administrateurs devraient rendre cela impossible, et ils devraient en être tenus responsables.
Malgré de belles certifications de sécurité, on a l’impression que des bonnes pratiques pourtant bien pensées, comme celles d’un livre à 36 $ sur Amazon, sont complètement ignorées.
Ce qui manque dans ce billet : la manière dont les auteurs définissent la « production », et comment un compte « non productif » peut disposer de droits d’administration sur le domaine de production.
Ce schéma est la règle plutôt que l’exception dans tout l’écosystème MS, mais le fait que Microsoft lui-même fonctionne ainsi est particulièrement embarrassant.
Dans une entreprise, les mots de passe de tous les serveurs et bases de données de production étaient stockés dans un fichier texte du dépôt de code, parce que l’architecte en chef ne voulait pas avoir à les mémoriser. Quand on a signalé au CTO à quel point c’était idiot, on a reçu comme réponses : « Nous faisons confiance à nos employés » et « Nous avons passé l’audit de sécurité ».
Quand j’arrive dans un nouveau poste, je déteste voir quelqu’un attribuer de nombreux privilèges « parce que c’est plus simple ». Il ne faut pas faire ça. Non seulement cela expose l’entreprise, mais cela vous fait aussi porter une responsabilité dont vous ne voulez pas. Vous pouvez casser quelque chose d’important par accident, et si vous vous faites pirater, on pourrait vous soupçonner puisque vous aviez les permissions.
Pourquoi cela est-il considéré comme une « erreur » ? Il pourrait tout aussi bien s’agir de l’acte d’un espion travaillant comme administrateur chez Microsoft.
1 commentaires
Réactions sur Hacker News
full_access_as_appà une application OAuth devrait avoir des privilèges d’administrateur. Selon lui, « quelqu’un » a commis une erreur de configuration assez majeure en production.