Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Stealing OAuth tokens of Microsoft accounts via open redirect in Harvest App

eval.blog

Post reply on HN
Print view View original

51–60 of 114 posts

Re: Stealing OAuth tokens of Microsoft accounts via open redirect in Harvest App

#51

Post by nurple »

0xcrypto wrote: post #47
nurple wrote: post #25

The headline seems pretty unfair to Microsoft here, seemingly to capitalize on the press of their recent auth disaster. The first thought that came to my mind on reading the headline was "oh great, another MS breach". These are in fact harvest's tokens, which only erroneously exposed access to their app, because of an injection vuln in their code, and would be exactly as compromised behind any other IdP.

Hi, author of the blog post here. Yes I understand your concern and I tried keeping Microsoft's name out of the title but couldn't think of anything else. Since the vulnerability only affects the oauth implementation for the connection with Microsoft accounts. Previously the title was "Microsoft OAuth token leak via open redirect in Harvest App" but later I changed it to "Microsoft Account's OAuth tokens leaking via…

If only tokens minted by MS were in scope of the vulnerability because of Harvest's outlook integration, maybe something like "Harvest OAuth CSRF Leaks Tokens of Microsoft Outlook Users" or "CSRF in Harvest's Outlook Integration Leaks User Tokens".

If you want to add any editorializing around mitigation, linking to the OAuth RFC[0] that dictates a MUST for binding the users auth state with the request to prevent such attacks would be instructive to readers.

[0] https://datatracker.ietf.org/doc/html/rfc6749#section-10.12

Re: Stealing OAuth tokens of Microsoft accounts via open redirect in Harvest App

#52

Post by 0xcrypto »

nurple wrote: post #51
0xcrypto wrote: post #47

Earlier quoted context omitted.

Hi, author of the blog post here. Yes I understand your concern and I tried keeping Microsoft's name out of the title but couldn't think of anything else. Since the vulnerability only affects the oauth implementation for the connection with Microsoft accounts. Previously the title was "Microsoft OAuth token leak via open redirect in Harvest App" but later I changed it to "Microsoft Account's OAuth tokens leaking via…

If only tokens minted by MS were in scope of the vulnerability because of Harvest's outlook integration, maybe something like "Harvest OAuth CSRF Leaks Tokens of Microsoft Outlook Users" or "CSRF in Harvest's Outlook Integration Leaks User Tokens". If you want to add any editorializing around mitigation, linking to the OAuth RFC[0] that dictates a MUST for binding the users auth state with the request to prevent such…

Oh yes, that sounds better. I am changing the title now.

Updated to "Stealing OAuth tokens of connected Microsoft accounts via open redirect in Harvest App"

Re: Stealing OAuth tokens of Microsoft accounts via open redirect in Harvest App

#53

Post by matja »

Uvix wrote: post #44
matja wrote: post #43

RFC 6749 goes into details on how the authorization server should prevent this type of attack The authorization server MUST require public clients and SHOULD require confidential clients to register their redirection URIs. If a redirection URI is provided in the request, the authorization server MUST validate it against the registered value. So how is this possible, when presumably the Harvest app did not register th…

The Harvest redirect_uri is registered with Microsoft. Harvest implements its own redirect after the Microsoft OAuth server redirects to them, based on the data in the state.

I agree the fact that Harvest blindly redirects helps enable the attack, but according to the OAuth standard, a redirect_uri which does match a registered one should not be accepted before authorization takes place.

From the POC authorization URL, the redirect_uri parameter and value are:

    redirect_uri=https%3A%2F%2Foutlook-integration.harvestapp.com%2Fauth%2Foutlook-calendar%2Fcallback?state=%7b%22return_to%22:%22/time%22%2c%22subdomain%22:%22example.com/%22%7d
So if Harvest registered the redirect_uri as:

    https%3A%2F%2Foutlook-integration.harvestapp.com%2Fauth%2Foutlook-calendar%2Fcallback
then why does any extra URL parameters added to that value get accepted by the Microsoft OAuth server before authorization, when they clearly do not match the registered one?

edit: I tried authorizing using another OAuth server provider, with a changed redirect_uri by appending URL parameters to the encoded value, and the OAuth server (I believe, quite rightly) rejected the authorization request.

Re: Stealing OAuth tokens of Microsoft accounts via open redirect in Harvest App

#54

Post by lukevp »

astrostl wrote: post #50

Well, this is disconcerting. I've used Harvest and found the support to be absolutely stellar, with prompt responses that clearly and deeply understood the nuances of how customers are using the product and detailed steps on how to creatively use existing features. Anything unimplemented yielded, "we'll put that on the backlog but no promises." Given the 30 headcount cited in engineering [1], I don't know where it go…

I can’t tell if you love it or hate it… is this sarcastic?

Re: Stealing OAuth tokens of Microsoft accounts via open redirect in Harvest App

#55

Post by astrostl »

lukevp wrote: post #54
astrostl wrote: post #50

Well, this is disconcerting. I've used Harvest and found the support to be absolutely stellar, with prompt responses that clearly and deeply understood the nuances of how customers are using the product and detailed steps on how to creatively use existing features. Anything unimplemented yielded, "we'll put that on the backlog but no promises." Given the 30 headcount cited in engineering [1], I don't know where it go…

I can’t tell if you love it or hate it… is this sarcastic?

I wouldn't say that I love or hate it. The post definitely isn't sarcastic. What part(s) need more clarity for you?

Re: Stealing OAuth tokens of Microsoft accounts via open redirect in Harvest App

#56

Post by scurvy_steve »

matja wrote: post #43

RFC 6749 goes into details on how the authorization server should prevent this type of attack The authorization server MUST require public clients and SHOULD require confidential clients to register their redirection URIs. If a redirection URI is provided in the request, the authorization server MUST validate it against the registered value. So how is this possible, when presumably the Harvest app did not register th…

They are adding a second redirect on top and sticking it into the state parameter, presumably so they can redirect to anywhere. so the flow wanted was

Go the some harvest authorize url,

That redirects to the Microsoft authorize url with redirect_uri=registered_uri and state=some_encoded_final_uri,

user enters credentials,

redirect to a registered uri

read state parameter and redirect to uri encoded in state.

This exploit still redirect to an authorized uri, but that endpoint then reads the the state parameter and happily forwards the response/token.

3 mistakes in this, abusing state, not encypting and validing state if you are going to abuse it. Enabling implicit grant(even if they needed it, should have made a second registration with limited uses).

Re: Stealing OAuth tokens of Microsoft accounts via open redirect in Harvest App

#57

Post by Uvix »

matja wrote: post #53
Uvix wrote: post #44

Earlier quoted context omitted.

The Harvest redirect_uri is registered with Microsoft. Harvest implements its own redirect after the Microsoft OAuth server redirects to them, based on the data in the state.

I agree the fact that Harvest blindly redirects helps enable the attack, but according to the OAuth standard, a redirect_uri which does match a registered one should not be accepted before authorization takes place. From the POC authorization URL, the redirect_uri parameter and value are: redirect_uri=https%3A%2F%2Foutlook-integration.harvestapp.com%2Fauth%2Foutlook-calendar%2Fcallback?state=%7b%22return_to%22:%22/ti…

Allowing the query string to be altered is allowed but discouraged by the OAuth 2.0 spec: https://datatracker.ietf.org/doc/html/rfc6749#section-3.1.2....

Re: Stealing OAuth tokens of Microsoft accounts via open redirect in Harvest App

#58

Post by matja »

Uvix wrote: post #57
matja wrote: post #53

Earlier quoted context omitted.

I agree the fact that Harvest blindly redirects helps enable the attack, but according to the OAuth standard, a redirect_uri which does match a registered one should not be accepted before authorization takes place. From the POC authorization URL, the redirect_uri parameter and value are: redirect_uri=https%3A%2F%2Foutlook-integration.harvestapp.com%2Fauth%2Foutlook-calendar%2Fcallback?state=%7b%22return_to%22:%22/ti…

Allowing the query string to be altered is allowed but discouraged by the OAuth 2.0 spec: https://datatracker.ietf.org/doc/html/rfc6749#section-3.1.2....

Interesting, thanks!

Re: Stealing OAuth tokens of Microsoft accounts via open redirect in Harvest App

#59

Post by btilly »

cowsup wrote: post #19
eterm wrote: post #7

I really feel like Hackerone isn't really holding up their end of the bargain if they let companies sit on things like this for 3 years.

Of the three parties involved (HackerOne, the company, and the researcher finding the bug), the company has all of the leverage. If they feel like HackerOne is stepping on their toes and making decisions as to whether to "let" companies do things, those companies will just leave HackerOne and create an in-house solution.

You assume that the reputation loss of leaving HackerOne is not an issue for the company.

It seems very reasonable to me that if the decision to leave HackerOne is prompted by conflict over responsible disclosure, then it is appropriate for HackerOne to disclose that fact. Including disclosing the bugs that the company was unwilling to responsibly disclose.

This puts HackerOne in the position of actually representing the interests of the hackers. And makes participating in HackerOne to be more than a meaningless publicity gesture for the companies.

Re: Stealing OAuth tokens of Microsoft accounts via open redirect in Harvest App

#60

Post by 0xcrypto »

EE84M3i wrote: post #16
eterm wrote: post #7

I really feel like Hackerone isn't really holding up their end of the bargain if they let companies sit on things like this for 3 years.

Hackerone is beholden to the company running the bug bounty program. The extent that they are involved heavily depends on what services they are providing (triage, etc). At the most basic level, they're just providing a platform for disclosure of vulnerabilities and some boilerplate legalese to prevent legal departments from sueing researchers. In the vast majority of cases, companies deny requests for public disclos…

Author of the blog post here. Yes, I agree that it wasn't Hackerone's fault and they tried their best to help.

As for the violation of agreement with hackerone, I have read the policy many times before publishing the article and even asked Hackerone about this. The vulnerability is already fixed and I haven't heard from Harvest since April 2022 so there's no point asking them as it would seem like a threat rather than an actual disclosure. An excerpt from the agreement:

> Last resort: If 180 days have elapsed with the Security Team being unable or unwilling to provide a vulnerability disclosure timeline, the contents of the Report may be publicly disclosed by the Finder. We believe transparency is in the public's best interest in these extreme cases.

Post reply on HN