
Researchers reverse-engineer the Dropbox client: What it means - heyitsnick
http://www.techrepublic.com/blog/it-security/researchers-reverse-engineer-the-dropbox-client-what-it-means/
======
wladimir
How could there have been any doubts that the heavily obfuscated Python could
be reverse engineered? Me, and some others, did it quite a while ago. It
wasn't a lot of work to find the opcode mapping using frequency analysis and a
bit of reasoning (ie, mapping against known libraries). Anyone remember
dropship?
[https://en.wikipedia.org/wiki/Dropship_(software)](https://en.wikipedia.org/wiki/Dropship_\(software\))
I wonder if they're going to send a takedown request this time too.

Oh I see dropship is mentioned in the paper, great :)

In any case, interesting that they found some previously unknown security
holes this way. This again proves that security through obscurity, at least
for client software, doesn't work. When will people learn. You _can 't_ hide
anything on the client for the user, at least not for long.

~~~
randuser
Obfuscated code is surely harder to understand and work with than original
code with descriptive variable names, comments, formatting, etc. Wouldn't this
make it more difficult to find vulnerabilities?

~~~
jacquesm
It makes it just as easy for the whitehats _and_ for the blackhats so it makes
no difference. It may give some people a false sense of security that they
would have not had if they were able to look at the code.

Presumably dropbox is through its enormous distribution a very fat target and
I find it hard to believe that this published effort would be the first
instance of such an undertaking. You're average blackhat isn't going to
publish his hack but will market it for all it is worth.

Then you get pages like these:

[http://1337day.com/exploit/description/19604](http://1337day.com/exploit/description/19604)

(click 'ok')

I don't think the dropbox team obfuscates their code as a security measure,
they more likely do it to increase the depth of their moat by a little bit and
to make it a bit harder to write third party clients against their non-
published api's.

------
recuter
[http://neopythonic.blogspot.co.il/2011/06/depth-and-
breadth-...](http://neopythonic.blogspot.co.il/2011/06/depth-and-breadth-of-
python.html)

"The contrast with my visitor the next day couldn't be greater. Through a
former colleague I got an introduction to Drew Houston, co-founder and CEO of
the vastly successful start-up company Dropbox.

Python plays an important role in Dropbox's success: the Dropbox client, which
runs on Windows, Mac and Linux (!), is written in Python. This is key to the
portability: everything except the UI is cross-platform. (The UI uses a
Python-ObjC bridge on Mac, and wxPython on the other platforms.) Performance
has never been a problem -- understanding that a small number of critical
pieces were written in C, including a custom memory allocator used for a
certain type of objects whose pattern of allocation involves allocating
100,000s of them and then releasing all but a few. _Before you jump in to open
up the Dropbox distro and learn all about how it works, beware that the source
code is not included and the bytecode is obfuscated. Drew 's no fool. And he
laughs at the poor competitors who are using Java._"

Sometime after that, Drew poached Guido from Google. I remember this post. :)

~~~
captainmuon
You can use a custom memory allocator in python? I wonder if this is somehow
pluggable, or if they had to modify the interpreter.

~~~
zaphar
The dropbox guys gave a talk about this at pycon one year but I'm having
trouble finding it now. I remember thinking it involved less work than I
thought it would.

~~~
plodit
I think this is what you're looking for: [http://blip.tv/pycon-us-
videos-2009-2010-2011/pycon-2011-how...](http://blip.tv/pycon-us-
videos-2009-2010-2011/pycon-2011-how-dropbox-did-it-and-how-python-
helped-4896698)

------
groby_b
I am slightly confused as to why reverse-engineering a client allows you to
sidestep two-factor auth. That _should_ be entirely a server-side thing.

~~~
pfitzsimmons
From skimming the original paper, it seems as if you can bypass authentication
if you know certain keys that that particular dropbox client stores locally.
Of course, if you were able to access those values on the local hard-drive,
you likely already have access to the victim's hard-drive or computer. In that
case you have the victim's local copy of the dropbox folder already, there is
no need for reverse engineering.

This "weakness" is no different than the weakness of two-factor authentication
in any scenario where login is persistent. I have two-factor gmail
authentication for gmail with "remember me" set so I do not have to log in
every day. If someone steals my laptop and gets my cookies, they can log in as
me regardless of two-factor authentication, until the cookie authentication
expires.

~~~
bad_user
If somebody steals my laptop and it's still open, they still have to provide
my user password since the screen gets locked after some time of inactivity.
And reading from the hard-drive directly won't help, because I got an
encrypted hard-drive (with dmcrypt).

I did this precisely because the laptop is a single point of failure. Steal
somebody's laptop and bam, you've got access to everything important to that
person.

My Android phone is also encrypted (with a much weaker password) and I can
also remotely delete everything on it through Google Apps.

~~~
kefka
I hope you did things like disable firewire, and superglue the ram in the
slots.

And I've done something similar with my iPhone. It reverse SSHs in to my
server, and provides me a shell login. Something bad happens? I can rm -rf *
to my iPhone.

And I can do bad things :)

------
seiji
I always find reverse engineering things made by people amusing. We could
just, you know, ask someone.

It's like when a new iPhone comes out and they throw the custom silicon under
electron microscopes. It's entertaining, and I'm sure fun for the people doing
it, but fighting information wars against ourselves just seems silly.

There are large problems humans don't have answers to, but we're busy making
things then figuring out how the things we made work. Madness ensues.

~~~
objclxt
> _There are large problems humans don 't have answers to, but we're busy
> making things then figuring out how the things we made work_

Many technologies have been developed or accelerated through the need to
reverse engineer something. I would argue the techniques developed to break
the Enigma Code during WW2 had profound effects on computing generally.

Often reverse engineering a technology can also allow you to make improvements
the other party has yet to realise, catalysing new ideas and research.

Not that all this means you are necessarily wrong, although perhaps it is a
little too idealistic to hope for a world where information isn't a valuable
currency?

~~~
guiomie
I thought the enigma had been stolen from the U-571 ... ahah

~~~
eru
There's lots to the Enigma story. Yes, some have been recovered from the
enemy, but that wasn't the beginning nor the end of decrypting them.

------
naner
The "expert" analysis was a bit lame. He brings in an expert pen tester who
provides a legal opinion?!

------
lucb1e
Read the paper. They haven't actually found a way to really bypass two-factor
authentication and all other security measures. With their findings, you can
hijack an account if:

\- you feel like cracking a 256-bit random value remotely (can't locally
bruteforce it), or

\- you have filesystem access.

I'd say both are irrelevant. You can't crack 256-bit values locally, let alone
if you have to check the value remotely, and with filesystem access I imagine
you can do a whole lot more than just uploading files to someone's Dropbox.

Bypassing two-factor authentication with either of the options is possible
though, and I can see the issue, but this is by design. I don't think you want
to have to enter your credentials (username, password, second factor) every
single time you store a file or check for updates.

~~~
captainmuon
If you have filesystem (write) access, you don't have to hack Dropbox to
upload files, just put the files in the appropriate folder. And if you can
execute code, you can just remote control the UI (move the cursor, type) and
do anything the user can.

But I'm glad to hear that they found no "actual" weakness, that would enable a
hacker with only my account name, or who is on my WiFi, to access my Dropbox.

------
andrewcooke
so why does this need to be obfuscated? is it not possible to do this securely
and transparently?

~~~
diydsp
I'm not a security expert, but from a management standpoint, obfuscation
certainly /slows/ (not inhibits) the spread of homebrew Dropbox clients.
Homebrew clients have the potential to create lots of customer support
issues...

To a _conservative, lean organization_, it's better to constrain customer use
cases to known good clients than to handle fallout such as "I lost all my
data!" "What rev of client were you running?" "zAxX0r'2 m0D51c|< ph3y3Ldr.0p
0.0.69r."

That said, I could hope for Dropbox to evolve to a more open (ssh-based?)
model, though I'm not a security architect :)

------
arnehormann
Link to the presentation of the reverse-engineers:
[https://www.usenix.org/sites/default/files/conference/protec...](https://www.usenix.org/sites/default/files/conference/protected-
files/kholia_woot13_slides.pdf)

------
RachelF
Does Dropbox not use Amazon S3 as their storage engine anyway? This should
have an open API?

~~~
mcpherrinm
Dropbox does have an API,
[https://www.dropbox.com/developers](https://www.dropbox.com/developers) but
this is about reverse engineering the client which seems to use things not
here -- in particular, some authentication stuff. I haven't read in depth
about why that allowed them to bypass 2-factor auth though.

~~~
jontas
From the whitepaper
([https://github.com/kholia/dedrop/blob/master/paper/accepted/...](https://github.com/kholia/dedrop/blob/master/paper/accepted/woot13-paper1.pdf)):

> We found that two-factor authentication (as used by Dropbox) only protects
> against unauthorized access to the Dropbox’s website. The Dropbox internal
> client API does not support or use two-factor authentication!

------
ChazDazzle
[http://pastebin.com/gzF4XkBL](http://pastebin.com/gzF4XkBL)

Fun find from the source code: There's a module named "gandolf.py" which
appears to have something to do with version control.

------
unknownian
Fun fact: the GNU/Linux Dropbox client is licensed under the GPL. I don't know
if the article was referring to it though.

~~~
derobert
No it's not. The dropbox _installer_ and Nautilus hooks are released under the
GPL. But it actually downloads a proprietary binary which does most
everything.

~~~
unknownian
My mistake, sorry.

