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.
@Derek – when you reuse a key to add a new computer, does it show up as an additional computer under the “My Computers” tab on the Dropbox website?
Will –
No, at the time I tested the additional system did not show up on the list (which is in line with how Dropbox is handling their authentication). If you’re paying close attention, you’ll see that the “Last Activity” time/date stamp is updated when the new system syncs – however, the system name remains the same.
-Derek
Surely any files hosted by a 3rd party is always going to be less secure than keeping the file to yourself. We’ve seen that a lot recently, with Sony, Google, Amazon, etc having real problems – Dropbox won’t be any better. I have started to use broolz (http://www.broolz.com) for file sharing since it means my data only goes to those I want to share with. Same it is only LAN based at the moment, though I have been told they are working on a WAN version.
Tell me if I have this right: if I keep my computer very secure, but I have to share Dropbox files with a colleague who is less careful about his security, then an attacker who compromises *his* system can upload files to my Dropbox? And if I was unsuspecting, and my “colleague” dropped something that looked legit into my Dropbox (appropriately named, since an attacker could get quite a bit of personal / company info from my colleague’s files) then I could end up running a Trojan or other malware?
The analogy is a bit like locking my car keys in the safe at home, but giving my friend a copy. He leaves his set lying around, and someone who gets hold of his copy can steal my car without even breaking into my house or garage? Scary!
So maybe it’s not Dropboxe’s fault for my friend’s carelessness, but users should at least be aware of the security risks.
Encryption may be a good protection strategy, but synchronization and encryption can interact in
unexpected ways, further complicating the concerns raised about Dropbox security architecture. It turns
out that it’s very easy to LOSE ENCRYPTION of data synced by Dropbox to the online Dropbox server
location and to other PC locations.
Here’s a simple example that uses PGP Netshare on a Windows 7 system. PGP is a popular encryption tool
with a storied history (http://en.wikipedia.org/wiki/Pretty_Good_Privacy), and is now owned by Symantec.
My goal was to impose PGP encryption on ALL data in the Dropbox synced/shared folder, by using PGP’s
Netshare capability to actively maintain encryption of all data created in or copied to a designated
folder.
1) Configure PGP NetShare to keep all files in the Dropbox folder encrypted
2) Create and save a file to the Dropbox folder
3) EXIT (shutdown) PGP Services, eliminating ability to decrypt for viewing
4) View file in local/PC Dropbox folder = FAILS (file IS encrypted)
5) Download Dropbox server copy of the file and view = SUCCEEDS (file is NOT encrypted)
6. Download Dropbox server copy of the file to an entirely different PC, where no copy of PGP is
installed and view = SUCCEEDS (file is NOT encrypted).
One explanation for this behavior that has been suggested is that PGP and Dropbox MAY both be
implemented using File System Filters (http://msdn.microsoft.com/en-us/library/ff548202(v=VS.85).aspx).
The Load Order Groups for File System Filter Drivers (http://msdn.microsoft.com/en-us/library/ff548202
(v=VS.85).aspx) determine the CALLING ORDER of such filters. The default groups for Replication and
Continuous Backup load higher in the calling stack than the group for Encryption and are therefore
called earlier. This would explain why the local copy is left encrypted, the remote copy is not, AND why
Dropbox is NOT triggered to synchronize the now different files.
Taking it a bit further, this explanation is consistent with assertions that: (1) Dropox NEVER changes
files; and (2) PGP/NetShare enforces encryption AT ALL TIMES of files in the designated folder.
File System Filters make it convenient to extend File System capability, but at the cost of complex
Data-flow and added security risk. If this is what’s happening in the example, the nuance is in WHEN
Dropbox is triggered to acquire access to file data and HOW it is provided with access to that data —
Namely, slightly before encryption occurs in the file system filter calling order and through the file
system itself, which is handling the unencrypted data stream delivered from the application (Word,
Notepad or whatever) that Dropbox knows nothing about.
There apparently are workarounds (that involve managing the interaction between encryption transaction
and synchronization transaction differently), but they are not so obvious without expert insight.
I agree that remote keys should be invalidated by an owner’s password change. I would go so far to say that the failure to do so is a design flaw.
Consider the user who has been sharing files with a friend or associate and now wants to stop sharing. Isn’t changing a password the general mechanism for such a separation.
As this is a known path exploit, how about the client at the point of installation installing it in a randomised folder
%APPDATA%\Dropbox
Becomes
%APPDATA%\gHuTp328bQ\Dropbox
I’m no expert so I don’t know if that would help or not
anyway, the ability to revoke device access from the web is a must, or how about mimicking Google’s 2-step verification, where you sign up with not only a password, but also a 5 digit pin which must be entered on each new device, this pin wouldn’t be stored on the client, but instead is server-side verification
I know this is somewhat dated, but I couldn’t resist commenting, so…
I think that this –
“In reality, at the point an attacker has physical access to a computer, the security battle is already lost.”
– Is a mis-nomer at best, and blatant mis-information at worst.
Physical access is not the only way to get ahold of a computer’s files, and in the event of physical access, a protection mechanism will protect against casual theft( i.e…a laptop is stolen, the thief boots to a live disk, browses your dir structure and finds the file.). Simply because he has my computer does not mean he has access to my bank account, mortgage account, or other password protected / encrypted areas on that laptop. If my hardware is stolen, I can go to those sites and by simply changing my password, re-protect myself. Secure files, while lost, probably won’t be compromised, and I have backups (on DropBox, perhaps). If I have protected files on the system, or the system itself is encrypted, I have taken steps to mitigate my loss. If my data is so sensitive that I’m being targeted by attackers, I probably won’t be using a cloud product anyway.
According to this (and no one from DropBox has negated the issue, only said it’s a non-issue), if the file gets into the wrong hands, the shared data (my backups, perhaps) is vulnerable, with no built-in mechanisms to protect myself.
Now, we can all say encrypt this, protect that, Lysol the other, but in the end…the user wants/needs to be protected from themselves. This is not for technical people who get that defense in-depth is becoming a necessity, but for users who simply trust that the product has their best interests at heart. It’s not good or bad, just the way it is.
Long gone are the days of trusting the internet (if it ever was trusted. I know I never trusted it). Don’t even know why cloud computing exists. I know why, but it’s not the function, rather the reason, I question…It’s taking us back to dumb terminals, where all data is stored centrally. Except this time, “central” means “world”, not network, department, or company.
Using your analogy of the car…Sure, you could leave your keys on the counter and perhaps the thief will break in, take them, and steal the car…maybe he’ll miss them going after the blender, but if I am truly concerned about my car being stolen, maybe I will have LoJack, or an ignition lockout separate from my keys. Maybe I don’t care, leave the keys in the ignition, and pray that someone drives that POS ’74 pinto into the night :). Regardless, the choice is mine, and I have choices to make. It seems with this product, there are choices, but none suggested or provided by the company, and you have to be technically savvy to implement and upkeep. Imagine buying a car with no doorlocks or ignition switch, and being told not to worry, so long as your garage is secure, no one will steal your car.
Let’s not even get into the social engineering / phishing / careless collaborator scenarios.
Other institutions who house your data would never be viable with a risk such as this (brokers, banks, CC companies, etc…). This is a product I will not allow into our corporate nets. Period. We have enough file sharing / collaboration products already that do leverage corporate security mechanisms. But for Joe Public / Jane Small Business Owner, who just trusts a company because they’re a paying customer…the issues can be catastrophic, and knowledge of a breach can be days, weeks, months, (or even never) down the road.
I fully agree with time sensitive UUID’s and most other suggestions brought up here, but I think the first step in mitigation is for DropBox to realize that we the public, while not programmers, are not blind either. We need security choices built-in, and be allowed to leverage them or not. Not be told that because one piece of our technology is breached, why worry about the rest? I’m sure alot of your customers just presume that their data is fully secured, and believe that by using your product, they are taking steps to keep their data protected, while providing ease of collaboration / retrieval. You need to show them that their data security is your primary concern by helping them protect themselves from themselves, as well as others.
There is no one thing that is be all end all for anything. That’s why we have a variety of choices to perform required functions. I for one will not be using (or stealing) this Pinto so long as the mind-set presented by this company is as it is.
Thanks for reading. I won’t be purchasing your product, nor suggesting its use to anyone until security becomes more than “don’t let your system be compromised”.
i will be keeping an eye on the news to see if Dropbox is the next company to get fully compromised because of their views on security. After all…if your perimeter is breached, I’m sure all of your company data is available for use, since once 1 level of defense is broken…why bother, right?
Oh…for all of those small url’s in most of these blogs…I won’t be going to those, either…obfuscated URL’s…*shudder*.
Derek – Good work. Seems the issue isn’t what you found, but rather is it important enough to correct. 1 vote for correct it.