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.
Thanks for this valuable piece of information. I would be truly interested in hearing about other similar services!
More tests are needed.
Why is this a problem? This is no different from password authentication, Kerberos host authentication, or SSH public key authentication, SSL authentication. If an attacker gets access to your secret or private key, your security is compromised until you revoke that credential.
There’s nothing Dropbox can to do fix this on the client side, because an attacker can just run a modified version of the software. In order for Dropbox to “fix” this on the server, they’d have to do source address verification, which would break pretty much everyone except people who have static IP addresses. Even then, IP addresses can still be spoofed given a sufficiently sophisticated attacker.
The only thing Dropbox could do is to break every device’s authentication whenever a user changes their password. That might be a good idea, or it might just discourage people from changing their passwords. I don’t know.
The correct way to fix this is by preventing malware from running on the client side in the first place. That might be why some people are so interested in secure operating systems. 🙂
Dwayne – I appreciate your comment. Here’s my thoughts:
1) Passwords can be changed (easily) and generally are when a compromise occurs. Compensating controls such as password rotation, expiration, etc help ensure that a password doesn’t stay the same forever.
2) Kerberos host authentication is tied to a specific host. Also, user auth should “ride on top of” host authentication in the case of Kerberos and ACLs should be in place to prevent a host from directly accessing your crown jewels.
3) SSH Keys should be protected by a passphrase. You have an option of being more secure, if you choose to use it… 🙂
I do completely understand where you’re coming from and yes, the problem I describe is present in any static/non-changing authentication key method. However, I wanted to explain some of the internals behind how Dropbox authenticates hosts to expose what I think to be a rather trivial attack vector for gaining unauthorized and sustained access to data, even post-remediation.
So I’ve thought a bit more about this, and I’ll add a few comments:
1) Password rotation is overrated. Most of the time, people choose similar passwords, or they write down their passwords, etc. Also, you don’t want people to have to repeatedly enter their passwords, or you just create more opportunities for their passwords to get stolen (e.g. through phishing, or through accidentally typing their passwords into an IRC window…)
2) What do you mean by “Kerberos host authentication is tied to a specific host”? There’s no such thing as a “host” when you’re dealing with crypto. There’s only “those who know some secret” and “those who don’t”. You can easily defeat Kerberos host authentication (and therefore impersonate a host) by copying the host’s /etc/krb5.keytab.
3) And the passphrase is typically stored in a keyring, or the key is stored in an ssh-agent. Either way, if you can run malware, you can steal a user’s SSH private key pretty easily. Passphrases protect the key on the disk if the attacker starts with a machine that is *off*; they’re pretty useless on a running machine (at least with current operating systems).
That said, Dropbox could periodically re-key each host (using e.g. Diffie-Hellman key negotiation) to make it more likely for cloned set of host credentials to get noticed. On the other hand, that would break people who restore their systems from a backup, or who regularly roll back virtual machine snapshots. It’s always a trade-off.
I suppose they could also try to detect when two hosts are synchronizing using the same credentials at the same time, but that would also break certain VM cases, and if they’re not careful, it would break mobile users who switch IP addresses fairly frequently.
Really, though, if your host credentials get stolen, you need to de-authorize that device through the website and re-authorize it. (I assume Dropbox provides some way of doing that, albeit manually?)
Hi Dwayne.
The point that you’re making is that any static/unchanging authentication key is basically vulnerable to this style of attack. Completely agree.
I’m by no means an expert in Kerberos, but my understanding was that it makes significant use of DNS which should provide some basic protection against simply copying the Service Principal/Host Keys…albeit, very weak protection. Thus my comment re: tied to a specific host. I could be on a completely wrong page here though… 🙂
krb5 tickets expire after a set period of time. That is what prevents someone from extracting kerberos tickets from a local machine.
No they don’t. You’re confusing user tickets with machine tickets. User tickets expire. Machine tickets don’t.
I think best solution would be to make it visible to the owner which hosts have accessed dropbox. If you see an unexpected ip has had access to your dropbox you could do something about ist. And this would be an easy solution. Just show the ips and send them once a week to the owner or so.
As for re-keying, I think key rotation would be fine on active hosts even knowing occasionally things will get out of sync and it would ask for a password again. If rolling back snapshots becomes a big enough issue you could put the shared key on a disk that doesn’t get rolled back.
I think all keys should be invalidated on password change.
Definitely the best solution I see.
This is entirely compatible with the current design though. They could even have it be optional, add a check box to the password change form that will delete all client pairings.
Doesn’t actually need to delete the pairs, just invalidate the host id in a black list.
This way, the next time the client starts it could re-prompt for password and re-establish connection without having to re-configure.
the Dropbox settings should not be restored via backup, so it wouldn’t matter if you restore the sql db file then.
If restoring the settings of Dropbox from a backup it will in many cases mess up the files stored inside the Dropbox. Because hashes of files are then not correct anymore, such things…
Kerberos has very strict use of DNS and timestamps to help with authentication. Copying a krb5.keytab from one machine to another will not do anything unless you can also alter DNS such that the forward and reverse lookups from the point of view of the KDC will now point to the new machine.
Even so, the key can be easily regenerated (equivalent to changing the password) such that the old one is useless.
Security in my opinion is not a standard but an ongoing process of validation and reassurance – the said here is my take:
1. Require keys that identify each unique software installation of the dropbox client. Each client id is tied to a validated username. (if the attacker does not know the users password whether or not hey have the file their software cannot be linked to the account)
2. Keep the user constantly informed of the machines in their ecosystem. Text/email each time a machine is added.
3. Let the user know each time executable code is synced via their dropbox. Or create a cache where files are temporarily stored before the user is sent a report and request to sync across all machines.
I am a security student
@1.: There is such a key. That is the key we are talking about here all the time.
@2.: That’s exactly the problem. Of course, noone can just add a machine to your account (except he knows the password, of course). The attackers machine cannot be distinguished from the original user’s machine, as it authorizes using the same key. For the dropbox side, it looks as if the user connected from a friend’s internet connection.
> I am a security student
I don’t know why you added that to your post. It’s not important for the matter, but it makes people think you are aware of what you are saying, while instead you show that you have not at all understood the problem.
Stop that. Thanks.
@Marian,
Thanks for the reply. As I observe from all the posts we are all trying to learn and find a solution to a real problem. If anyone had a silver bullet we would not be having this conversation. I want to learn how to think these things out like professionals such as yourself do, so that is why I add the student part, not to proclaim my wisdom but lack of 🙂
@@2. What other user specific parameters can we add to make it more secure. For example store an authentication key in any directory with a user specified name which the user enters at installation. Dropbox pings this file every x-seconds (or whatever). If it can’t find it – it is not valid.
What do you think??
That is funny. I thought about the student part in the way he described it (whether that was his original intention or not). You thought he was being pretentious, I thought he was saying “But I am no expert…”
One can only speak about what one has in his head. Sounds stupid and obvious, but it is amazing 🙂
Relax. He’s saying he’s no expert. Jeez. Stop taking a bloody *chat* on the Internet so seriously.
I wonder if an effective way around it would be to require a one time password check each time the system starts. In response, they get a session identifier tied in Dropbox’s system to the incoming IP address (or some combination of identifiable information). The Dropbox service on the system would have to periodically “phone home” with this session identifier, or use it with every sync check: if that didn’t happen in X minutes (or it did happen, but it didn’t come from the same IP address/other unique identifiers), that session identifier would be restricted from syncing.
Just as an additional thought… since your password would not be stored anywhere (you’d be required to input it on every device startup in order to get your session identifier), and someone attempting to spoof would need to not only successfully get your currently in-use session identifier from resident memory but also spoof whatever system attributes were being used to uniquely identify the system, it would likely limit your vulnerability substantially.
I guess the question would be how difficult it would be (or would it be possible) for an attacker to spoof that he’s coming from your IP address (particularly within the servers’ time limit for session ID viability) but still have the responses route correctly to him. Admittedly, not being a security expert, I don’t know the answer to that question. I’d also be curious to know if there was something better than IP address that could be used, which couldn’t be easily spoofed by the sender.
It would be slightly inconvenient for users to have to enter their username/password whenever they turned on their device (or if they ever lost connection long enough for the session ID to time out), but that’s a small inconvenience compared to the security flaw.
Don’t forget, Dropbox is mainly used for user convenience. You start asking for user passwords every time you loose your users.
It should be an option in the settings, but not the default value as it would jeopardize Dropbox as a product.
I know this is a bad security point of view, but it’s a good business point of view. That’s why Chrome won the market for example – it was easy and didn’t annoy the user.
Or they could create a Pc name/id pair that validates the machines, and each ID is only valid for that machine. If two machines with the same name log in an incident happens and the problem has to be solved.
This wouldn’t however solve it if you lost your pc due to some kind of failure and created a new pc name/id combo without invalidating the old one (this probably can’t be done automatically).
Dropbox could show a simple transparent popup whenever you log in to show who else is logged into your machine – this gives at least a small change find out more machines are online that you have or some old ones are active that should not be. Again, this would require the user to have at least basic knowledge about the system, which isn’t usually the case.
Alex and Sky both have valid points. There should be a way to make it more secure but not at the user’s expense.
It seems to me that vulnerabilities that allow attackers to read a file from a known path are normally considered relatively low-risk, so may not be patched as promptly as remote code execution issues. Also I’d guess that exploitation of such a vulnerability would be far more likely to go unnoticed since it might not produce any visible symptoms or leave any traces. (They also aren’t sexy, so security researchers probably aren’t putting as much effort into looking for them as they could.)
So, on the whole, it seems unwise to me to store unencrypted password equivalents directly on disk. No, it’s not necessarily a huge problem, but it’s not good practice.
One example: the recent Adobe Reader vulnerability. It’s already been patched for Adobe Reader 9, but won’t be patched until June in Adobe Reader X because the latter uses a sandbox so the impact is mitigated – except that the sandbox doesn’t prevent an attacker from reading files. (Actually Adobe’s security bulletin suggests that protected mode prevents the exploit from running at all, but it’s scarce on detail. Hopefully you see my point regardless of the facts of this particular case.)
Windows provides an API for storing secrets, which get silently encrypted and decrypted using your local logon password as a passphrase. Using this would mitigate the problem; at least then an attacker would need to be able to run code in order to extract the hostid, rather than just needing to be able to read a file. In a Unix environment you could, say, store the hostid with root-only permissions and use a suid executable to extract it. (Isn’t this more or less what the ssh client does to protect a user’s private key(s)?)
> (Isn’t this more or less what the ssh client does to protect a user’s private key(s)?)
No, ssh keys are just that: Keys. You can copy them around as you like.
I totaly agree with you and I’m pretty surprised that this causes quite a stir..
The host ID should be matched to a hash which is based on the machine’s hardware configuration — much like the way Microsoft does WGA for Windows etc.
If the hardware configuration score changes more than a few points, the user should be required to log in again.
And naturally, the hardware fingerprint should be built around factors that are very hard to spoof like serial numbers of devices, etc.
This is shocking, considering how many people are already hooked onto dropbox, me included. Let me check my authorized systems immediately. Thank you
@Dwayne Litzenberger is indeed right, nothing dropbox can do.
Thanks for this. I’m a (paid) DropBox user, and this worries me. Hopefully DropBox will get this fixed.
@DIALLO mamdou Bobo
Yes there is. If we have cloud based applications that do not suffer from this problem, dropbox can for sure be corrected so it does not suffer from it. Timed reauthentication, host hardware hashing and sending to the server over a ssl channel, host id rotation would be a start.
Timed reauthentication: Would that involve the Dropbox client storing your password? If so, then an attacker can just steal your password instead. If not (and you prompt the user instead) then an attacker’s malware can just mimic one of those dialog boxes, and you’ll willingly hand over your password.
Host hardware hashing is pointless. An attacker would just copy that hash as well, and provide it to the server along with your host id.
Host id rotation might help, but it would also break restoring from any kind of backup (especially e.g. VM snapshots). It would also break the case where you use Dropbox to preserve and share state across, for example,several Amazon EC2 nodes. (If it were me, I would probably add host ID rotation anyway, but I can see where some people might object to that.)
I suppose the real problem is that Dropbox is providing a misleading user interface. They present a list of “devices”, when what they’re actually providing is a list of independent sets of automatically generated credentials, which may or may not be used across multiple hosts.
@Dwayne
You’re wrong about other authentication mechanisms. Many will generate a host key or rely on an existing host certificate in addition to the credentials (private key or otherwise). There’s more to the security mechanisms you mentioned than a revokable key. With dropbox, at least for users, there is not.
@Derek
Writing about issues like this is difficult. There’s something important that you’ve missed here:
1) you haven’t specified whether you’ve brought this to dropbox’s attention; bad karma
2) you don’t offer a solution
If that’s how you roll, cool, but consider a different approach. Moreover, if dropbox wasn’t receptive to your conversations about security, it’d be worth talking about that too.
All that said, thanks for pointing this out.
Host keys/certificates *are* credentials, and if an attacker gets a copy of those, they can impersonate your host.
Personally, I’d be glad that the Dropbox client uses host-key based authentication, rather than *storing my password* (which is the alternative) which, if compromised, would allow an attacker to take full control over my account.
Seems like the ability to generate a new key from the website and update the key on the effected clients would be all that’s needed really.
Good post.
But I don’t think it’s a huge deal also as long as host_id is random enough and can’t be easily predicted. Think about SSH key authentication. If an attacker gets access to user’s computer he can steal the keys. Yes – they are often protected by passphrase, but passphrases can be cracked with sufficient time and a lot of people don’t protect SSH keys to begin with.
Perhaps a mitigating solution would be to add a passphrase to host_ids in dropbox just like we have them for SSH keys.
In general I think it’s a reasonable assumption in theory that user’s HD is secure from remote attackers so you can store keys there. In practice, story is different.
http://yampolskiy.blogspot.com
Why is the headline constructed as an attack on Dropbox? By your own admission, to get access to config.db an attacker would already have access to the user’s files.
This is like complaining that once an attacker has root, they can read your email. How is that a fault of the email daemon?
Seems like yellow journalism to me.
+1 on this.
If the hacker has access to a machine, it’s a mute point to blame Dropbox. It’s the responsibility of the owner to make sure they have a secure box.
However, there’s the argument that once in, Dropbox does give the hacker a method to spread a malicious EXEs through the shared public folders. That’s no different from a hacker breaking into a site without the owners knowledge and injecting Trojans into publicly available downloads.
It’s certainly not a “mute” point … he said it.
It may, however, be moot.
(Gah, this is a pet peeve.)
I think the bigger problem is that becoming compromised is difficult for most people to notice, and even then once compromised the instinctual response of most people to change their password doesn’t help.
I think you are forgetting that programs aren’t used by techies and security experts, they are used by the people that click “OK” on the pop up just to get rid of it.
Those people need an easy way to check on, and maintain the security of their systems/network provided by the service, and it needs to be obvious what their solution is if changing their password is not going to help.
“Yellow journalism”? Give him a break. It’s not a new vulnerability, and it’s not specific to Dropbox, but the ability to revoke access after a successful compromise is a legitimate thing to ask for.
The problem, really, is that on *Windows*, it’s fairly common for attackers to “have root” for a limited period of time. What we really need is operating systems that provide a useful sandbox, so that games with random malware don’t get access to your config.db.
You already can revoke access both from the client itself and from the web interface.
The claim “insecure by design” is a bit provocative – the worst accusation that can be made is that it’s “as insecure as the computer it’s installed on,” given that most PCs these days offer password access, file-level and even whole-disk encryption. That said, I agree it could use a bit of in-app file encryption, to prevent casual file snooping. But I’d hate to see the app become as bloated and crypto-crazy as, say, Skype.
I’d be interested in your analysis of competitor ADrive.com’s security model and apps (Java and Adobe AIR).
Can you review also Wuala?
It is advertised as one of most secure synchronization tool.
Thank you for your time 🙂
The host-id should be generated and unique for a given device ! if then the client should check if host-id and device match before syncing.
But in most of cases if the attacker have access to the device, he can nearly do whatever he want !
The problem here is that to do this you take a hash of the hardware.
If the person has access to your machine, they can get the hardware hash just as easily as the dropbox key file and you’re no better off then before.
Why wouldnt the client application (dropbox’s daemon) be the one to take the hardware hash each time it starts up and transmit that back to dropbox servers as part of the auth routine?
I would think it would be much less trivial to emulate the hardware or somehow trick/fool dropbox servers into getting the other hash.
Truly nothing would stop a determined hacker – but somebody copying a simple file – that’s pathetic,
disclaimer – dropbox user….
Have you made real test of hacking your DropBox account?
If you had no test your idea, perhaps DropBox identification use another data in combination with hostid.
If i’ll want to make same system of DropBox , i ‘ll take one data of the host and a host-id , for example mac adress as a key and result with host-id send like password to server.
and if is not correct demand of manual authentification ….
hi all,
this is arash from dropbox. we take security very seriously and I wanted to make sure our position on this research is communicated clearly.
we don’t agree with the assertion that there is a security flaw – dropbox is a perfectly safe place to store sensitive data. the article claims that an attacker would be able to gain access to a user’s dropbox account if they are able to get physical access to the user’s computer.
in reality, at the point an attacker has physical access to a computer, the security battle is already lost. the research claims dropbox is insecure because it is possible to copy authentication information straight from the user’s hard drive. in reality, this ‘flaw’ exists with any service that uses cookies for authentication (practically every web serivice 🙂 cookies are stored on your hard drive and are susceptible to all the same attacks mentioned by the research (i.e. a virus can steal your cookies and gain access to all your web services).
there are measures that can be taken to make it more difficult (though not impossible) to gain access to the authentication cookie which we’ll consider in the future. that said, dropbox isn’t any less secure than other web services and we maintain that dropbox is a perfectly safe place to store sensitive data.
-arash
yes but problem with social engineering now as @legz said on twitter ( http://twitter.com/#!/LegZ/statuses/56327024968613889 in french … ) : easy to demand on forum or another the file ‘config.db’ telling that your appli dropdox don’t work and need it …
maybe an advertising to user : “don’t share your settings file dropbox”
I am disappointed in your answer. I assume it’s because of my ignorance. However….
1. I am worried that a virus can specifically target a known file in a known location and poof, I am pwned even though there was no physical access to the computer.
2. I would think that certain security measures would be obvious, easy, and yet, here you are saying you are happy with the status quo. A) So for instance, even Facebook sends me an email when I try to use it from a new computer, you should be able to detect common times when the config file looks as though it is being used from a new computer. B) You could make it very clear from the website or the system tray exactly which PC/IP/geolocation my dropbox account has been accessed from recently. C) You could offer the user an option when changing passwords to unlink all computers to that account. D) Instead of storing a static key, you could store a time expiring key and/or use other techniques to protect from a key replay attack. E) You could offer the users the ability to NOT have the key stored and force them to login at system startup.
The difference is that I can configure my web browser to not store cookies.
I do that:
– to reduce tracking
– to mitigate risks of XSS (if I’m not always logged on every once my browser is started, XSS exploit of a webapp will be less likely to success)
Also cookies have a time limit which the web site can choose before requiring reauth. And some website use that feature.
In the DropBox auth case, there is no time limit.
Hi Arash
So I work for a company that deals with your personal Medical information.
Are you personally OK our company using dropbox to pass YOUR personal medical and finanical information using dropbox
Or do you think that it would be irresponsible and against HIPPA anbd FOI rules?
Tim
“the research claims dropbox is insecure because it is possible to copy authentication information straight from the user’s hard drive. in reality, this ‘flaw’ exists with any service that uses cookies for authentication (practically every web serivice 🙂 cookies are stored on your hard drive and are susceptible to all the same attacks mentioned by the research ”
Arash, would you agree that in most secure web services – cookies typically 1) have a session timeout, and 2) are bound to an IP during the session?
mark me with @dlitz on this one; this is not a shocking security failure, nor anything close.
It’s an architectural decision with a massive usability tradeoff; if you encrypt stuff at user layer as you take it on/off the dropbox storage service then you lose a lot of utility. Sure you _can_ do that, and feel free to do so, but it’s a bit like parachuting with a mattress tied to your feet because you’ll “hit the ground hard”; in which case, why jump in the first place?
Or you can strengthen the auth to require a password for every checkin/out, but that too has a massive usability cost.
In short: yes, make people aware how it works, but no, this is not a bug. It just comes with the turf.
Tell people that if they don’t like it, they should just avoid Dropbox.
My writeup is on Computerworld at http://goo.gl/a12RO
Security is always a trade-off with usability. You cannot consider truly secure or private anything that goes on someone elses box.
All things considered and Dropbox being one of the best UX in the market I still think ti saves time (ie install the client on a new box, do not remember the pw, just change it without having to go back to all my boxes and phone etc)
Why can’t Dropbox encrypt the data(config.db) to machine specific? say combination of system specific info based encryption key to encrypt the data — this should give a basic level security for the user.
That wouldn’t help. An attacker’s malware could just copy the machine-specific encryption key while it’s copying the config.db.
No need to store the key — basically I believe every time we can generate key with a good algorithm since system info is constant.
Then the attacker will do _that_ instead.
I’m assuming host_id is encrypted over the wire? I saw no mention of that here.
Meh. If someone has my hard drive I am not sure that I will care that they can sync my dropbox. Not sure I see the problem here either. They have great freaking product that just works.
I’ve just put together a dirty little MSF module:
https://github.com/v-p-b/MSF-Addons/blob/master/modules/post/multi/gather/dropbox.rb
I agree with Dwayne’s many comments. Barring some sort of hardware security module holding a private key, I don’t see how Dropbox can do any better here. Anything bound to an IP address (like a Kerberos key bound to a hostname) is going to be broken by NAT. Other suggestions I’ve seen are just layers of indirection.
Hey Derek,
Thanks for beginning this conversation. I’ll repeat here some of my thoughts earlier posted on twitter.
The argument here is akin to ‘if intruder gains access to your refrigerator, they’ll eat your food’. They’re *already* in your house. If an attacker gains physical access to your system, virtually no security protocol will prevent unfettered access to everything, cookies or no.
Encryption *on the box* will only slow down such access; an attacker can simply time-shift: take the system *away* & brute-force attack it elsewhere.
Physical possession means nearly 100% of the security battle has *already* been lost. Dropbox has nothing to explain here.
By ‘nearly’ I mean that one cld implement a multi-factor auth on individual files, making access v. difficult, but not impossible.
Given sufficient time+resources, anything is possible. Physical possession removes or at least loosens the ‘time’ constraint of brute-force. In practice, such an attack is too costly [risk/reward] as to be considered a realistic threat to the typical Dropbox (or Freepository) user.
@jbminn
No… I think it’s more like if an intruder gains access to your refrigerator, they’ll eat your food forever even if you move and buy a new refrigerator.
+1
This is the point people here don’t seem to get. Yes, the fact that the attacker gained physical access to your system or tricked you into giving out the config.db file is bad. However, it will take me a long, LONG time to copy, say, your 20GB dropbox repository. It takes only a few seconds to copy a file only few KBs. Once I have that, I get all the files you have stored now, as well as all the files you put there in the future, without doing anything else.
“Hey man, do you mind if I borrow your computer to check my webmail real quick? My battery just died and my wife will KILL me if I don’t tell her I’m running late.
…
Thanks for everything.”
Are you saying that trusting the storage of my ultra-secret-Ive-got-the-nuke-codez plans to someone else, on a device isn’t 100% locked down and may not always be available when I need it could be a problem? Who knew?!?!?