Not surprising at all. The configuration and docs for Oauth2 on Entra is an absolute cluster-f. Evidently, it’s so confusing that not even Microsoft themselves can get it right.
Their solution to this will be to add even more documentation, as if anyone had the stomach to read through the spaghetti that exist today.
fock · 6m ago
Does this have a CVE or something? I have the weird feeling the cloud initiative here won't notice this ever otherwise...
medhir · 8h ago
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:
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 · 7h ago
Also knowing the difference between authentication and authorization is crucial and should not be forgotten.
Ignoring the ridiculous complexity of Entra and how easy it is to not realize you’re making a mistake with it (especially internal at Microsoft where there’s no delineation between all the internal tenants you need to support and 3P customer tenants), it’s really scary how people think an auth token is the only layer of security you need. These sites shouldn’t have ever been exposed to public internet (they’re not now). Network security is such an afterthought but it’s the best layer of defense you can have!
muststopmyths · 8h ago
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 · 8h ago
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.
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 · 8h ago
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.
tw04 · 3h ago
A VPN? Yes, by definition. Zero trust requires that every connection is authenticated and users are only granted access to the app they request. They never “connect to the network” - something brokers that connection to the app in question.
VPN puts a user on the network and allows a bad actor to move laterally through the network.
raesene9 · 1h ago
It doesn't have to. There's nothing to stop you using a VPN as an initial filter to reduce the number of people who have access to a network and then properly authenticating and authorizing all access to services after that.
In fact, I'd say is a good defence-in-depth approach, which comes at the cost of increased complexity.
nicce · 8h ago
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.
gjsman-1000 · 8h ago
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.
raesene9 · 1h ago
Should they? From a threat modeling perspective, what's the consequences for HN of a user having their password compromised? Are those consequences serious enough to warrant the expense and added complexity of adding MFA?
mdaniel · 6h ago
I'm firmly in the pro 2FA camp, but merely as a point of discussion: the Arc codebase is already so underwater with actual features that would benefit a forum, and if I changed my password to hunter2 right now the only thing that would happen is my account would shortly be banned when spammers start to hate-bomb or crypto-scam-bomb discussion threads. Dan would be busy, I would be sad, nothing else would happen
For accounts that actually mean something (Microsoft, Azure, banking, etc), yes, the more factors the better. For a lot of other apps, the extra security is occupying precious roadmap space[1]
1: I'm intentionally side-stepping the "but AI does everything autonomously" debate for the purpose of this discussion
ocdtrekkie · 5h ago
Everyone else: I need unique 128-character passwords for every site I ever visit with unphishable FIDO keys for MFA.
Me: I didn't give the store website permission to save my credit card. If someone logs in, they'll know I ordered pants there.
mdaniel · 6h ago
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
piperswe · 3h ago
In theory, for automated traffic like that you should probably be using a plain Access application with a service token rather than WARP
glitchc · 8h ago
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 · 6h ago
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.
motorest · 3h ago
> 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.
It seems that the fundamental issue surfaced in the blog post is that developers who work on authorizarion in resource servers are failing to check basic claims in tokens such as the issuer, the audience, and subject.
If your developers are behind this gross oversight, do you honestly expect an intranet to make a difference?
Listen, the underlying issue is not cloud vs self-hosted. The underlying issue is that security is hard and in general there is no feedback loop except security incidents. Placing your apps in a intranet, or VPN, does nothing to mitigate this issue.
raesene9 · 56m ago
But of course it does provide an additional layer of security that indeed could have reduced the likelihood of this issue being exploited.
For me, the core of the discovered issue was that applications intended purely for use by internal MS staff were discoverable and attackable by anyone on the Internet, and some of those applications had a mis-configuration that allowed them to be attacked.
If all those applications had been behind a decently configured VPN service which required MFA, any attacker who wanted to exploit them would first need access to that VPN, which is another hurdle to cross and would reduce the chance of exploitation.
With a target like MS (and indeed most targets of any value) you shouldn't rely solely on the security provided by a VPN, but it can provide another layer of defence.
For me the question should be, "is the additional security provided by the VPN layer justified against the costs of managing it, and potentially the additional attack surface introduced with the VPN".
tonyhart7 · 3h ago
"The underlying issue is that security is hard and in general there is no feedback loop except security incidents."
this is tbh, computer architecture is already hard enough and cyber security is like a whole different field especially if the system/program is complex
tomjen3 · 3h ago
That is probably still good advice for most companies. Joe's roof fixing business may be the best roof fixing business in 3 states, but would you want them to run their own server for their website, email, and booking?
Anyone who is on this forum is capable of building their own stuff, and running their own server, but that is not most people.
yyyk · 2h ago
It's all very simple: Entra* (Azure AD or however you'd call it) should not be used for AuthZ. Entra AuthN is okayish, but forget about Entra AuthZ, do it all yourself. It's all very simple to avoid once you do AuthZ.
* No idea why the rename happened. Does some manager in Microsoft have the plaque: "Renomino, ergo sum."?
moi2388 · 3h ago
That’s what you get. Entra ID doesn’t allow you to blacklist or whitelist specific tenants for multi tenant apps, which causes problems like this.
Add the fact that MSAL doesn’t work for stuff like browser extensions, so people have to implement their own security solutions to interact with Entra ID and it’s not surprising there are so many issues.
bobbyraduloff · 1h ago
$0 in rewards for RCE on the Windows build servers is crazy. I understand he didn’t find an actual zero-day, only a configuration issue, but still. Imagine the global havoc you can cause if you can pollute the build environment with backdoored DLLs…
9cb14c1ec0 · 7h ago
OAuth is frequently marketed as "more secure". But implementations often confuse authentication with authorization, resulting in problems like this.
koakuma-chan · 6h ago
I just say auth. You decide which one I mean.
tgv · 1h ago
I know it's a joke, but it's funny because it's (somewhat) true. To add to the confusion, sometimes one of them gets abbreviated "authn". That is so unhelpful.
janci · 3h ago
Ohh, that's probably why our integration suddenly stopped working for single-tenant app registrations right before release. We were using the /common endpoint for everyone. That is disallowed now.
gjsman-1000 · 9h ago
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?
indrora · 1h ago
Having done two rounds at different Fortune 10s (one being Microsoft) I can tell you: This isn't AI, this is the result of years of "make it work" and duct tape.
This is "It'll be safe if we leave it on the intranet" and then someone says "Zero trust!" and then all the sudden things that had authentication on the inside are also going through a new and different layer of authentication. A stack of totally reasonable expectations stack tolerance on tolerance, and just like the Sig Sauer P320, it has a habit of shooting you in the foot when you least expect it.
jychang · 8h ago
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 · 6h ago
Then this is the AI code the was trained on, and my confidence is still not increasing.
croes · 7h ago
And they don’t use AI to at least check older code?
mdaniel · 6h ago
As the adage goes: now you have two problems
gjsman-1000 · 8h ago
Yes, but Microsoft hasn’t put together that AI making mistakes, is perfect plausible deniability for intentional “mistakes.”
therein · 8h ago
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?
excalibur · 6h ago
If their rules say this doesn't deserve a bounty their bounty program is a sham.
addams · 5h ago
Microsoft's bug bounty program is a shell of its former self. They quietly disqualified a lot of high-impact findings in 2023.
In my own experience:
- Leaked service principal credentials granting access to their tenant? $0 bounty.
Have they already gotten so drunk on "zero trust" that they don't think it should matter if attackers see their source code? Then again, they are open-sourcing a ton of stuff these days...
refulgentis · 5h ago
I will forever remain radicalized how every tech company decided to just say fuck it in 2023. (ex-Google and left in 2023 over similar shenanigans)
Should be a major public reckoning over this. But there can't be, they hold the cards, the only real view of this you'd have is day-to-day on Blind and some occasional posts that stir honest discussion here.
I guess we just get to grin and bear it while they give gold statues and millions to the right politicians.
jmogly · 4h ago
It’ll come. Can’t say in what form, but the reckoning will come. Probably anti trust, or anti tech regulations as the public hatred of the tooligarchs grows. The problem with being out of touch is you can’t see the ground shifting beneath your feet.
croes · 2h ago
They need the money for AI data centers
raesene9 · 53m ago
My own , small, experience with MSRC is indeed their bug bounty program is not good, they take any possible opportunity to avoid payouts.
this means that a lot of genuine bug bounty hunters just won't look at MS stuff and MS avoid getting things fixed, instead other attackers will be the ones finding things, and they likely won't report it to MS...
Their solution to this will be to add even more documentation, as if anyone had the stomach to read through the spaghetti that exist today.
(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...
Tenant, User, Group, Resource - validate it all before allowing it through.
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.
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.
[0] https://cloud.google.com/learn/what-is-zero-trust
VPN puts a user on the network and allows a bad actor to move laterally through the network.
In fact, I'd say is a good defence-in-depth approach, which comes at the cost of increased complexity.
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.
For accounts that actually mean something (Microsoft, Azure, banking, etc), yes, the more factors the better. For a lot of other apps, the extra security is occupying precious roadmap space[1]
1: I'm intentionally side-stepping the "but AI does everything autonomously" debate for the purpose of this discussion
Me: I didn't give the store website permission to save my credit card. If someone logs in, they'll know I ordered pants there.
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
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.
It seems that the fundamental issue surfaced in the blog post is that developers who work on authorizarion in resource servers are failing to check basic claims in tokens such as the issuer, the audience, and subject.
If your developers are behind this gross oversight, do you honestly expect an intranet to make a difference?
Listen, the underlying issue is not cloud vs self-hosted. The underlying issue is that security is hard and in general there is no feedback loop except security incidents. Placing your apps in a intranet, or VPN, does nothing to mitigate this issue.
For me, the core of the discovered issue was that applications intended purely for use by internal MS staff were discoverable and attackable by anyone on the Internet, and some of those applications had a mis-configuration that allowed them to be attacked.
If all those applications had been behind a decently configured VPN service which required MFA, any attacker who wanted to exploit them would first need access to that VPN, which is another hurdle to cross and would reduce the chance of exploitation.
With a target like MS (and indeed most targets of any value) you shouldn't rely solely on the security provided by a VPN, but it can provide another layer of defence.
For me the question should be, "is the additional security provided by the VPN layer justified against the costs of managing it, and potentially the additional attack surface introduced with the VPN".
this is tbh, computer architecture is already hard enough and cyber security is like a whole different field especially if the system/program is complex
Anyone who is on this forum is capable of building their own stuff, and running their own server, but that is not most people.
* No idea why the rename happened. Does some manager in Microsoft have the plaque: "Renomino, ergo sum."?
Add the fact that MSAL doesn’t work for stuff like browser extensions, so people have to implement their own security solutions to interact with Entra ID and it’s not surprising there are so many issues.
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?
This is "It'll be safe if we leave it on the intranet" and then someone says "Zero trust!" and then all the sudden things that had authentication on the inside are also going through a new and different layer of authentication. A stack of totally reasonable expectations stack tolerance on tolerance, and just like the Sig Sauer P320, it has a habit of shooting you in the foot when you least expect it.
In my own experience:
- Leaked service principal credentials granting access to their tenant? $0 bounty.
- Leaked employee credentials granting access to generate privileged tokens? $0 bounty.
- Access to private source code? $0 bounty.
Etc.
Have they already gotten so drunk on "zero trust" that they don't think it should matter if attackers see their source code? Then again, they are open-sourcing a ton of stuff these days...
Should be a major public reckoning over this. But there can't be, they hold the cards, the only real view of this you'd have is day-to-day on Blind and some occasional posts that stir honest discussion here.
I guess we just get to grin and bear it while they give gold statues and millions to the right politicians.
this means that a lot of genuine bug bounty hunters just won't look at MS stuff and MS avoid getting things fixed, instead other attackers will be the ones finding things, and they likely won't report it to MS...