No encryption is impenetrable. Hackers and researchers prove it every day, cracking some highly touted security measure thought to be too complex, too fortified to ever be breached.
The latest site to fall is Dropbox, the popular file-hosting service where more than 100 million users upload more than a billion files each day. Developers Dhiru Kholia and Przemyslaw Wegrzyn reverse-engineered Dropbox, a heavily obfuscated—or deliberately unintelligible—application, written in Python.
Once successfully reverse-engineered, the researchers were capable of hijacking Dropbox to intercept SSL traffic from its servers, bypass two-factor authentication and create open-source Dropbox clients. Of course they didn’t; they’re researchers, not hackers.
They did however describe their reverse-engineering method step by step, giving anyone with enough skill the knowledge to try the same method with any of the countless other sites, programs and applications written in Python: NASA, Minecraft, Django, OpenStack and a host of Google products, to name just a few.
“We show how to unpack, decrypt and decompile Dropbox from scratch and in full detail,” they wrote in their research paper. “This paper presents new and generic techniques to reverse-engineer frozen Python applications. Once you have the de-compiled source code, it is possible to study how Dropbox works in detail.”
Kholia and Wegrzyn presented the paper, “Looking inside the (drop) box,” at USENIX 2013, explaining how they were able to best the heavily obfuscated code.
“The client consists of a modified Python interpreter [that is] running obfuscated Python bytecode,” they wrote. “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.”
Kholia and Wegrzyn have noticed, however, that Dropbox shored up many of its attack vulnerabilities with each successive update. A hole in the “Launch Dropbox Website” feature, for instance, has been patched since the researchers exploited it.
“We have observed that the latest versions of Dropbox client do not use this tray_login mechanism (in order to allow the user to automatically log in to the website),” they wrote. “They now rely on heavier obfuscation and random nonces (received from the server) to generate those auto-login URLs.”
Thus far, Dropbox has tried to keep reverse-engineering at bay with anti-reversing measures running proprietary and frozen code, but the researchers view these temporary fixes as fool’s errands. They admit the techniques they described are generic enough for reversing other frozen Python applications, and anti-reversing measures won’t stop them.
“We wonder what Dropbox aims to gain by employing such anti-reversing measures,” wrote Kholia and Wegrzyn. “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.”
The researchers reverse-engineered Dropbox for the greater good, hoping their work inspires the security community to “write an open-source Dropbox client, refine the techniques presented in this paper, and conduct research into other cloud-based storage systems.”
Yet they also liken the relationship between software security and reverse-engineering to an arms race, and one that is only escalating.
“We believe that the arms race between software protection and software reverse-engineering will go on,” they wrote. “Protecting software against reverse-engineering is hard, but it is definitely possible to make the process of reverse-engineering even harder.”
