ASFWS – A critical analysis of Dropbox software security

Slides available on http://asfws12.files.wordpress.com/2012/11/dropbox-asfws-version.pdf

It was a full (or even an overfilled) room, in which several people did not find a seat, which listened to Nicolas Ruff and Florian Ledoux’s presentation. The topic is certainly appealing but the reputation of Nicolas Ruff aka newsoft (“Security researcher, hacker, blogger, serial speaker, troll herder, happy father & more” as he describes himself) is also a guarantee for an interesting and entertaining presentation. After a short introduction of their employers at EADS Innovation Works (a few hundreds of people within a holding of over 170’000 employees) we got really into the technical details on how Nicolas and his trainee Florian approached the challenge of reversing the Dropbox client as well as the communication protocol.

But first, why starting this investigation? The legend says it started due to strange broadcast packets on the LAN, sent by contractors located in the adjacent room. Furthermore, no in-depth analysis or proven record track of the Dropbox concept and protocol existed, leaving many questions open.

A first look at the client binaries across the supported OSes shows that all Linux, Mac and Windows clients use a similar binary based on Python. All PYC files (compiled Python sources) are available on the client, stored within an embedded zip in PE resources but with scrambled content. The client also includes a full Python interpreter but not quite identical to the original one as 53 files have been modified. It turns out the altered Python interpreter implements TEA encryption for the previously seen PYC files.

We now get decrypted PYC files which are still in a compiled form. But all PYC decompilers work only for files compiled with version 2.7, not for version 2.5 which is currently used by Dropbox. Never mind, instead of writing their own decompiler, Nicolas and Florian wrote two wrappers to upgrade a PYC file from Python 2.5 to 2.6 and from 2.6 to 2.7 and so be finally able to get an insight into the source code of the Dropbox client.

Compared to previous versions, the current client uses an encrypted SQLite database (with the default value / license key…) and the Windows DPAPI for storing sensitive information. A custom but robust implementation to store sensitive data is also available for MACs. From a network perspective, autoupdates of the clients are signed and they use a hard-coded list of root CAs for establishing the SSL communications.

While the SSL library wasn’t of the best in Python 2.5, Dropbox implemented their own solution based on OpenSSL and nCrypt. But this workaround also introduces security issues as both binaries are dating back to 2009, respectively 2007 and have known security vulnerabilities which may be exploitable for remote code execution. No update of nCrypt has been published since then and therefore no easy patch exists for this issue.

When sending a file via Dropbox, its content gets split into chunks of 4MB and a SHA-256 hash is calculated on it. Of all network communication between the Dropbox client and the server only one request is made over http (statistic about the user account using non sensitive data). All the remaining traffic is sent over an HTTPS connection. Note that this includes all errors and stack traces occurring on your client which are sent to Dropbox automatically.

A review of the known attacks about Dropbox start with Dropship where access to blocks based on their SHA-256 hash was possible without any authentication. This attack was successfully mitigated by enforcing user ACL checks. A second attack based presented at Usenix 2011 was also successfully mitigated with the analyzed binary.

Nicolas and Florian’s focus for attack was on the LAN sync feature, relying on port udp/17500 for discovery (via broadcast) and tcp/17500 for data exchange. Data exchange is done over TLS with client certificates as each Dropbox installation has a public and private key signed by Dropbox. Each installation (or node) can act as a server sending files or a client gathering files. The only identified issue here is that no certificate check is performed by the client while connecting to a (potentially rogue) Dropbox server.

The conclusion of the talk were positive as most identified issues in the past are fixed and the protocol and the client, aside a few flaws, are pretty robust. All aforementioned points were signaled to Dropbox which recorded the bugs and acknowledged them. On the other hand, their investigations resulted in having now software to decompile PYC files generated for Python 2.5 & 2.6 as well as a DBX decryption routine for SQLite encrypted databases.

I really encourage all interested persons to have a look at both the slides (featuring much more technical details) and their online tool repository (https://github.com/Mysterie/uncompyle2 & https://github.com/newsoft) where most of the software they wrote for this analysis is available.

After this great last presentation of the day it’s time for the traditional “apéritif” and then the departure for the evening’s event which takes place in the height of Lausanne at the Chalet Suisse. There’s nothing as good as a nice Swiss fondue and a huge dessert to have interesting discussions and exchanging experiences around the table. It’s also a great occasion to meet new people or catch up with others, such as Bruno Kerouanton which made the trip just for the evening. The bus trip back and the last drinks at the hotel were also precious moments in this kind of conferences.