unddoch
4 days ago
If anyone from Microsoft security reads this, could you please do something about login.microsoftonline.com/XXX/v2.0/adminconsent?
The callback you're redirecting the user to at the end of that flow is forgeable if an attacker knows an azure tenant ID of a different customer, and putting a "Never use the tenant ID value of the tenant parameter to authenticate or authorize users" warning in the docs is only helpful as long as a way to authenticate users exists.
birdsongs
4 days ago
They'll see it, tell a manager, it'll get added as a ticket to an Azure Devops board under the initiative for this month under the epic for employee suggestions, which will be reviewed & prioritised by Copilot and sent to a different middle manager as a weekly summary email and then automatically closed when no human ever interacts with the ticket after three months.
rsalus
4 days ago
speaking as a FTE at Microsoft... yup
0xWTF
4 days ago
Glad to know the frozen middle exists among the hyperscalers. High confidence you can swap the entire leadership team and nothing will change.
jiggawatts
4 days ago
> frozen middle
That’s the best new term I’ve learned in months!
pphysch
4 days ago
See also "defensive bureaucracy"
Henchman21
4 days ago
I spent 6 months working as a contractor in MS’ Chicagoland data centers. Nothing worked — phones on the walls ran Windows and did not give dial tone. Security systems unable to function because of Windows updates. Personnel more concerned with their required LinkedIn updates than their jobs. Not one FTE liked their role — everyone had a foot out the door.
When they offered to make me FTE I declined and moved on. Because it was an obvious absolute shit-show.
Sorry for those that are currently employed by MS.
throwup238
4 days ago
It’s not all bad. When I was there, the Washington campus had a restaurant with a three course menu for $15, designed by a Seattle celebrity chef.
gscott
4 days ago
Come for the paycheck... stay for the food!
Henchman21
3 days ago
We had a vending machine that required an app that made you buy tokens to access the food in the vending machines. Said app was a masterpiece of dark patterns. Put money in, maybe, if you're lucky, get food out. Maybe.
user
4 days ago
wibartle
4 days ago
That's me. But I don't understand your comment. Could you expand on it, either in a reply or preferably by email or via an MSRC case? You can reply with the vuln number so I can fast route it.
> The callback you're redirecting the user to at the end of that flow is forgeable
The redirect_uri is checked against the app registration. There's a general OAuth problem called "open registration redirects" that applies here, about which we've [blogged](https://www.microsoft.com/en-us/security/blog/2026/03/02/oau...) - but frankly, none of the industry solves this well.
In general, "I can create a link that goes to malware via X endpoint" isn't very interesting - you can also just create a direct link to the malware. Web browsers won't reliably show you the real destination of a link anyhow and even if they did, it's mostly just us hackers who understand URLs at all.
> as long as a way to authenticate users exists.
I'm lost. Entra supports [OpenID Connect](https://learn.microsoft.com/en-us/entra/identity-platform/v2...) for authentication. Most portals that surface admin consent authenticate the user with an OpenID Connect request either immediately before or after the admin consent request.
unddoch
2 days ago
I am a service provider. I have an Azure app registered so that clients can connect my app to their Azure environment.
Client A connected their Azure env to my service. Now an attacker creates a different tenant at my service and goes through the integration flow. Then he sends a request to my callback that says "admin consent configured for client A's tenant" and wants to steal Client A's data. How do I protect against that? Should I validate that the user who started the flow belongs to the same Azure tenant id? In itself it's not enough, what if it's just a random user without actual permissions to go through admin consent? What if a client legitimately has multiple tenants in my service that need to connect to the same azure tenant?
wibartle
a day ago
> Should I validate that the user who started the flow belongs to the same Azure tenant id?
Yeah. Basically, I'd expect most services are responding to the admin consent callback by saying "Admin consent flow complete. Redirecting to previous page" (usually some setup flow page). Then that page does whatever it normally does (presumably OpenID Connect sign-in with a cache in cookies / localStorage / sessionStorage) to authenticate the user.
So in a typical flow, the user is already signed in, and your service just reads their identity out of storage after the admin consent flow. If your service receives an unsolicited admin consent callback (and so there is no "previous page" and no user is signed in), I'd expect it goes to your service home page which either tries to sign the user in or shows an unauthenticated experience.
That's to say - most services setup flows are multi-step anyway. First the customer provides some information, then they sign a contract, then they pay, then they admin consent, then they configure your service's primary configuration. If admin consent is launced from /setupwizard/step4, then after admin consent, you go on to /setupwizard/step5. The normal thing step5 does (presumably, checking that the user is signed in, and then show the primary configuration user interface) should be good enough, just the same as if somebody randomly hit step5 without hitting step4 previously.
unddoch
12 hours ago
I want to first say thanks for engaging with me on this issue so directly, much appreciated.
As I said earlier - validating that the customer controls an azure user doesn't necessarily mean that they have permissions to grant admin consent.
Further, I think you perhaps kind of implicitly assume that when I authenticate users I do that by their Azure identity. In practice that can be a whole spectrum - whether I have my own user management system, and whether I couple it to Entra or not is not something you can rely on. Customers expect their preferred IdP to work with your service.
Btw, I just found a short article referencing this issue, offering the same solution with the same "vulnerable to inside org privesc" gap: https://medium.com/@dipakkrdas/microsoft-adminconsent-can-le...
Making this inherently secure is just not that hard here - you could easily make this a bit more PKCE like with an additional service->azure call before redirecting the user to the flow or by adding a symmetrical signature to the callback and a new API to verify the signature.
publlus_enigma
4 days ago
I'm sure one of the 60,000 employees who have been told they're welcome not to work there anymore, because the line must go up infinitely, will be chomping at the bit to do so.
nikanj
4 days ago
I love that this is the most reliable way to actually contact an actual human working at Microsoft
collabs
4 days ago
Reaching an actual human at Microsoft isn't enough. You have to reach the correct humans which is a much harder task. For example, you might have an idea. What if azure devops had a field for date component only, not date time, just the date because it would help you in an internal project. Can you find out who to reach? Even if you work at Microsoft, I would bet you cannot. Even when you find a defect in an internal product you are using, getting to a human requires you to go through layers of nonsense. I distinctly remember my manager telling me to not even bother explaining myself to the first support chat and to simply ask them to escalate. I was impressed at how they managed to make security a part of your review though. I never thought getting buy-in to update Newtonsoft.Json would be as easy as it was but a CVE meant you had to update it to whatever made the security flags happy.
Once I could reach the actual engineering team to look at the internal tool to look at the bug I had to report though, they were very responsive. The tool for communicating was cumbersome and made me feel like a vendor / customer relationship even though you are supposed to be the same team but once they realized it was an actual defect and not some harebrained feature request, they fixed it relatively quickly.