Abusing Entra OAuth for fun and access to internal Microsoft applications
23 comments
·August 9, 2025medhir
reactordev
Assume every token is forged. Secure by default. Even if it wastes cpu, validate each and every field. Signatures only work if verified. While you're at it, validate it against your identity database as well. Double check, triple check if you must. This is what I taught my devs.
Tenant, User, Group, Resource - validate it all before allowing it through.
Permik
Also knowing the difference between authentication and authorization is crucial and should not be forgotten.
muststopmyths
Move to the cloud they said. It will be more secure then your intranet they said. Only fools pay for their own Ops team they said.
I’m so old and dumb that I don’t even understand why an app for internal Microsoft use is even accesible from outside its network.
jameskilton
The last decade has seen an increase push in what Google started calling "Zero Trust"[0] and dropping VPNs entirely. The issue being that once someone got into a VPN it was much, much harder to prevent them from accessing important data.
So everything "internal" is now also external and required to have its own layer of permissions and the like, making it much harder for, e.g. the article, to use one exploit to access another service.
ronbenton
Does having a VPN/intranet preclude zero trust? It seems you could do both with the private network just being an added layer of security.
AWebOfBrown
It doesn't, but from my perspective the thinking behind zero trust is partly to stop treating networking as a layer of security. Which makes sense to me - the larger the network grows, the harder to know all its entry-points and the transitive reach of those.
nicce
I don’t see that really as an argument for this. You still should use VPN as an additional layer of security, assuming that you use some proper protocol. Then zero trust applies to internal network.
mdaniel
I am currently having this debate at $DAYJOB, having come from a zero trust implementation to one using fucking Cloudflare Warp. The cost to your "just use a VPN" approach or, if I'm understanding your point correctly, use VPN and zero trust(?!), is that VPNs were designed for on-premises software. In modern times, the number of cases where one needs to perform a fully authenticated, perfectly valid action, from a previously unknown network on previously unconfigured compute is bigger than in the "old days"
GitHub Actions are a prime example. Azure's network, their compute, but I can cryptographically prove it's my repo (and my commit) OIDC-ing into my AWS account. But configuring a Warp client on those machines is some damn nonsense
If you're going to say "self hosted runners exist," yes, so does self-hosted GitHub and yet people get out of the self-hosted game because it eats into other valuable time that could be spent on product features
gjsman-1000
Rule #1 of business, government, or education: Nobody, ever, ever, does what they “should.”
Even here: Hacker News “should” support 2 factor authentication, being an online forum literally owned by a VC firm with tons of cash, but they don’t.
glitchc
The zero trust architechture implies (read: requires) that authentication occurs at every layer. Token reuse constitutes a replay attack that mandatory authentication is supposed to thwart. Bypass it and the system's security profile reverts back to perimeter security, with the added disadvantage of that perimeter being outside your org's control.
ocdtrekkie
Zero trust is a good concept turned into a dumb practice. Basically people buying Google's koolaid for this forgot about "defense in depth". Yeah, authenticating every connection is great, throwing a big effing moat around it too is better.
The other thing is most companies are not Google. If you're a global company with hundreds of thousands of people who need internal access, moats may be non-ideal. For a business located in one place, local-only on-premise systems which block access to any country which they don't actively do business with is leaps and bounds better.
9cb14c1ec0
OAuth is frequently marketed as "more secure". But implementations often confuse authentication with authorization, resulting in problems like this.
koakuma-chan
I just say auth. You decide which one I mean.
therein
Did he really get no bounties out of this? The guy found a way into build boxes retail Windows is built on, potentially found the private key that would be used to generate license keys, likely could have dived in a little bit more after getting RCE on the build box to exfil the latest Windows 11 source code. He even found a way to issue rewards. They still gave him nothing?
gjsman-1000
Now remember these dimwits are bragging that 30% of their code is now written by AI; and have mandated Microsoft Accounts, set up OneDrive backup by default, and are providing infrastructure to OpenAI who is currently required to preserve even deleted chats. They also own LinkedIn.
This totally has no foreseeable potential consequences. It would be a real shame if some foreign hostile government with nuclear weapons managed to connect MS Account, LinkedIn Profile, and OpenAI accounts together by shared emails and phone numbers. Is it really worth starting a war for the crime of depantsing the nation?
jychang
To be fair, I’m pretty sure the code here was written before modern AI was a thing, back when dinosaurs roamed the earth.
deathanatos
Then this is the AI code the was trained on, and my confidence is still not increasing.
croes
And they don’t use AI to at least check older code?
mdaniel
As the adage goes: now you have two problems
gjsman-1000
Yes, but Microsoft hasn’t put together that AI making mistakes, is perfect plausible deniability for intentional “mistakes.”
inquirerGeneral
[dead]
ohhhh the gifts multi-tenant app authorization keeps giving!
(laid off) Microsoft PM here that worked on the patch described as a result of the research from Wiz.
One correction I’d like to suggest to the article: the guidance given is to check either the “iss” or “tid” claim when authorizing multi-tenant apps.
The actual recommended guidance we provided is slightly more involved. There is a chance that when only validating the tenant, any service principal could be granted authorized access.
You should always validate the subject in addition to validating the tenant for the token being authorized. One method for this would be to validate the token using a combined key (for example, tid+oid) or perform checks on both the tenant and subject before authorizing access. More info can be found here:
https://learn.microsoft.com/en-us/entra/identity-platform/cl...