Security

Researchers reverse-engineer the Dropbox client: What it means

There were doubts about being able to reverse engineer heavily-obfuscated applications written in Python. Two researchers have removed all doubt by reverse engineering the immensely popular Dropbox client.
[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

Reverse_engineer_ Dropbox1.jpg
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 modified 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 not documented.

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:

“[T]he techniques described in this section are generic enough and also work for reversing other frozen Python applications.”

Fallout 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 vectors.

Reverse Dropbox2.jpg
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.

I take that as a hint to update to the latest version of Dropbox whenever it becomes available.

Mitigation

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 go:

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 beneficial for Dropbox users and for Dropbox.

Second opinion

I'd 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.

"They've documented 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 language).”

Final thoughts

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.

About

Information is my field...Writing is my passion...Coupling the two is my mission.

13 comments
Neon Samurai
Neon Samurai

"Overall, Dropbox is just fine."

Not for me. My complaint remains the use of server side encryption for user data. Spideroak and Lastpass prove that every feature Dropbox provides can be done properly in a way that does not provide Dropbox the ability to decrypt user data.

With the weekly increases in reports of government privacy invasion. Stick to Spideroak or Mega which enrypt/decrypt all data on the user's machine; the server and provider can not decrypt your data without contacting you. (and, if it's a legal matter.. the feds should have no problem contacting you directly now should they...)

glwright1262
glwright1262

In all fairness, the last two statements really ought to be placed near the beginning of the article.

erncas
erncas

It would be fair if the positive comments about Dropbox were placed at the beginning of the article...

briesmith
briesmith

The message from this, and one that requires absolutely no understanding of what was done or achieved by these obviously talented, and honest, software experts, is, put nothing of any importance on DropBox.

Pictures of baby, or Grandma, number one son scoring his first goal, menus for/from Mum, guest lists, all these sort of things, fine. But anything you want only the recipients to see you simply cannot entrust to DropBox.

There are so many collaboration solutions around that don't offer even simple security you wonder if all the words that are written about securing data have any point. No one appears to be reading them or, at least, taking any notice of them.

If you want a secure collaboration space look for applications and hosts that have UK IL2 certification or its country equivalent.

And never use auto syncing.

Michael Kassner
Michael Kassner

@glwright1262 

The update does not lessen the real issue of the Dropbox client being reverse engineered and more than likely being looked at hard by the digital underworld. 

Michael Kassner
Michael Kassner

@erncas 

The update does not change the fact that the Dropbox client was reverse engineered and now vulnerable to the whims of the bad guys.

cureerp
cureerp

@briesmith I believe both auto syncing and Dropbox are fine as long as the user is encrypting the files to be stored in DropBox.

Michael Kassner
Michael Kassner

@xadmin1 

The question is what was used to write the application? If it's Python, your application is no better off.

Neon Samurai
Neon Samurai

@Michael Kassner @glwright1262 

Yet another reason why Dropbox would be better served by open source development. These vulnerabilities would have been found much sooner significantly limiting the "how long has bad guys known" question.

Heck, the source is out now, get a developer community going. Dropbox still has the real secret sause locked away on the server side anyhow.

Michael Kassner
Michael Kassner

@cureerp @briesmith 

That is a good assumption, except when other applications use Dropbox as the file-syncing vehicle. Typically then the application breaks down. 

former33t
former33t

@Michael Kassner@xadmin1

To be fair, until these researchers completed their work, the code was more secure BECAUSE it was written in Python (albeit obfuscated).  I read assembly code like English. If it was regular compiled x86, it would actually have been easier to reverse engineer.  - Jake Williams 

Neon Samurai
Neon Samurai

@Michael Kassner @cureerp @briesmith 

That right there is my use case.

Camera syncs to dropbox but does not sync to spideroak or mega.. so photos pass through dropbox long enough to be moved into proper storage on the desktop.

todo.txt only saves/sync with dropbox currently. I'd also like to see updated to support the Mega API in addition/replacement of the dropbox API.

Scratch that first one, I recently changed the camera to sync photos back through Mega instead of dropbox.

Your point is a strong one. When what you want to use only supports what you don't want to use, you end up using what you don't want also.

Editor's Picks