Slashdot Mirror
Researchers Reverse-Engineer Dropbox, Cracking Heavily Obfuscated Python App
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..."
Good thing I stopped playing the game.
It's hosed now.
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
Your head of state is a corrupt weasel, I hope you're happy.
even then, all it takes is someone versed in the assembly language of the platform your application runs on, a copy of IDA pro or something similar, and a few hours of his time. I know this is a bit of a lost art in today's world of python and javascript, but it's still valid.
Better delete your dropbox-hosted /copporn
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.
They also claimed the generic techniques they used could be applied to reverse-engineer other Frozen python applications: OpenStack...
Wow, they can reverse engineer OpenStack? That's amazing - what do they use, an obscure set of commands called "wget", "git", and "tar"?
I hope your sarcasm is understood, it's a dangerous technique to use on the internet.
However, there's an interesting twist to the pcode vs. native code dichotomy, from reverse engineering standpoint, as anyone who's well versed in the brain-mangling line noise that calls itself the IOCCC will know. One of the best obfuscations is to embed an interpreter into your code, and then do all the hard work in the bytecode.
Your head of state is a corrupt weasel, I hope you're happy.
They should have written it in perl.
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.
"For every complex problem, there is a solution that is simple, neat, and wrong." -- H.L. Mencken (1880-1956) --
Why? If you're looking for the selfish angle, maybe he/they just wanted the notoriety. However, he/they might've just wanted to do a public service. Most people trust dropbox to be secure. Of course, slashdot users should all know better than to trust the 'cloud' for anything sensitive, but a way to get this info to people who would not otherwise know this is to make a splash about a successful pen-test.
Lots of guys see it as a challenge; the digital equivalent of saying 'you can't have this.' Well, challenge accepted.
Been there. Done that.
I believe it was EA that was doing that way back as part of their DRM for their Commodore 64 disk-based games. It would load the interpreter and a script, then execute the script [drawing it's fancy startup screens, checking for various bad sectors on their disk, over-writing parts of the script and interpreter, loading the game from various parts of the disk].
Sleep your way to a whiter smile...date a dentist!
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....
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.
"The true measure of a person is how they act when they know they won't get caught." - DSRilk
Use a non-compiled language, get what you deserve...
Python is compiled, if you distribute *.pyc files only.
NB: The message above might reflect my opinion right now, but not necessarily tomorrow or next year.
Yes, only with Perl would they be able to implement security through obscurity and open-source it at the same time.
-- Make America hate again!
The "trusting trust" attack that you linked already has countermeasures. One by David A. Wheeler, called diverse double compiling, involves bootstrapping the compiler using several independently developed compilers for the same language and seeing whether they ultimately produce the same binary. Of course, these countermeasures are no help for a proprietary language such as the Pascal variant used by Delphi.
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.
How do you know the machine building your CPU will not inject a backdoor in it?
Because Kevin Horton's NANDputer was built by hand out of a pile of 74HC00 (quad 2-input NAND gate) ICs on a breadboard. There isn't enough room in any single 7400 to insert a backdoor.
Hell, a breadboard full of 7400's is big enough to put in a real back door, complete with hinges.
Faster! Faster! Faster would be better!
I've always assumed that data on Dropbox wasn't very secure, which is why I was happy to find that ecryptfs works well with dropbox across multiple machines (assuming they are all running Linux). To wit:
/home/orp/e /home/orp/e
/home/orp/e, and it "magically" appears in its unencrypted form (name, content) on any other machine that was updated on Dropbox that has the encrypted partition mounted the same way. All dropbox ever sees is the encrypted stuff.
chinook: ~orp df
Filesystem 1K-blocks Used Available Use% Mounted on
/home/orp/Dropbox/e 491451392 129077764 361240528 27%
chinook: ~orp ls Dropbox/e
./
../
ECRYPTFS_FNEK_ENCRYPTED.FWZS4gY2TLKRZUavoct.ewyb3LhUsTmtMCkw6-7kc4NR3-58yIKIxSsrgk--
ECRYPTFS_FNEK_ENCRYPTED.FWZS4gY2TLKRZUavoct.ewyb3LhUsTmtMCkw9VkRKmwOO95LV0W1qwwNHk--/
ECRYPTFS_FNEK_ENCRYPTED.FWZS4gY2TLKRZUavoct.ewyb3LhUsTmtMCkwKsqUWInaV2aVwzvhw6CcW---
ECRYPTFS_FNEK_ENCRYPTED.FWZS4gY2TLKRZUavoct.ewyb3LhUsTmtMCkwOggoYf2PUQpQQmgJLHwIaU--/
ECRYPTFS_FNEK_ENCRYPTED.FWZS4gY2TLKRZUavoct.ewyb3LhUsTmtMCkwQEdvushvgMYZ2uRpeRJ9EU--
[etc]
This works with the same partition mounted across multiple machines. Save a file to
The main disadvantage to this approach is that if you are trying to access files on a non-linux machine you are hosed; Lastpass and other password managers that have file encryption functionality can give you cross-platform encryption but not with the nice filesystem access that Dropbox provides.
A squid eating dough in a polyethylene bag is fast and bulbous, got me?