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

101–110 of 114 posts

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

#101

Post by 0xcrypto »

matja wrote: post #85
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…

But in the POC link, they have state=1 as a parameter for the authorization server, there is another state parameter encoded into the value for the redirect_uri, which makes me wonder why that even matches the registered redirect_uri.

You are right that redirect_uri must match the exact registered redirect_uri.

But some providers allow query parameters. For Microsoft, it was possible in 2020 when I reported the vulnerability. In 2022, they restricted query parameter support to only applications that is built for Work and School accounts and in August 2022, they added a section for this in the documentation.

See: - Commit: https://github.com/MicrosoftDocs/azure-docs/commit/c249a0548... - Current Documentation: https://learn.microsoft.com/en-us/azure/active-directory/dev...

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

#102

Post by peeters »

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.

That's the gist.

> The authorization server SHOULD require the client to provide the complete redirection URI (the client MAY use the "state" request parameter to achieve per-request customization). If requiring the registration of the complete redirection URI is not possible, the authorization server SHOULD require the registration of the URI scheme, authority, and path (allowing the client to dynamically vary only the query component of the redirection URI when requesting authorization).

> The authorization server MAY allow the client to register multiple redirection endpoints.

https://datatracker.ietf.org/doc/html/rfc6749#section-3.1.2....

Either the redirect URL is statically configured, or it's accepted as a query param to the auth request, and subject to a strict whitelist. It's not a secret from the user, but even for a SPA it is usually transient so you don't have the user sitting at some ugly URL with "?code=abc123...". Typically you would use the state query param to retain any context needed to redirect the user to their desired destination, but that would be after the redirect endpoint uses the passed code to fetch the token and store it somewhere locally. In this case apparently the redirect endpoint allowed redirecting to entirely different applications by simply forwarding on the sensitive query params, but did not validate that those destinations were on any whitelist.

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

#103

Post by polack »

jorge_leria wrote: post #74
foota wrote: post #71

Earlier quoted context omitted.

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

It's a really simple vulnerability though. It comes of like you're not really on top of things when you cant reproduce or close it.

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

#104

Post by jabiko »

jorge_leria wrote: post #74
foota wrote: post #71

Earlier quoted context omitted.

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

I'm wondering how your two quotes "security of our customers is of the utmost importance to us" and "we believed there was something" fit together given that the issue stayed open for three years?

So for three years you believed there was something, yet you didn't invest sufficient resources to reproduce and/or understand the issue, while at the same time, all these three years security was of utmost importance?

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

#105

Post by belter »

belter wrote: post #17

Worth quoting here... "...In the process of disclosing and patching this vulnerability, the Harvest team was barely responsive. The company acknowledged the vulnerability by triaging but took a very long time to fix the vulnerability. After 3 years of reporting, the company finally fixed the vulnerability silently and didn't bother to inform...no bounty or even HackerOne points were rewarded by the company..." And fr…

Question to mods? Was there any particular reason why this post was moved to the bottom of the thread? I can see the reasoning if a person mentioned in the post replies that their answer is moved to the top of the thread. But are HN mods now also moving post independently of the upvotes? Is the criteria mentioned somewhere?

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

#106

Post by pravus »

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

There's no reason to have a URL (or any data) encoded in the state parameter. The purpose of the parameter is to provide an opaque lookup key which you can utilize to provide correct, validated responses. This is usually done in some sort of database or Redis-like cache. My workflows have always used a random UUID for the state key and I just encode the necessary (validated) data items needed for the next step as a JSON blob. It's essentially a very short-lived web session.

If for some reason you really do need to transmit this data in-band (ultra rare use case) you should at least be using something like HMAC to verify that all carriers have transported the data unmodified. It is your responsibility to ensure the integrity of the data end-to-end.

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

#107

Post by mooreds »

tptacek wrote: post #40
mooreds wrote: post #8

Man, the implicit grant is pretty horrible, for exactly the reasons shown in this post. FYI, they are omitting it in the upcoming OAuth 2.1 spec: https://www.ietf.org/archive/id/draft-ietf-oauth-v2-1-09.htm...

It's been deprecated for like 6 years now, too, right? There'd be no reason to keep it in the new spec, since CORS obsoletes it.

I wasn't able to find an exact date for deprecation, but I know that PKCE replaced it for the main use case, and that was released in 2015.

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

#108

Post by jorge_leria »

jabiko wrote: post #104
jorge_leria wrote: post #74

Earlier quoted context omitted.

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

I'm wondering how your two quotes "security of our customers is of the utmost importance to us" and "we believed there was something" fit together given that the issue stayed open for three years? So for three years you believed there was something, yet you didn't invest sufficient resources to reproduce and/or understand the issue, while at the same time, all these three years security was of utmost importance?

Hey, I got into more details in my internal discussion with the researcher and previous post, but around the time we determined we couldn't replicate it, we got a similar report leading me to believe this was already closed. I didn't believe there was something the whole time. It was a mix-up on my side, and I'm sorry about it.

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

#109

Post by barryrandall »

tptacek wrote: post #40
mooreds wrote: post #8

Man, the implicit grant is pretty horrible, for exactly the reasons shown in this post. FYI, they are omitting it in the upcoming OAuth 2.1 spec: https://www.ietf.org/archive/id/draft-ietf-oauth-v2-1-09.htm...

It's been deprecated for like 6 years now, too, right? There'd be no reason to keep it in the new spec, since CORS obsoletes it.

Unfortunately, the old tutorials and StackOverflow answers people are getting their logic from haven't been deprecated.
Post reply on HN