What was the security vulnerability behind Box and Dropbox and what's different now?

Question

Earlier today I received a number of comments saying that my shared links were disabled. I looked around and saw a number of articles explaining what happened, and Dropbox posted an official statement

For background, whenever you click on a link in any browser, the site you’re going to learns where you came from by something called a referer header. The referer header was designed to enable websites to better understand traffic sources. This is standard practice implemented across all browsers.

Dropbox users can share links to any file or folder in their Dropbox. Files shared via links are only accessible to people who have the link. However, shared links to documents can be inadvertently disclosed to unintended recipients in the following scenario:

A Dropbox user shares a link to a document that contains a hyperlink to a third-party website.

The user, or an authorized recipient of the link, clicks on a hyperlink in the document.

At that point, the referer header discloses the original shared link to the third-party website.

Someone with access to that header, such as the webmaster of the third-party website, could then access the link to the shared document.

Personally, I am not too clear what the vulnerability is, as I've always been under the assumption that a shared link is basically a public link, since I never actually specified WHO has access to it. For example, on Google Drive I can choose who has access to it, regardless whether they have the link or not.

The next paragraph in their statement says that they have patched the vulnerability. How was this done? It looks like if someone managed to get ahold of your shared link, they're still going to have full access to it. At least, when I created new links to my shared folder, I didn't see anything different.

Answer 1

The referer header is a HTTP request header that is sent by the browser whenever you navigate to a different page - the URL of the page that contained the link you clicked is sent to the new page within this header (even if it is a different domain).

The referer isn't sent if you type in a URL, and it is not sent by most browsers if your current page is protected by TLS (https://).

This page can be used to find out if you referer is leaked to it, but this of course will depend on where you link to it from.

The Dropbox vulnerability is when a file is shared via the web and a public URL is generated. This URL is in the form https://www.example.com/s/123456qwerty/file.htm, where 123456qwerty appears to be a randomly generated token.

Normally these links only present a download link to the file, but you can modify the URL from https://www.dropbox.com/s/... to https://dl.dropbox.com/s/... which will then become https://dl.dropboxusercontent.com/s/... and would present the HTML file as being served from this domain. Also, the protocol can be changed to http which would disable the protection of the referer normally enabled by using the https protocol.

If you share this dl link with somebody, and the HTML file contains links to 3rd parties, the referer could be sent to the third party when links are clicked, exposing your private share URL with the third party. They would be able to view the referer header in their server logs or site analytics reports. This has also caused a second problem when users enter the generated links in a search engine instead of the browser's address bar, as when ads are displayed the PPC report to the advertiser shows the search term that was used, which happens to be the "private" URL to the file.

I'm not sure what the official fix is, bar the temporary deactivation of some shared links (although I haven't been notified of any disabled on my account). Computer Weekly reports:-

Dropbox has now disabled access to links that have been previously shared and implemented a patch to prevent shared links from being exposed from now on.

Possible fixes to this issue could include:

• Parsing of the page to change links such as http://www.example.com to use a service such as https://href.li so the link becomes https://href.li/?http://example.com/ (or more probably, Dropbox's implementation of such a service). This won't work with more complicated links, such as those generated or redirected by JavaScript.
• Parsing of the page to change links to use the HTML 5 noreferrer tag. This won't work with more complicated links, such as those generated or redirected by JavaScript.
• Force HTTPS for all shared HTML pages. This won't work on all browsers.
• Make HTML pages downloadable only instead of displayed inline - this could break some user setups though if they are using Dropbox as a static file server rather than simply sharing.
• An auth cookie generated when a shared link is followed by the original recipient. This would set the cookie and then redirect to a new URL. e.g. https://www.example.com/s/123456qwerty/file.htm sets the cookie then redirects to https://www.example.com/s/auth/zxcvbn76543/file.htm which is only accessible if the auth cookie is present. This would make any leaked referer data useless as the URL can only be used in combination with the cookie. This would break any bookmarking of the shared links though, unless the original link was saved manually.
• Setting a referrer-policy header to prevent the referer from being leaked in supported browsers.

You could test the final fix (whatever that may be) by this linking to a site from a shared Dropbox HTML file, checking the referer and finding out if you get the same result as the hidden version. At the moment of writing, these are still being sent by my Dropbox shared HTML page when accessed over http.

Update

The next paragraph in their statement says that they have patched the vulnerability. How was this done? It looks like if someone managed to get ahold of your shared link, they're still going to have full access to it. At least, when I created new links to my shared folder, I didn't see anything different.

Only recently have Dropbox added Passwords for Shared Links and Shared Link Expiration to their Pro accounts only.

If you’re a Dropbox Pro or Dropbox for Business user, you can set a password for any shared link that you create. This helps to ensure that only collaborators with the password can access your shared content.

If you’re a Dropbox Pro or Dropbox for Business user, you can set an expiration for any shared link that you create. This enables you to provide temporary access to content that you want to share.

These two features help resolve the vulnerability of files being accessible due to referer or PPC reports.

Update 2

As per https://www.dropbox.com/help/files-folders/public-folder:

As of September 1, 2017 public links have been disabled for all users.

Answer 2

The referer is an identifer passed in the HTTP header saying where you came from. For example, if you do a search in search engine the site you land at can determine from this field that you came from the search engine and did not type the URL directly.

Shared links are just out there, but you need to know they exist or guess them - but there is nothing really stopping you from accessing the shared link because they are designed to be open. This is security by obscurity, and not a real protection.

So when you post the link on page, and someone clicks the link, the referral information can be exposed. The referral information is not required to be passed. Using HTTPS for the links is one method to prevent sending the referer information, Google does something similar to hide specific referer details for logged on users. There are also some HTML5 and other proposals. You could also redirect all links through an exit-gateway instead of linking directly to a third party resource. e.g., if the document contains a link to http://www.somesite.com you replace the underlying link with http://www.filesharingsite.com/out.php?site=http%3A%2F%2Fwww.somesite.com then filesharingsite.com does a redirect so the referer information no longer points to the source document, but only to the exit page. On a personal level, you can use browser plugins and privacy proxies to help prevent this header information from being sent.

I am not a Dropbox user and I haven't seen them post any specific details on what methods they are using yet.

A Dropbox user shares a link to a document that contains a hyperlink to a third-party website.

What this means is that there is a Dropbox document link with a hyperlink embeded that points to another site, the referral information not only says "Dropbox" but a identifier which could be linked to a specific document id. If you have logs, you can go through the referer entries and identify these document ids, then go to the shared document which is obscured rather than hidden.

You can learn more about the discovery of the attack in the Intralink's blog (the company who made the recent public disclosure)