Yeah. It seems low to me. The team writing the auth code is probably paid a fortune comparatively. It’s also surprising to see MS has mistakes like that in the auth flow. I know it’s a combo, but still, damn!
I don’t know enough about dev.azure.com, but if they could do more than read info, like spin up VMs, then $3k is an insulting joke. Doubly so if there are credit cards attached to those accounts. The idea of someone spinning up resources on my Azure account gives me nightmares.
It’s also worth noting the combo here is really nasty because DNS takeover means you could send phishing emails from a legit sub domain.
What’s the damage to MS if someone nefarious had found that and launched a huge phishing campaign?
It's highly recommended to not allow wildcards in the redirect_to values within OAuth2 for that reason: It's just too easy to create flaws like this one. Additionally on https://docs.microsoft.com/en-us/azure/active-directory/deve..., Microsoft itself recommends to avoid them: "Wildcard URIs, such as https://*.contoso.com, are convenient but should be avoided. Using wildcards in the redirect URI has security implications."
"We found that we could exchange the stolen authentication token for a Bearer token through app.vsaex.visualstudio.com"
For me this exchange should always require an additional secret they should not have access to (exception would be for an app where securing the secret is not trivial, but not the case here I believe).
That’s why I said I was surprised. I just can’t understand how anyone, let alone what I assume is a team, could write auth code without reading the spec to see what every parameter does. Even if you weren’t paying attention I feel like you shouldn’t miss that one, right?
Is that full stack overflow development where some one is copying and pasting things they don’t understand?
The recommendation is ignoring the reality of the world. How can developers handle authentication when authentication is not allowed on their company domains?
Measures like filtering/whitelisting are always pushed back in my experience because it's legitimately preventing developers to support authentication.
>>> It’s also surprising to see MS has mistakes like that in the auth flow.
Having worked on authentication code across companies, this is really the typical kind of mistakes one sees. Nothing special to MS.
It's not even a simple stupid bug, like allowing open redirections. There was some checks on domain and an abandoned whitelisted domain that could be acquired by a new user.
I don’t know enough about dev.azure.com, but if they could do more than read info, like spin up VMs, then $3k is an insulting joke. Doubly so if there are credit cards attached to those accounts. The idea of someone spinning up resources on my Azure account gives me nightmares.
It’s also worth noting the combo here is really nasty because DNS takeover means you could send phishing emails from a legit sub domain.
What’s the damage to MS if someone nefarious had found that and launched a huge phishing campaign?