AAD misconfiguration led to Bing.com results manipulation, account takeover
wiz.io
wiz.io
> Microsoft has addressed an authorization misconfiguration for multi-tenant applications that use Azure AD, initially discovered by Wiz, and reported to Microsoft, that impacted a small number of our internal applications.
Sure, a small number of internal applications. Just the ones that gave them arbitrary JavaScript execution on every visitor to bing.com and full access to every signed in user's emails and cloud office documents.
https://msrc.microsoft.com/blog/2023/03/guidance-on-potentia...
Put another way: just because the researchers didn't (publicly) complain doesn't put MSFT in the right here. There are more than a few kernel developers who didn't raise hell about Linus' abusive behavior. Yet even Linus himself realized his behavior had to change.
In either case only paying $40,000 for disclosing an exploit like this sends a clear message from Microsoft. They don't take their user's security seriously. And it also incentivizes certain outcomes -- They're cheap and less moral actors who are only motivated by the finanical reward won't bother to engage with Microsoft.
Use Microsoft products at your own peril.
And yet, it still seems out of line with the scope of the vulnerability.
"seems" implies a subjective measurement.
> If the researchers weren't ok with that bounty, they shouldn't (and wouldn't!)
Researchers are going to research. Please don't carry water for trillion dollar companies; the reward was paltry don't blame the researchers for Microsoft's cheapness.
It is only uninformed HN posters imagining that vulnerabilities are worth millions of dollars on some imaginary black market that are complaining about it. Just like they do with every vulnerability disclosure that mentions the size of the bounty.
And by repeating this low-value conversation for the hundredth tube, you (yes, the specific you) are just hijacking the conversation and taking attention from what is unique and interesting about this case into your fantasy grievances about the bounty being too small.
Well, good morning to you as well.
Anyway, the conversation had turned to the topic of remuneration. You didn't reply with THIS comment originally, you joined right in and defended Microsoft's payment terms. If you thought this thread of conversation was "taking attention away" why did you wallow into the mud with the rest of us?
It's neither imaginary nor black. They list their prices on their website: https://zerodium.com/program.html
Sure normally it is a joke but this one in particular does look like something that would actually be worth something to the right buyer
These researchers would get more from re-selling the exploit from dark web criminals than this bug bounty program.
It's impossible to know if anybody else has been abusing this for some time or not, and it's a valid concern for people here to argue the bounty is low enough that this kind of valuable exploit may have ended up on an exploit marketplace in the interim.
From the https://immunefi.com/leaderboard/
#1. 4 paid reports: $13,010,000 total earnings
#2. 2 paid reports: $10,020,000 total earnings
#3. 8 paid reports: $8,010,000 total earnings
If these trillion dollar companies messing around with your personal information was an existential threat to their business, they would pay comparably with crypto companies.
But taking an ancient bounty and multiplying it by an exchange rate from years later would definitely be silly.
Yes, but you have to go through a KYC process, and of course pay your taxes. (In the US)
It also depends on which country you're in. There are a lot of OTC desks if you know where to look.
Then you realize developers at all companies are nearly universally bad.
It's a kind of miracle any of this stuff works at all, despite all the intelligence that's gone into them.
This seems even more ludicrous than this recent Outlook credential theft bug https://msrc.microsoft.com/update-guide/en-US/vulnerability/... or this recent RCE glitch in the Windows networking stack https://msrc.microsoft.com/update-guide/vulnerability/CVE-20....
Can't believe this is real to be honest...
Edit: As the article itself stated, around 25% of all systems with this setup are vulnerable!
> The results surprised us: 25% of all the multi-tenant apps we scanned were vulnerable to authentication bypass.
If only. How about: just download the backup of the server log from https://example.com/logfile.txt? Oh, and it contains everything. Including internal application logs.
In general, one should always use roles in Azure. Even if you have a flaw like this, your endpoint would be safe if you required a role to access your endpoint.
For multi-tenants, I completely this misconfiguration, there’s no real warnings when configuring it. In order to lock down to specific tenants, I recommend having a list of issuers that you check the token against.[2]
[1] https://intility.github.io/fastapi-azure-auth/single-tenant/...
[2] https://intility.github.io/fastapi-azure-auth/multi-tenant/a...
Why not? It's pretty much in line with expectations on my end.
Things I still regularly come across:
- developers with copies of the production database on their laptop
- said laptop doesn't have an encrypted hard drive
- every developer having access to production databases, including people hired yesterday
- default userids / passwords hardcoded in firmware
- the marketing department having access to the production database in bulk
- datalakes with zero access controls that perfectly mirror the production db
- sharepoints without proper authentication storing mountains of customer data
Anyway, I could go on like this for a while. And usually the company employees are aware of these, they just haven't gotten around to plugging the holes or they were never going to unless someone told them to because it is convenient. Occasionally there is serious pushback, for instance against developers having a recent copy of the production database on their laptop is in some places considered perfectly normal.
> every developer having access to production databases, including people hired yesterday
Do you expect new developers to have a wait period before being able to access sensitive materials? That seems like a recipe for disaster, you’re openly saying “I don’t trust you” at the start of your relationship with someone, when it’s the most volatile.
I’m almost positive that doing it will just cause your new devs to resent their new bosses from day 1.
Your original comment makes it seem like you feel someone should not have access simply because they’re new. Not that nobody should have access at all.
I wonder how that correlates with companies bragging that they only take day or even few hours to have new hire code landing at production "coz they are so agile"
Instead, it gives us exposure to a new set of higher level security problems, that over time we will need to develop higher level primitives to navigate. We would still have these problems with lower level languages, we'd just be too overwhelmed with smaller issues to properly address them
These seem quite contradictory statements. Copying something from StackOverflow and using it in production code without making sure you fully understand what it does? And something like "verify: false" should be an instant red flag that you need to triple-check to make sure that’s really the correct thing to do for your use case.
I would have added quite a few more exclamation marks myself. That bug should have gotten way more than a $40k bounty.
If there was a competitor to AD that is. Right now developers and hn peeps have loads of options for their work, enterprises do not. I have Windows clients to authenticate, I need AD. I need forwards/ backwards compatibility on my clients, therefore I need Windows. I have applications that must run for several decades therefore I need Windows.
Or look at some alternatives like...
"Setting up Samba as an Active Directory Domain Controller" - https://wiki.samba.org/index.php/Setting_up_Samba_as_an_Acti...
What is the AIR business unit?
everyone always forget these when praising "open"ai closed products.
imagine google search showing other people's gmail content on web searches. That's what the current EULA for chatgpt allows to happen.
Do LLMs use fuzzy logic at all? I know fuzzy + neural network was a big thing in the 1990s or so, but I thought that LLM NNs (and most current NNs in AI) use Bayesian logic.
Not that you're wrong of course, but with an attack like that it wouldn't be accurate to say that every user is affected. At the same time, if you can't figure out if anyone was affected, what do you tell regulators?
They could definitely review historical or backup copies of their CMS databases for Bing, or database transaction logs, or whatever they have, to determine if this type of attack was ever launched. They'd have to correlate that to Bing visitor/usage records and hopefully be able to connect the dots. Even if they have the data to do this, I don't see them doing it.
Yes.
Then, on each AAD tenant that wants to use this app, an admin for that tenant would create their instance of the app, called an enterprise application or service principal. That second object can choose whether any user in that tenant can sign in to the app or not, and can assign AAD roles to users/groups.
It is very common for apps to have a single tenant, and therefor the app registration and enterprise application are both in the same tenant, but if the app registration would allow it, any tenant can create their instance, and assign users from their tenant any role they desire.
This means that it is possible to have an app managed really well within your tenant, yet make the mistake of allowing sign-ins from other tenants, and thereby outsiders could still have full access...
-how do I validate a token to confirm that a call has permissions to do a thing. -what secrets do I need to safeguard in order to be able to validate said tokens -does the caller need to store any secrets -when do I need to call external services in order to validate tokens.
Instead, AAD hides all thrse behind abstract terms like: service principal, app registration, enterprise application... No wonder people fuck up.
I can't even comprehend what "creating their own instance of an app" means! This is way more abstract than it needs to be. Does the code get served from somewhere else? Do they get db copies? Probably not... But it hurts to think in these terms when all we want is to make sure calls are authorized.
And yes, I have successfully implemented this kind of stuff before. I used to keep sections of the RFCs on speed dial. I've never had to deal with cloning app registrations.
You would think that if anyone knew how to configure Azure properly it would be Microsoft.
Wow.
The "Am I affected" section downplays the effect. If I understood it properly, this could already have been exploited, and nobody would ever be the wiser.
Everyone makes mistakes in their careers, but these are some awfully big mistakes with awfully big stakes.
Few weeks doing different tasks, or few months watching video on youtube on each OS?
Few days reading technical info about how OS works on low level, or reading articles about OS philosophy and general direction?
Few weeks doing different tasks, or few months watching video on youtube on each OS?
Few days reading technical info about how OS works on low level, or reading articles about OS philosophy and general direction?