Dropbox, the cloud-based file-sharing service, has reported that it has paid out more than $1 million to bug-bounty hunters since starting its program in 2014.
The milestone comes after the service tripled its bounties in 2017, and after running two live hacking events with the HackerOne platform.
“Additionally, charities have also benefited from our continued investment in security through bug-bounty reporters that have leveraged our donation-matching policy to donate more than $10,000 to charities around the world,” the company said.
To mark the occasion, Dropbox also revealed details on a handful of older, resolved bugs for the first time.
For instance, one of the notable issues that the company has paid out on since the program started was a shared link password bypass flaw. It was discovered by a researcher with the handle “detroitsmash,” who was awarded $10,648 for the finding and an additional $2,744 as a bonus.
The issue involved a feature for Dropbox Professional and Business users that allows them to password-protect their shared links via an option in Link Settings.
“detroitsmash reported on December 25, 2018 that one of our endpoints [servers] responsible for performing document previews in Paper documents was ignoring passwords set on shared links,” the company noted in its bug-bounty report card, issued Monday. “This would allow an attacker with a copy of a password-protected shared link to be able to bypass the password requirement and view the document.”
The issue turned out to be that additional access-control checks were missing, the company said – and a patch was immediately issued.
A more recent flaw was found during a live hacking event that the company ran with HackerOne last year (one of two that Dropbox has mounted since starting its program). Discovered by “0xacb” and “cache-money,” this CSS-injection bug was an oversight in the name validation on one of the company’s account registration servers. An attacker would have been able to exploit it by manipulating the user ID field during the sign-up process.
It earned the researchers $12,167 for their report and a $1,000 bonus for having the “Coolest Proof of Concept” out of all of the submissions.
“A chain of little issues…resulted in the ability to remotely access another user’s…documents,” according to the writeup. “All an attacker had to do was create a team, create a user with the payload as their first and last name, and then share a…document with a victim. If the victim opened their notifications, it would allow the attacker to exfiltrate the URLs of…documents present on the page.”
Specifically, the flaw existed in a bulk user import feature that allows a team administrator to give users access to shared documents on a combined scale rather than inviting them one by one to view something.
The issue arose from 0xacb’s discovery that while the individual account signup process prevents users from inserting special characters into their user IDs, the bulk user import process did not.
Then, cache-money created a user with the name <h1>First Name</h1> and shared a document with 0xacb to see what would happen; the response tipped them off that HTML injection was possible – but that cross-site scripting (XSS) was prevented by Dropbox’ use of DOMPurify, an XSS sanitizer for HTML.
The Dropbox internal security team got involved in probing the issue, and soon uncovered that DOMPurify was however allowing <style> tags in user names in the default configuration. Style tags are the HTML tags that indicate whether text should be bolded, italicized and so on.
As such, an attacker could also load in their own cascading style sheets (CSS) code into the same user-name fields. This essentially opened the door to a CSS injection attack, which is functionally similar to XSS, with the difference being that the injected code is CSS, not JavaScript.
One barrier to exploitation however was a limit on the number of characters allowed in the first and last name fields.
“Normally, an attacker can leverage CSS injection to exfiltrate sensitive tokens (like a CSRF token) from the page using selectors; however, the payload needed to perform this kind of attack usually requires hundreds of characters, not 80,” Dropbox explained. “After some brainstorming, we independently rediscovered a technique using an ‘at-rule’ in CSS called @import (originally documented by sirdarckcat) which allowed us to exfiltrate tokens from the page using just CSS and a payload that was well under the 80 character limit imposed.”
Dropbox fixed the vulnerability the day of the hackathon, it said.
“At Dropbox, we value the relationships we continue to build with the security researcher community,” the company concluded. “These…bugs discussed are just a few examples that validated the diligent work and impact of the Dropbox Security team, revealed how different risks can manifest from multiple directions, and helped make Dropbox a safer and more secure platform.”
