Taking over Azure DevOps accounts with one click | Hacker News Reader

Taking over Azure DevOps accounts with one click

blog.assetnote.io

118 pointsinfosecau25 comments

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.

Yes, it's way too low. Seeing companies cheapen out on bug bounties makes me feel less secure about them. It shows that they don't believe in the importance of security, provides less incentives for ethical hackers to find security issues and it means that less ethical hackers will be that much more tempted to use vulnerabilities they've found unethically.

Don't know the range of their bounty program but seems like this exploit is circumstantial on finding a subdomain which was left hanging. Once they registered that subdomain on their own account, this exploit seizes to be effective by third parties so reproducibility is minimal (subdomain can be registered once). Unless you plan to sell the exploit once to one client or just re-use it once at a time by selling access to it (too much trouble, centralized risk).

It's not about reproducibility but severity and value.

Offering low bounties for something like this can act as an incentive for people who find something like this to sell it somewhere else.

A bug like this would be orders of magnitude more valuable in the wrong hands.

How can a low bounty act as an incentive?

This attack could have been used to gain access to any Azure account.

If you knew that Microsoft would pay you a couple thousand for this and the black market would offer hundreds of thousands of dollars. It could influence a decision to not report the vulnerability to the developer.

I don't see how your explanation shows Microsoft creating the incentive. Your argument seems to amount to "Microsoft is not creating a sufficient disincentive." The problem with creating a sufficient disincentive is that you draw a lot of attention and still run the risk of being outbid when a vulnerability is discovered.

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."

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.

What's really WTF for me is :

  "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).

>>> 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 opened the comments section to ask the exact same question.

wondering how many hours did he put on this.

FWIW, we've had a lot of fun doing web inventory mapping via OWASP OMASS (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.

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.

Probably makes a lot of less than ethical security researchers wonder if maybe they should do something else with the knowledge of the vulnerability next time

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 :-(

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.

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?

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.

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.

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.

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.

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

Reply on news.ycombinator.com