[This article has an update: see below.]
This past February, at
Mobile World Congress, CEO Drew Houston mentioned that Dropbox,
the company’s file-hosting service, surpassed 100 million users, and those 100
million users upload over a billion
files to Dropbox servers each and every day. For some perspective, two years
ago, I mentioned in this article that Dropbox had 25 million
users, and just over 200 million files were added daily.
Dropbox’s success hasn’t
come without a few hiccups, which brings me to the point of
this article. It seems the crew at Dropbox has another problem
to contend with, all because of Dhiru Kholia and Przemyslaw Wegrzyn.
Looking under the bonnet
In their paper Looking inside the (Drop) box, Dhiru and
Przemyslaw get right to the point:
“We describe a method to
bypass Dropbox’s two-factor authentication and hijack Dropbox accounts.
Additionally, generic techniques to intercept SSL data using code injection
techniques and monkey patching are presented.”
Dhiru and Przemyslaw
accomplished this by reverse engineering the Dropbox client. That
may not seem like much, as reverse engineering is a common practice. What made
their effort unique was figuring out how to reverse engineer the client even
though it was an obfuscated application written in Python:
The client consisting of
a modiﬁed Python interpreter [that is] running obfuscated Python bytecode.
However, Dropbox being a proprietary platform, no source code is available for
these clients. Moreover, the API being used by the various Dropbox clients is
Reverse engineering the
Dropbox client has been tried previously, but with only partial success. Dhiru
and Przemyslaw claim they can reverse engineer several versions of the Dropbox
client software (Details). And, the implications of their
success reach beyond Dropbox. The paper hints at why:
described in this section are generic enough and also work for reversing other
frozen Python applications.”
from reverse engineering
Once the software is
unpacked, all secrets on how the application works are exposed. Initially,
Dhiru and Przemyslaw focused on the registration process, login, and Dropbox’s
“Launch Dropbox Website” feature as potential ways to hijack a victim’s Dropbox
account. Next, the two researchers determined how to:
Intercept SSL traffic from Dropbox servers
- Bypass Dropbox’s two-factor authentication
- Create an open-source Dropbox clients
The paper goes to great
lengths explaining how Dhiru and Przemyslaw successfully gained access to a
victim’s Dropbox account and files. The two also
mentioned in the paper with each new version of Dropbox, developers were able
to harden the client’s security, which in turn eliminated one or more attack
For example, Dhiru and Przemyslaw
were able to exploit the “Launch Dropbox Website” feature, but:
[W]e have observed that
the latest versions of Dropbox client do not use this tray_login mechanism (in
order to allow the user to automatically login to the website). They now rely
on heavier obfuscation and random nonces (received from the server) to generate
those auto-login URLs.
take that as a hint to update to the latest version of Dropbox whenever it
In a tip of their hats to
the Dropbox developers, Dhiru and Przemyslaw draw an interesting analogy: “We believe that the arms race between software protection
and software reverse engineering will go on. Protecting software against
reverse engineering is hard but it is definitely possible to make the process of
reverse engineering even harder.”
Dhiru and Przemyslaw also
wanted to point out that running proprietary and frozen code is not the way to
That being said, we
wonder what Dropbox aims to gain by employing such anti-reversing measures.
Most of Dropbox’s “secret sauce” is on the server side which is
already well protected. We do not believe these anti-reverse engineering
measures are beneﬁcial for Dropbox users and for Dropbox.
like to introduce a friend of mine, Jacob Williams (@MalwareJake). Jake is highly-skilled in the art of
penetration testing, and a digital forensic scientist employed by CSR Group. You may remember Jake as the guy who created DropSmack, a
rather unique way to use Dropbox. What Dhiru and Przemyslaw are claiming
is something I am not qualified to opine on. So, even before I started this
article, I asked Jake to look at the paper and let us know what he thought:
“I think the angle here
may be the DMCA/intellectual property rights one. Dropbox has gone out of their
way to obfuscate their code, hiding it from study. These researchers have
turned that on its head.
the step-by-step instructions for unpacking the Dropbox code. While the DMCA
has a security research exception, I’m certain Dropbox designed their code
obfuscation to keep others out. With this public, everyone can pilfer the
Dropbox code (and easily re-purpose it since it is Python, a scripted
One of the first things I
wondered about was how long has the digital dark side known about this?
Something else to consider: will this research lead to the creation of even
more obfuscated proprietary code, or the opposite – more accessible source
code that can be vetted as championed by Dhiru and Przemyslaw?
[Update (28 Aug 2013)]
Dropbox has contacted me and offered the following statement:
We appreciate the contributions of these researchers and everyone who helps keep Dropbox safe. However, we believe this research does not present a vulnerability in the Dropbox client. In the case outlined here, the user’s computer would first need to have been compromised in such a way that it would leave the entire computer, not just the user’s Dropbox, open to attacks across the board.
I then asked Dhiru and Przemyslaw what they thought. Here is their reply:
The statement from Dropbox is absolutely right. We have no problems with it. Reversing the Dropbox client was the main focus of our paper (the attacks are just ‘side-effects’). In order to hijack Dropbox accounts, you will need to leverage an existing vulnerability on the target user’s machine. Overall, Dropbox is just fine. There is nothing to worry about. We are still using and loving it.