Forgot your password?
typodupeerror
Python Security Software

Researchers Reverse-Engineer Dropbox, Cracking Heavily Obfuscated Python App 242

Posted by Soulskill
from the turns-out-it's-just-23,000-nested-if-statements dept.
rjmarvin writes "Two developers were able to successfully reverse-engineer Dropbox to intercept SSL traffic, bypass two-factor authentication and create open-source clients. They presented their paper, 'Looking inside the (Drop) box' (PDF) at USENIX 2013, explaining step-by-step how they were able to succeed where others failed in reverse-engineering a heavily obfuscated application written in Python. They also claimed the generic techniques they used could be applied to reverse-engineer other Frozen python applications: OpenStack, NASA, and a host of Google apps, just to name a few..."
This discussion has been archived. No new comments can be posted.

Researchers Reverse-Engineer Dropbox, Cracking Heavily Obfuscated Python App

Comments Filter:
  • by You're All Wrong (573825) on Wednesday August 28, 2013 @02:27AM (#44694179)
    Sounds remarkably like security through obscurity to me. With the predictable outcome.

    You have no right to feel secure if you only think you're secure assuming noone else examines your source code.
    http://en.wikipedia.org/wiki/Kerckhoffs%27s_principle
  • by epyT-R (613989) on Wednesday August 28, 2013 @02:36AM (#44694211)

    Lawyers have trouble understanding that law doesn't dictate the limits of curiosity, greed, mathematics, or physics. If there is sufficient incentive, it WILL be cracked. In this case, I think they wanted to demonstrate that drop box is not secure. This should be a 'duh' experience for anyone in IT worth their salt.

  • by odie5533 (989896) on Wednesday August 28, 2013 @02:44AM (#44694247)
    This sounds remarkably like security + obfuscation to me. The two are not necessarily mutually exclusive. If they had released it open source, one could argue that with more eyes reading the code they would be able to find and eliminate bugs or security issues. But this is not necessarily true. And they clearly did not want to release the software open source.
  • Waste of resources (Score:5, Insightful)

    by xenobyte (446878) on Wednesday August 28, 2013 @02:58AM (#44694289)

    Why do so many developers waste time on obfuscation and other ways of hiding the source in scripting languages?

    Using utilities like IonCube to 'protect' PHP-code will never stop the dedicated people from reverse engineering the application or re-engineering it. I've seen that countless times. It is security-through-obscurity at best and it will prevent people from both fixing bugs and re-submitting the fixed code to the developers, and finding security issues from simple code reviewing.

    If developers of competing applications needs to steal code they're really crappy developers and whatever that makes their application unique will be equally crappy and thus not a threat.

  • by epyT-R (613989) on Wednesday August 28, 2013 @02:58AM (#44694291)

    Actually, it's not dependent on whether the code is open or not. It's dependent on the design. If the design requires secret bits to stay hidden in the client, then open sourcing it would make it even more trivial to break, but with such designs, it would not matter whether it was open source or not. The huge library of cracked software out there speaks volumes to this.

  • by Anonymous Coward on Wednesday August 28, 2013 @03:24AM (#44694353)

    "Short" amount of time? Dropbox has been around for years, during which they've established themselves as the top brand in this space, even ahead of companies like Google or Microsoft.

    Only in autistic/retard world is "In 5 years someone might get around to reversing this" the same as "a waste of time".

  • by SJ (13711) on Wednesday August 28, 2013 @04:04AM (#44694449)

    Bad analogy.

    Code obfuscation is more akin to locking your door, and then hiding the key behind the pot plant.

  • Insecure by design (Score:5, Insightful)

    by nomaddamon (1783058) on Wednesday August 28, 2013 @04:19AM (#44694487)
    The point of the article wasn't to crack it, it was to show that if something sounds insecure by design, it is insecure...

    DropBox allows you to "log in" to it's website via click in the application -> no credentials required. Therefore it must either store user credentials or some other secret(s) on client side (host_id and host_int in this case).

    Any process running under privileges accessible to you can be cracked (albeit sand-boxing, in which case you need system privileges) and it can't hide data from end-user / other processes in same privilege space (albeit sand-boxing....).
    They can make it more difficult though (extracting Bluray key from windows media player will take anyone at least a few days)

    More and more big companies think they can hide data on client side and be secure. Dropbox, Windows Live (LiveConnect) and numerous others are now relying on fast exchange of nonces in addition to client-side secret storing to make it secure "enough".. But breaking the nonce handshake and authenticating in programmatic fashion will add maybe 10% more cracking/programming effort on top of the regular cracking effort.

    TLDR: If it is insecure by design, it is insecure and no amount of obfuscation will help you....
  • by black3d (1648913) on Wednesday August 28, 2013 @04:53AM (#44694577)

    A lot of the commentators in this article are mentioning "security through obscurity" as if the fact it doesn't work long-term should be some revelation to the Dropbox team, or that Dropbox has somehow dropped the ball through using this method. It's an unfair stance to take, considering that outside of hardware based platforms like TPM, *ALL* client-side software security is at best security through obscurity.

    The only news here is that Dropbox is the latest fairly major player to have their client reverse-engineered. Obfuscation is merely a means of delaying the inevitable, and for all we know it has done it's job wonderfully. Plenty of other people may have tried to reverse-engineer the code before but gave up because of the complexity of the obfuscation. The fact that an 'adversary' has dedicated sufficient time and commitment to the effort is news to be sure, but the news shouldn't be turned into "Dropbox did a bad". Anyone with any reasonable experience in IT (which I'd hope most readers here have) should know by now that there are no means to secure software on a computer which someone has control of.

  • by black3d (1648913) on Wednesday August 28, 2013 @05:07AM (#44694619)

    How is Dropbox not secure? Do you mean the client you have control of isn't secure? That's all the article is speaking of - they haven't found a way to steal your data from Dropbox unless they already have a secret from your PC.

    In order to access your account, they need the secret host_id (which is generated per device and unique to that device) and host_int from your computer (although, if they already have host_id, they can get host_int from the server - so really, they only need host_id). Presuming they have access to your computer, they can use these keys to access your account. (ie, without actually having your password). If they already have access to your computer however - well, at this stage we're splitting hairs. Any software which stores your login credentials on your own computer is at best hiding an access method through obscurity.

    The only way to avoid this is to require you to enter your password each time you want to sync your files. Same with Google Drive. Same with .. every piece of software that stores login credentials on the client. Calling DropBox "insecure" when you actually mean "as secure as any client-side auto-login software can be" is a misnomer.

  • by aaaaaaargh! (1150173) on Wednesday August 28, 2013 @06:52AM (#44694923)

    You're missing the point, which is that Dropbox did bad by obfuscating the code, because they should have made it Open Source right from the start and focus on selling their server-side hosting services. Keeping client code proprietary when it involves security and encryption of possibly confidential data is virtually always bad practise (outside the realm of embedded military applications using tamper-proof chips, perhaps).

  • Re:Python? Really? (Score:2, Insightful)

    by Gr8Apes (679165) on Wednesday August 28, 2013 @08:47AM (#44695435)

    Python and javascript are syntactically much more difficult to master than assembly language.

    That's why there are so many assembly masters as compared to script kiddies, err, Python and JS "masters"? Or were you meaning to be funny? The mods certainly were clueless. (Interesting, really?)

  • by Millennium (2451) on Wednesday August 28, 2013 @09:28AM (#44695761) Homepage

    "Always" is a strong word to use and speaks more of ideology than of reality.

    Not always.

  • Re:Python? Really? (Score:5, Insightful)

    by Anonymous Coward on Wednesday August 28, 2013 @10:02AM (#44696121)

    If there's one thing I can't stand, it's language elitism. Look, the language you choose to write your application in is completely irrelevant. Programming languages are tools to help you solve problems and, unless you're a compiler writer or theoretician, aren't really all that interesting in and of themselves. If you think you're a better programmer than someone because of the language you've chosen rather than the types of problems you're able to solve and the quality of your solutions, then you've completely missed the point.

  • by gweihir (88907) on Wednesday August 28, 2013 @12:08PM (#44697331)

    In addition, it uses Stackless Python on the _server_, not the client. Not affected by this thing at all, just some people that think word-associations make insights. Hint: They do not.

  • by Yaur (1069446) on Wednesday August 28, 2013 @12:41PM (#44697671)
    The advantage of keeping client code closed is that you can make breaking API changes much more easily. If you have an open client and an open API you are stuck with them and you need to spend a lot more time making sure that they are correct and complete. With a client based on reverse engineering you have no right to be surprised when it suddenly breaks.
  • by DigitAl56K (805623) on Wednesday August 28, 2013 @02:45PM (#44698679)

    You're missing the point, which is that Dropbox did bad by obfuscating the code, because they should have made it Open Source right from the start and focus on selling their server-side hosting services.

    Wrong.

    Sure, that's easy to say in hindsight, now that they have built an extremely well established business out of it and are the premiere brand in the space. If they had open sourced it right from the start then they would have all the client and client-server development costs on their plate, meanwhile Joe Shmoe could have come along and copied it, pointed it at his own servers, and took a substantial chunk of the business opportunity with much less investment overhead.

    In business you have to find a compromise between your ideals and reality. "Your ideals" perhaps not being the same as their ideals, either.

"Just think of a computer as hardware you can program." -- Nigel de la Tierre

Working...