For the past several days I have been focused on understanding the inner workings of several of the popular file synchronization tools with the purpose of finding useful forensics-related artifacts that may be left on a system as a result of using these tools. Given the prevalence of Dropbox, I decided that it would be one of the first synchronization tools that I would analyze, and while working to better understand it I came across some interesting security related findings. The basis for this finding has actually been briefly discussed in a number of forum posts in Dropbox’s official forum (here and here), but it doesn’t quite seem that people understand the significance of the way Dropbox is handling authentication. So, I’m taking a brief break in my forensics-artifacts research, to try to shed some light about what appears to be going on from an authentication standpoint and the significant security implications that the present implementation of Dropbox brings to the table.
To fully understand the security implications, you need to understand how Dropbox works (for those of you that aren’t familiar with what Dropbox is – a brief feature primer can be found on their official website). Dropbox’s primary feature is the ability to sync files across systems and devices that you own, automatically. In order to support this syncing process, a client (the Dropbox client) is installed on a system that you wish to participate in this synchronization. At the end of the installation process the user is prompted to enter their Dropbox credentials (or create a new account) and then the Dropbox folder on your local system syncs up with the Dropbox “cloud.” The client runs constantly looking for new changes locally in your designated Dropbox folder and/or in the cloud and syncs as required; there are versions that support a number of operating systems (Windows, Mac, and Linux) as well as a number of portable devices (iOS, Android, etc). However, given my research is focusing on the use of Dropbox on a Windows system, the information I’ll be providing is Windows specific (but should be applicable on any platform).
Under Windows, Dropbox stores configuration data, file/directory listings, hashes, etc in a number of SQLite database files located in %APPDATA%\Dropbox. We’re going to focus on the primary database relating to the client configuration: config.db. Opening config.db with your favorite SQLite DB tool will show you that there is only one table contained in the database (config) with a number of rows, which the Dropbox client references to get its settings. I’m going to focus on the following rows of interest:
- email: this is the account holder’s email address. Surprisingly, this does not appear to be used as part of the authentication process and can be changed to any value (formatted like an email address) without any ill-effects.
- dropbox_path: defines where the root of Dropbox’s synchronized folder is on the system that the client is running on.
- host_id: assigned to the system after initial authentication is performed, post-install. Does not appear to change over time.
After some testing (modification of data within the config table, etc) it became clear that the Dropbox client uses only the host_id to authenticate. Here’s the problem: the config.db file is completely portable and is *not* tied to the system in any way. This means that if you gain access to a person’s config.db file (or just the host_id), you gain complete access to the person’s Dropbox until such time that the person removes the host from the list of linked devices via the Dropbox web interface. Taking the config.db file, copying it onto another system (you may need to modify the dropbox_path, to a valid path), and then starting the Dropbox client immediately joins that system into the synchronization group without notifying the authorized user, prompting for credentials, or even getting added to the list of linked devices within your Dropbox account (even though the new system has a completely different name) – this appears to be by design. Additionally, the host_id is still valid even after the user changes their Dropbox password (thus a standard remediation step of changing credentials does not resolve this issue).
Of course, if an attacker has access to the config.db file (assuming that it wasn’t sent by the user as part of social engineering attack), the assumption is that the attacker most likely also has access to all of the files stored in your Dropbox, so what’s the big deal? Well, there are a few significant security implications that come to mind:
- Relatively simple targeted malware could be designed with the specific purpose of exfiltrating the Dropbox config.db files to “interested” parties who then could use the host_id to retrieve files, infect files, etc.
- If the attacker/malware is detected in the system post-compromise, normal remediation steps (malware removal, system re-image, credential rotation, etc) will not prevent continued access to the user’s Dropbox. The user would have to remember to purposefully remove the system from the list of authorized devices on the Dropbox website. This means that access could be maintained without continued access/compromise of a system.
- Transmitting the host_id/config.db file is most likely much smaller than exfiltrating all data found within a Dropbox folder and thus most likely not set off any detective alarms. Review/theft/etc of the data contained within the Dropbox could be done at the attackers leisure from an external attacker-owned system.
So, given that Dropbox appears to utilize only the host_id for authentication by design, what can you do to protect yourself and/or your organization?
- Don’t use Dropbox and/or allow your users to use Dropbox. This is the obvious remediating step, but is not always practical – I do think that Dropbox can be useful, if you take steps to protect your data…
- Protect your data: use strong encryption to protect sensitive data stored in your Dropbox and protect your passphrase (do not store your passphrase in your Dropbox or on the same system/device).
- Be diligent about removing old systems from your list of authorized systems within Dropbox. Also, monitor the “Last Activity” time listed on the My Computers list within Dropbox. If you see a system checking in that shouldn’t be, unlink it immediately.
Hopefully, Dropbox will recognize the need for additional security and add in protection mechanisms that will make it less trivial to gain long-term unauthorized access to a user’s Dropbox as well as provide better means to mitigate and detect an exposure. Until such time, I’m hoping that this write-up helps brings to light how the authentication method used by Dropbox may not be as secure as previously assumed and that, as always, it is important to take steps to protect your data from compromise.
Update (10/31/2011): Dropbox has release version 1.2.48 that utilizes an encrypted local database and reportedly puts in place security enhancements to prevent theft of the machine credentials. I have not personally re-tested this release – feel free to comment if you’ve validated that the new protection mechanisms operate as described.
Remote hosting of files, be it securely over an encrypted channel or which ever it should be, my policy is to never ever trust it (despite me being a Dropbox user too).
Never trusted remote sites for taking *important* files. Normal stuff like music, should be fine. If you are paranoid of the files being modified, keep a SHA1 checksum or something more secure of checksum like SHA512, of each file in Dropbox directories.
Indeed though, it is rather insecure for the use of host id as authentication mechanism and the maintaining of host id despite changing of passwords… then what is the passwords used for anyways other than web-based authentication ?
The best for now is to use the good old username and password authentications on clients as well and not rely on host id.
Regarding mitigation/revocation after detecting a breach: has anybody checked if the new host_id generated by DropBox (after unlinking and re-linking the host in question to the DropBox account) is the same as the old host_id? Because if the client used some system fingerprint without salting it, it could well be the same. In that case we still wouldn’t keep the attacker out.
Dropbox has a list of connected devices that isn’t accurate – it’s a list of active keys.The UI needs to be fixed, because right now, it’s lying to the user.
Worse, an attacker can add themselves to my dropbox and the software does *nothing* to inform me of this.
Send me an email. Something. “A new device has connected to your Dropbox.”
The fact that Twitter does more to inform me of new followers than Dropbox does when new devices connect to my files just seems crazy, now that it’s been pointed out. Yes, it won’t solve every attack, but it prevents some of them. Do you lock your doors when you go to sleep at night? Same thing here.
The response from the Dropbox rep is way too dismissive and does not encourage trust in their approach to issues like this or their service.
Is this host__id generated based on the user’s hardware configuration + timestamp then encrypted, or is it tied to a Dropbox system-wide algorithm? If the latter, couldn’t someone figure out the generation algorithm and reverse it, making EVERYONE’S Dropbox files potentially vulnerable, without having to have physical access to anyone’s computer?
And in the End, if someone will be able to capture any of the “Dropbox-Config-Files” my System Security itself has got a big problem and all the rest of my Data is also as unsecure as Dropbox is in this Moment!
Good article, clearly pointed out the main problem of the authentication scheme dropbox is currently using.
However, may I ask you to take a look at http://root.n0xius.nl/?p=59? It’s a guy who shamelessly copied your article and implicated it was his. I hope you’re able to shut this guy down, it’s a real shame when people start plagiarising.
Ridiculous. Would you have websites use a users password as the session ID too? How about remember me authentication tokens, password there too? Using a token unrelated to a users password for authentication is a security best practice, DropBox are doing the right thing here.
Hi !
Your article lacks some informations to understand the impact of this vulnerability…
What is the format of the host_id variable ? Is it long enough or is it vulnerable to network brute force attacks ? Can it be guessed ? etc
If you assume right away that the host is severely compromised then I concur. But I think this post especially emphasizes that it is really simple to get access to you dropbox files by simply getting a file.
In particular, if you assume that from time to time dropbox client queries for the password then it should be fine for most users.
Of course this should be done @runetime by the client.
If you also assumes that the attacker has a modified version of the client this is a completely different issue.
(that he is also able to performe the same “hardware hash” on the compromised host)
🙂
Indeed. I think that is precisely what Derek is pointing out in this note.
At least on linux it is different: dropbox dbfile have a regular mask. depending on your environement these files may have universal read access. This might not be the case of your “stored files”.
Furthermore, as Derek mentioned, there are several cases where it is easy to “extract” a single file (like this db file) when you could not get everything that is stored on your dropbox account. Also attacker might be interested in getting “long term” access to those files.
Eventually this “little breach” might lead to other forms of dropbox based attacks.
🙂
It would be a problem of this daemon if the attacker would be still reading them once you have been able to remove root access from him.
There is a very basic solution for this that IT literate folks should be using anyway.
Use truecrypt to creat a virutal encrypted disk within a file , save that file to dropbox.Simples.
OK for “normal” non techies this would include more work but I’m sure dropbox could come up with some sort of addon to automate this for them?
Is there anything in place to prevent a hacker just bruteforcing random host_ids, and seeing what they find ?
There’s a lot of talk about compromising a system, but the initial post mentioned that only the host_id is required, so what’s to stop a botnet just working through host_ids on mass to pull down data ?
The assumption that an attack needs to be directed against a specific individual seems rather short-sighted.
Bruteforcing host_ids is useless, if you do the math.
Assume that Dropbox has, what, 4 million users? That’s around 2^22 (this is actually more than 4 mio, but it’s easier to work in binary like this). Now, let’s say that every single user has 4 installations (and I can assure you that that’s not the case), which means 4 host_ids, so we’re at 2^24.
You have a range of 2^256 possible host_ids. 2^24 of them are valid. Leaves 2^232.
You have a probability of 1/(2^232) to discover a valid id, that’s 1/6901746346790563787434755862277025452451108972170386555162524223799296
Now, humans are incredible bad at visualising large numbers, and even worse at working in binary. So, it’s about 6.9*10^69. (it’s more than that, but anyway..)
It is infeasible to brute force even one valid host_id today or in the foreseeable future.
Also, we need a network connection to Dropbox to check every single host_id for validity. And the EC2 infrastructure isn’t exactly fast in terms of bandwidth (S3 is silghtly better, but the S3 part of Dropbox doesn’t work with host_ids).
by changing the host_id to different random values ?
i want to ask whether dropbox allow to or more activities to be active at the same time.
Like any good authentication system consider:
1) Session management. Perhaps 15 minutes idle, 8 hours absolute should force the user to reathenticate and generate a new dropbox host id.
2) Tie auth credentials to other host information like the first three IP octets.
This does indeed impact usability, but having an auth token that is forever valid is indeed an authentication AntiPattern.
If you have particularly confidential information that you want to post on sites like dropbox, my personal suggestion is to password protect the files individually. Share the password to these files with your shared users separately, by phone or email – not via dropbox. Then, even if someone inappropriate gets access to the file, they still cannot open it or modify it. This does not stop someone from uploading an infected file to you, but using this precaution, you would never open a file that was not individually locked and thus would be protected from ever running the infected file.
I do agree with the author that this is a weird security design. At least by password changing the host_id must be updated. And Dropbox should give warning emails (at least) if two different machines are using the host_id at the same time. And it should offer a feature to protect subfolders with encryption and extra password, if user wants to give extra security.
Btw, are there any other services out there in the cloud with similar approach like Dropbox, but more secure?
We discovered this and a few other vulnerabilites in Dropbox last September and reported it through CERT.fi back in November. We do practice something called responsible disclosure, you know.
The host_id one is the least critical of the ones we found. None of the other ones requires access to the user’s filesystem (in that case you’re owned anyway, so we were not even sure if we should count that as a vulnerability), but their impact is also completely different.
It’s kinda frustrating to discover something, report it, not hear much back and now see someone else being hyped. Alas, such is life 😉
Cheers,
Manuel @ SBA Research gGmbH
As a Dropbox use in a quasi-admin role, my biggest concerns are:
1. What machines are using my hash key to sync my shared files?
2. How can I know if some of my users’ hash keys have been compromised, especially since we share different folders among different sets of users?
I would like to see an email from my Dropbox account each time a new machine starts synching with my account, not just when someone accepts a Share invitaion, and a simple set of instructions to follow if I want to take proactive steps to secure my folders, or if I suspect they have been compromised.
Good article and I really hope they will add more security layers to Dropbox authentication.
I described a plausible attack scenario from what you have found, which take use of the public Dropbox folder to transfer the file… you can find the article here:
http://www.kittybomber.com/configharvester.html
This is in no way a very efficient attack but it could be doable.