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

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 beneﬁcial 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:

