It's even worse: "Because of the nature of these Actor tokens, they are not subject to security policies like Conditional Access". This goes against all principles of good security design. A token that gives root access instead of specifying a particular action allowed just invites misuse, erroneous or malicious.
I would expect these tokens to be like JWT or macaroons, carrying specific permissions within specific bounds / tenants. Alas.
But the systems that have been built around them are bad. Firstly in issuing these ‘root’ tokens at all, and secondly in not checking the claims properly.
A JWT is only as good as the systems it’s used by.
This makes me wonder if Microsoft’s commitment to long-term support is part of the problem: instead of deprecating these ancient APIs they keep them on life-support, but forget some "regression-test" on how they interact with the shiny new surfaces.
Feels like P0’s Windows Registry talks, most of the vulns weren’t in the new code, they were in the how legacy behaviors interacted with newer features.
Microsoft also forced to keep these legacy code tbh
You see, most enterprise client with big enough contract can force to do this and MS need to support this customer until they migrate or if they ever be at all
I may argue for any big legacy enterprise software, its easier to rewrite the damn whole thing than to support the legacy code forever but they cant do that even if they have motivation/resource
AWS had switched from using something like this ("injection tokens") to just regular IAM roles, though managed by the AWS.
The only special permission that services (actually, the AWS accounts that they use) inside the AWS have is access to "service principals". The service roles inside customer accounts then use them to grant access.
AWS IAM is painful, but it shows that you can design a secure permission system.
I recently had to deal with Entra ID for the first time to setup Microsoft OAuth for our site and my god why is it so badly designed.
Just creating a tenant is a PITA and you get a default tenant you can't change without paying for Microsoft 365? Then you have subscriptions, Microsoft partners, Enteprise vs individual accounts, etc. All mixed with legacy AD naming and renaming, documentation with outdated screenshots, Microsoft Partners bullshit.
There ist a whole industry clustered around this FUBAR that makes its living by helping companies navigate this shit. It has small and big players and they have no incentive to tell you that there is anything else you could use. The monthly Service fee is too tasty.
Oh man, I was close with this a few times as I ran powershell in different ISE windows and sometimes copied/pasted things over for different tenants, darn - it really seemed so obvious of an exploit!
One wonders whether those who designed all this ever considered what that field in the token is for.
The word "tenant" is also very telling --- you're just renting, and the "landlord" always has the keys.
I would expect these tokens to be like JWT or macaroons, carrying specific permissions within specific bounds / tenants. Alas.
I'm feeling sorry for those poor abused JWTs in this vulnerability.
But the systems that have been built around them are bad. Firstly in issuing these ‘root’ tokens at all, and secondly in not checking the claims properly.
A JWT is only as good as the systems it’s used by.
This makes me wonder if Microsoft’s commitment to long-term support is part of the problem: instead of deprecating these ancient APIs they keep them on life-support, but forget some "regression-test" on how they interact with the shiny new surfaces.
Feels like P0’s Windows Registry talks, most of the vulns weren’t in the new code, they were in the how legacy behaviors interacted with newer features.
You see, most enterprise client with big enough contract can force to do this and MS need to support this customer until they migrate or if they ever be at all
I may argue for any big legacy enterprise software, its easier to rewrite the damn whole thing than to support the legacy code forever but they cant do that even if they have motivation/resource
Literally every single "security" framework uses God-mode long-lived tokens for non-human identities.
(Except for SPIFFE, but that's a niche thing and used only for Kubernetes bullshit.)
The whole field of "security" is a farce staffed by clowns.
The only special permission that services (actually, the AWS accounts that they use) inside the AWS have is access to "service principals". The service roles inside customer accounts then use them to grant access.
AWS IAM is painful, but it shows that you can design a secure permission system.
Just creating a tenant is a PITA and you get a default tenant you can't change without paying for Microsoft 365? Then you have subscriptions, Microsoft partners, Enteprise vs individual accounts, etc. All mixed with legacy AD naming and renaming, documentation with outdated screenshots, Microsoft Partners bullshit.