11 ms·
Stealing OAuth tokens of Microsoft accounts via open redirect in Harvest App
- lsowen 3y agoIt took THREE YEARS (August 2020 - August 2023) to fix the vulnerability? I'm not sure the size of the Harvest team, but that still seems insane.
- politelemon 3y agoI'm guessing, as would be typical of many companies, it ended up on a backlog as low priority, survived a few Jira reorganisations and corporate restructuring, before eventually being noticed and fixed.
- bonzini 3y agoProbably fixed without even noticing when a dependency was updated...
- config_yml 3y agoThey're a small company with an even smaller engineering team, I think 13 devs or something like that. I would imagine either everyone knows about it immediately or they are too overloaded with work that it gets deprioritised into oblivion after a quick first look.
- lol768 3y agoIt's not an excuse, it's just poor engineering culture or lack of security awareness. I work with an engineering team of 5 - security issues still get prioritised and fixed. Feature work gets deprioritised, as it should, as soon as there's a credible security concern.
- LightBug1 3y agoYou must work at a half-decent outfit then.
- lawgimenez 3y agoIf they had time to rewrite the whole native app to React Native then they should have enough time to triage this security issue.
- dmvdoug 3y agoObligatory link: https://youtu.be/Uo3cL4nrGOk https://youtu.be/Uo3cL4nrGOk
- nurple 3y agoAll they had to do was add and validate a nonce value in the state, or at the very least, to triage, sanitize the subdomain value. The latter would literally be a 10 minute fix.
- jorge_leria 3y agoHarvest Security Team here. I addressed this on another comment, but basically we were never able to reproduce and there was no explicit fix, but it stayed on Triage state when it should've been Closed, due to a human error on my side.
- steve1977 3y agoWell, as they say on their homepage, it’s more than just time tracking…
- eterm 3y agoI 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.
- EE84M3i 3y agoHackerone 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 disclosure. A researcher that discloses regardless of permission violates their agreement with hackerone and the company and exposes themselves to legal liability. In this case it seems the company agreed to public disclosure, which IMO should be applauded, even if their response was very slow. I've personally had several four figure bugs unremediated for >1year, but I never thought it was hackerone's fault.
- eterm 3y agoSo, bug bounty programmes sprung up as a well to help coordinate disclosure and help researchers engage in responsible disclosure. A key part of responsible disclosure is the disclosure part. Often researchers would disclose unpatched issues to put weight on companies, even large companies, to actually patch issues. One of the side-effects of programs like Hackerone is that actually doing your own responsible disclosure is now frowned upon (often to the point of legal problems). But part of the social contract of absorbing coordinated disclosure should be an expectation that hackerone allows disclosing even unfixed issues. Hackerone should not be "beholden" to companies. They make the rules. They could allow disclosure of issues if they wanted to make that a condition of the platform. It's companies sitting on vulnerabilities that birthed the concept of "responsible disclosure" in the first place. If H1 etc are allowing it then there needs to be renaisance of the practice outside the platforms.
- jdironman 3y agoSo, it basically sounds like we are missing a governed body consiting or researched with possibly tiered disclosure process (for severity) and the possibility to _maybe_ apply for an extension of disclosure. Would this ever happen?
- mooreds 3y agoMan, 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.html#name-removal-of-the-oauth-20-imp https://www.ietf.org/archive/id/draft-ietf-oauth-v2-1-09.htm...
- tptacek 3y agoIt'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.
- mooreds 3y agoI 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.
- barryrandall 3y agoUnfortunately, the old tutorials and StackOverflow answers people are getting their logic from haven't been deprecated.
- jussij 3y agoCan someone with OAuth expertise explain this issue in a few more details, as I've read the blog a few times, but still don't understand the actual vulnerability. From my very limited OAuth knowledge isn't this how it works: 1. The Harvest application asks Microsoft to verify a user. 2. The user is verified by Microsoft. 3. If the user verification is successful Microsoft redirects back to the callback URL, passing back the access token inside the body of the response message. In this case hasn't the writer of the blog just created a hand-crafted URL so that the return is back to example.com rather than the actual return URL?
- meibo 3y agoMicrosoft 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.
- jussij 3y agoOk, 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.
- phatskat 3y agoNot 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/“.
- deleted 3y ago[deleted]
- belter 3y agoWorth 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 from the company page.. https://www.getharvest.com/security https://www.getharvest.com/security "...Harvest cares deeply about protecting the privacy of the data entrusted to us by our customers. This is one of the core values at the heart of our business... "
- HL33tibCe7 3y ago> All data stored on Harvest and Forecast is safe, secure, and reliable. For us, it’s the only way to do business. Lol
- 93po 3y ago"Harvest cares deeply about profiting from the illusion of the privacy around the data we harvest from customers. Profit is one of the core values at the heart of our business"
- deleted 3y ago[deleted]
- deleted 3y ago[deleted]
- jorge_leria 3y agoHey! I'm part of Harvest Security Team. We'll be changing the way we do this, but by the time this happened I triaged the report after reading it because it really looked legit. The reality is that we were never able to reproduce and there was no explicit fix. The issue stayed on Triage state and I missed the reporter updates. I talked to the author of the post and I believe we are in good terms now. The security and privacy of our customers is extremely important to us, everything we say in our security page is true and I've been working on this for years.
- driverdan 3y agoWhy wait 3 years for them to fix this? 90 days is more than enough time before disclosing it.
- mjevans 3y agoI can see longer than 90 days if there's some HUGE change required, and a decent sized team is allocated to the problem for most of their work time. OR if there's a solution but it needs to progress on a specific (and relatively short) timeline for customer notification. However that additional leeway should be afforded by the researcher and/or their lawyers / representatives. It's something a company might ask for in good faith in response to a larger than usual issue.
- nurple 3y agoThe 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.
- charles_f 3y agoAgreed, that was my thoughts as well, to the point where I even wondered if the article knew how oauth works to claim these are msft tokens
- 0xcrypto 3y agoHi, 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 open redirect in Harvest App". I am still considering to change it and open to suggestions.
- nurple 3y agoIf 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 https://datatracker.ietf.org/doc/html/rfc6749#section-10.12
- 0xcrypto 3y agoOh 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"
- tomrod 3y agoWhat a terrible response by Harvest. They're losing our business as soon as we can migrate.
- tptacek 3y agoIs Harvest an important app? Implicit-flow open redirect bugs are pretty bread-and-butter, so it's odd to see one at the top of HN. Are people reading this title as if it was a major Microsoft vulnerability?
- drawkbox 3y agoMight be misdirection PR because of the recent Okta issues which were directly at Okta. [1] Okta having lots of issues last few years. [2] [1] https://arstechnica.com/security/2023/10/okta-says-hackers-breached-its-support-system-and-viewed-customer-files/ https://arstechnica.com/security/2023/10/okta-says-hackers-b... [2] https://en.wikipedia.org/wiki/Okta,_Inc.#Security_incidents https://en.wikipedia.org/wiki/Okta,_Inc.#Security_incidents
- deleted 3y ago[deleted]
- matja 3y agoRFC 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 the malicious redirect_uri? Does the Microsoft OAuth server ignore URL parameters within a redirect_uri when comparing with registered redirect URIs for the OAuth client?
- Uvix 3y agoThe 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.
- matja 3y agoI 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.
- Uvix 3y agoAllowing 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.2 https://datatracker.ietf.org/doc/html/rfc6749#section-3.1.2....
- deleted 3y ago[deleted]
- humanlity 3y agoHow can I solve this problem cheaply? Here are a few thoughts: - Generate an encrypted token based on the redirect state value. - Store the mapping of tenant_id and unique state. - wait Microsoft support wildcard redirects.
- scurvy_steve 3y agoFirst, just don't enable implicit grant. That makes it a lot harder to screw up. State is for preventing CSRF, not transferring data. Don't abuse state, it's wrong. Use your own authorize url, add an encrypted cookie and redirect to the real one. Even if the cookie is encrypted, only put some kind of session/cache key in it, don't actually send "info". Read cookie in callback then delete it.
- humanlity 3y agoOk, I get it, Thanks
- deleted 3y ago[deleted]
- astrostl 3y agoWell, 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 goes because I didn't see other features getting cranked out either. I started getting spammed as a "user of Harvest" which prompted me to suspect that they were selling their customer lists. They took this claim extremely seriously, connecting me with company heads immediately to issue stern denials and execute a prompt investigation. That was great. What I think it came down to, though, was also engineering. I figured out a rather easy way to reliably infer active customers, which also, "went on the backlog" and remains unfixed months later. And it's a fix that appears to be super trivial. They also only offer MFA if you're signing in with Google [2]. But the app itself is DAMN good at what it does. 1: https://www.getharvest.com/about/meet-the-team https://www.getharvest.com/about/meet-the-team 2: https://support.getharvest.com/hc/en-us/articles/360052667131-Does-Harvest-offer-two-factor-authentication-2FA-or-single-sign-on-SSO-options- https://support.getharvest.com/hc/en-us/articles/36005266713...
- lukevp 3y agoI can’t tell if you love it or hate it… is this sarcastic?
- astrostl 3y agoI wouldn't say that I love or hate it. The post definitely isn't sarcastic. What part(s) need more clarity for you?
- andix 3y agoI can confirm the quality of their support. My requests were always processed by very qualified people, often within minutes. Some of my feature requests even ended up in their product. Maybe it wasn't because of me, but then they share my ideas of a good time tracker.
- jorge_leria 3y ago
- jorge_leria 3y agoHi! 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. Shortly after when we got back to the reporter for the last time, saying that we'll find a resolution, is when we were convinced that we were not able to reproduce it. Around that time we received a similar OAuth-related report. Unfortunately, this led to an internal mix-up, making us believe that we had addressed and communicated the resolution. Because of the way I have notifications set up, I missed the follow-ups, and the issue stayed in Triage state indefinitely without receiving updates. This is by no means an excuse about the lack of updates, about which I'm deeply sorry. I've been a bug bounty hunter for many years and understand how frustrating it is to wait for updates from companies. Finally, I'd like to reassure y'all that the security of our customers is of the utmost importance to us, and everything we say in our security page is true.
- foota 3y agoIt'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?
- jorge_leria 3y agoThe 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.
- polack 3y agoIt'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.
- andix 3y agoI 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.
- madeofpalk 3y agoI did not know that was possible! I would never have thought to do that, personally.
- andix 3y agoEvery oauth application needs to be registered individually, togther with a client secret or certificate. In case of Microsoft via the Azure portal. That registration can (technically) be revoked by the oauth provider. I have no idea if Microsoft would react to such a report, and what's the correct channel to submit it. But bug reports or abuse reports they usually take seriously.
- trimethylpurine 3y agoMy eyes hurt.
- 0ETH-JP 3y agoGood to know that an accident caused education or possible intent/ my life in a nutshell is wrapped around curly braces or 0eth limits of imagination. -on the other hand base2 mathematics is about as intriguing for the average person human experience or augmented reality. We had a great time deciding intent or purpose for research that didn’t start case files with day1 or private practice or contract but it wasn’t just this case of you look at the transfer of data from a computer view it’s taking the path of least interest for intent or excusable bipolar circuitry’s since ohms law was a Trending topic for engineering students.. if you see a pattern of the norm through greed or monetizing a new way to fool the next the button space bar was not just space exploration downpress.. we are greedy at nature but still to find hope of future generations box is one less hacker 1 case we see . The protocol drivers were never expected to array or say imprint to the spool of knowledge. Everybody sees the problem in our brains we are programmed to develop work arounds for habituation intention. Who wants to sue BG not me but for the fact that and understand how or why binary systems can evolve into tricking people and a entire generation regeneration cycle between our days and days leftist will lobby null hypothesis and preach a beta tester from Islamic nations is only capable to learn within there own framework and environment.. now evolution will change into something we call Ai when technology has solid proof of learning a new hobby without internet or WiFi so their brains will become more advanced by repetition of Or religion based keywords.. dao coining mining technology isn’t just a profit it’s a process and not our choice but we should be able to make it less likely to be confused or so easy to learn a “me” signal on our own time invest in American diesel repairs llc in physics of diesel technology.. this was a very important thing to live through by investing in ourselves and our communities by choosing “Integrity over compromise “ I’ve been offered a dollar worth of coin that allows the other to breach me.. and possibly affect our own people customers and there environments.. Oeth choice of truth is 110% always been teaching itself how to handle adaptation for healing a broken heart or broken soul.. in the end we will never know how I did recreate it but it wasn’t my intention.. it’s only plausible that we will now know how to handle this gift from my own experiences and loss.. talent is not all it takes it’s a way of life. Ty for examples
- inputError 3y ago[dead]
- Bvlynicole 3y ago[dead]
- Bvlynicole 3y ago[dead]