Researchers Reverse
Content
Researchers reverse-engineer the Dropbox client: What it means
By Michael Kassner in IT Security, August 26, 2013, 1:15 PM PST More Email Alert RSS 6 Comments Save Facebook 40 Twitter 424 Linkedin 110
There were doubts about being able to reverse engineer heavilyobfuscated 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 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.
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?
By Michael Kassner in IT Security, August 26, 2013, 1:15 PM PST More Email Alert RSS 6 Comments Save Facebook 40 Twitter 424 Linkedin 110
There were doubts about being able to reverse engineer heavilyobfuscated 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 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.
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?
