
Taking over Azure DevOps accounts with one click - infosecau
https://blog.assetnote.io/2020/06/28/subdomain-takeover-to-account-takeover/
======
marshallford
Does the $3000 (USD?) bounty seem low to anyone else? Prior to reading the
timeline section at the bottom of the post I would have guessed a range of 25k
to 50k as a bounty for such a severe vulnerability.

~~~
donmcronald
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?

~~~
dividuum
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...](https://docs.microsoft.com/en-us/azure/active-
directory/develop/reply-url), Microsoft itself recommends to avoid them:
"Wildcard URIs, such as [https://*.contoso.com](https://*.contoso.com), are
convenient but should be avoided. Using wildcards in the redirect URI has
security implications."

~~~
donmcronald
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?

~~~
user5994461
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.

------
lmeyerov
FWIW, we've had a lot of fun doing web inventory mapping via OWASP OMASS
([https://github.com/OWASP/Amass](https://github.com/OWASP/Amass)): enumerate
via amass -> dump into neo4j or just csv/json -> explore with
jupyter/graphistry.

A _lot_ of bug bounties have been getting paid out this way. I can't share the
details, but we did it as a graph analytics demo with a financial partner
bigger than many countries, and 30min later, tickets filed. IMO every sec team
> 5 people should have something like this setup.

------
eganist
That bounty is an order of magnitude smaller than it should've been. It's an
account takeover defect that most anyone could fall for because of the
structure of the payload URL.

~~~
donmcronald
And it’s shocking they’re able to add a DNS zone for a domain they don’t own.
That alone is a massive issue for the email phishing potential. The
combination is stunning.

From: bob@project-cascade.visualstudio.com

SPF: pass

DKIM: pass

DMARC: none

“Hi it’s Bob from Project Cascade. We’re giving away Azure credits to anyone
who used our trial in 2019 or earlier. Visit project-
cascade.visualstudio.com/credits to check if you’re eligible.”

Click.

“Sorry, you’re not eligible.”

I’d fall for that :-(

~~~
gravitas
In all the cloud provider DNS services I've used you can add a zone for
anything with no verification of ownership. The root cause flaw is the domain
owner allowing their registrar data to go stale and let NS point at a shared
service where they did not own/host the records.

------
tcmb
Being awarded a bug bounty suggests that there was a bug that was fixed. But
this was actually a misconfiguration, wasn't it? Any Azure account with a
dangling subdomain and unrestricted reply-to is still vulnerable to this
attack, correct?

~~~
Someone1234
This critique seems to rely on an undefined definition of the terms
"misconfiguration" and "bug."

Reply-to is a bug. But it might be a configuration fix, as opposed to code
fix. But without knowing how it is implemented we cannot say.

And maybe more importantly the boundary between misconfiguration bugs and code
bugs is irrelevant from an outsider's perspective.

How reply-to is implemented is irreverent, the result is identical.

~~~
tcmb
The distinction is relevant from the perspective of any other customer on
Azure. A code fix would have fixed the problem for them, too, A fixed config
fixes the problem for visualstudio.com only. That's what I was getting at.

------
lowwave
It is kind funny (or click-baitish) articles with "one click" seems. From a
developer point of view, pretty much anything can be done with just one click.

~~~
Liquid_Fire
The point is that it requires just one click (on a link) from the target user
to steal their credentials, which is relatively easy to convince people to do,
as opposed to a more complicated sequence of steps.

------
magma17
stupid user action is needed, so it's not a critical bug.

