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

71–80 of 114 posts

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

#71

Post by foota »

jorge_leria wrote: post #70

Hi! I'm the person in charge of managing the bug bounty program, and I'd like to shed light on what happened from our end. I already apologized and explained this to @0xcrypto internally, but I believe that I should say something here to clarify what happened. The truth here is that we were never able to fully reproduce the issue from the beginning, but struggled to close it because of the fear of missing something.…

It's unclear to me (not that I necessarily need to know), but do you believe in the end that the vulnerability as described there worked, and if so, do you know why you failed to reproduce it?

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

#72

Post by andix »

I don't understand why this issue was not communicated to Microsoft. They could've just revoked access for this oauth application until the issue was fixed.

Although there are probably thousands of similar bad implementations out there that are connected to Microsoft via oauth.

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

#73

Post by andix »

jorge_leria wrote: post #70

Hi! I'm the person in charge of managing the bug bounty program, and I'd like to shed light on what happened from our end. I already apologized and explained this to @0xcrypto internally, but I believe that I should say something here to clarify what happened. The truth here is that we were never able to fully reproduce the issue from the beginning, but struggled to close it because of the fear of missing something.…

Great to hear, I love using Harvest. But could you please finally fix the (not so) new mobile app (iOS)? There are so many tiny issues that I stopped reporting them to your support.

The app state constantly gets out of sync with server state (some changes on the server only show up after a force reload, some changes on the client just revert after pressing save)

And the time tracking UX is so annoying (buttons that are only visible if you scroll down, start/stop/restart/delete buttons are constantly at different locations, depending on the state of the item).

The old app was not pretty, but it worked without issues.

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

#74

Post by jorge_leria »

foota wrote: post #71
jorge_leria wrote: post #70

Hi! I'm the person in charge of managing the bug bounty program, and I'd like to shed light on what happened from our end. I already apologized and explained this to @0xcrypto internally, but I believe that I should say something here to clarify what happened. The truth here is that we were never able to fully reproduce the issue from the beginning, but struggled to close it because of the fear of missing something.…

It's unclear to me (not that I necessarily need to know), but do you believe in the end that the vulnerability as described there worked, and if so, do you know why you failed to reproduce it?

The fact that we kept it in triage means that we believed there was something. Also the reporter gave a really good explanation.

By the time the report was originally sent the feature was just released, and while we never deployed a code change to directly address it, it wouldn't be the first time that we receive something that I believe it was genuinely a security issue and stopped being reproducible due to an seemingly unrelated change around the same time.

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

#75

Post by mooreds »

withinboredom wrote: post #31
mooreds wrote: post #28

Earlier quoted context omitted.

So it was the combination of: * the additional redirect using the JSON object in state * the `subdomain` not being properly verified * the implicit grant being supported Which allowed an attacker to get an access token for a user's Microsoft account. From my reading, this seems to be entirely an issue due to an improper implementation on Harvest's side, nothing to do with Microsoft's implementation of OAuth. Am I cor…

Clearly not, or I doubt we would be reading this blog post. I assume that for several years though, that was exactly what Microsoft thought too.

What am I missing then?

It seems pretty clear to me from reading the blog post that the issue was what I outlined (sorry for the lack of list formatting, I always forget I need an extra line after each bullet point).

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

#76

Post by phatskat »

jussij wrote: post #15
meibo wrote: post #12

Earlier quoted context omitted.

Microsoft checks the return URL to see if it is one of the whitelisted URLs specified by Harvest. Harvest added their own redirection mechanism on top of this, presumably to support multiple instances of their software, which did not do a good job of sanitizing input values for their redirect. So no, this is not an implicit issue with oauth, just a shoddy implementation.

Ok, I think I understand but correct me if I'm wrong. Normally that return URL would be hidden from view, as it would live in configuration detail found inside of the Microsoft system, attached to the client_id. However, Harvest weakened this security by adding in the additional (and unsafe) return_to parameter to manage their return URL.

Not as far as I recall (haven’t done OAuth in a hot minute) but the redirect URL is typically in the GET parameters or in the body of the request, neither of which is hidden from view.

This issue seems to be that there was a secondary redirect in the body of one of the requests (I believe the token response), that could be forged to loosely match a trusted domain but with an attacker’s domain present, eg “//attacker.com/trusted.com/“.

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

#77

Post by zeven7 »

mooreds wrote: post #75
withinboredom wrote: post #31

Earlier quoted context omitted.

Clearly not, or I doubt we would be reading this blog post. I assume that for several years though, that was exactly what Microsoft thought too.

What am I missing then? It seems pretty clear to me from reading the blog post that the issue was what I outlined (sorry for the lack of list formatting, I always forget I need an extra line after each bullet point).

Not sure what parent was talking about. You are correct. This is Harvest’s responsibility, not Microsoft’s.

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

#78

Post by madeofpalk »

andix wrote: post #72

I don't understand why this issue was not communicated to Microsoft. They could've just revoked access for this oauth application until the issue was fixed. Although there are probably thousands of similar bad implementations out there that are connected to Microsoft via oauth.

I did not know that was possible! I would never have thought to do that, personally.

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

#79

Post by withinboredom »

zeven7 wrote: post #77
mooreds wrote: post #75

Earlier quoted context omitted.

What am I missing then? It seems pretty clear to me from reading the blog post that the issue was what I outlined (sorry for the lack of list formatting, I always forget I need an extra line after each bullet point).

Not sure what parent was talking about. You are correct. This is Harvest’s responsibility, not Microsoft’s.

I didn't understand the article correctly. I was wrong.

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

#80

Post by madeofpalk »

michaelt wrote: post #64
scurvy_steve wrote: post #56

Earlier quoted context omitted.

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 exp…

It's kinda normal that you'd want to let a user log in and return them to the page they were at. For example, if you're making a shopping website and a user asks to put something in their basket and you send them to log in, you'd want to return them to the item they were about to buy, not dump them back at the homepage. What's the proper way of doing this, without "abusing state" ?

At the least you're supposed to validate the at the returning "state" parameter is the same value as what you sent (using cookies or local storage).

Ideally you would 'consume' the token before redirecting, and not send it to the second redirecting url.

Post reply on HN