Information Security Insights
Dropbox authentication: insecure by design
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.
-
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.
-
#4 written by Derek Newton 2 years ago
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?)
-
#6 written by Derek Newton 2 years ago
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…
-
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.
-
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.
-
-
-
-
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.
-
-
-
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)?)
-
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.
-
-
-
-
-
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 solutionIf 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.
-
-
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.
-
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.
-
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.
-
-
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). -
-
-
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. -
-
“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)
-
-
-
-
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
-
-
+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.”
-
-
-
It’s disheartening to see many of the comments on here follow the lines of:
“You can’t make it perfectly secure so why are you bringing this up”
Since when did highlighting issues with a product and promoting discussion warrant a deluge of this type of thinking?
By this logic why implement a firewall, since they can be defeated (often trivially). Or anti-virus – since new malware is created on a regular basis.
How about instead of saying “This isn’t an issue because:
a) The attacker already has access to ONE of your hosts
b) There isn’t a better way to do it
c) It’s too hard
d)
”We instead realize what exactly Derek is saying, which is that there are flaws in the product. Whether you see these flaws as configuration related (multiple hosts should not be able to check in with the same config.db) or UI related (all hosts syncing should show up uniquely in the UI for management purposes) – there are solutions to each problem.
The entire solution space of IT security is not limited to IPs and passwords folks – get with the times. And frankly even if it were, I’ll keep my firewall, IPS and AV solutions because defense in depth and more work for the attacker(s) is always a good thing even if its not perfect security.
Does that mean Dropbox is an unusable product and everyone should fear for their lives? Not at all, but sticking your collective heads in the sand and saying “but that’s just the way it is” is myopic at best.
[/rant mode=off]
-
Quote: “You can’t make it perfectly secure so why are you bringing this up”
Since when did highlighting issues with a product and promoting discussion warrant a deluge of this type of thinking?Well, in short because that’s the right way to think about security – least common denominator.
If it would cost me $100 to physically steal your laptop and gain access to all the data on it, then it’s not worth your spending $1000 on firewalls and anti-malware; instead you should spend $50 on _that_ and another $50 on hard-disk encryption software, the latter so that my $100 hardware theft is fruitless.
It’s economics. Thus: if someone is already in your system and in a position to steal your Dropbox credentials, you actually have much larger concerns than Dropbox itself.
-
All your comments are true in a single user static environment.
However, I participate in projects with 50+ users sharing the same folder over project times of 2 years. Today, one of these computers gets comprimised only stealing a small file. If I understand the issue correct, the forthcoming work could be observed by anyone for the coming two years outside of the project without ever producing traffic or any other hint?
“Dongleing” the dropbox authentification to a computer, I expected, is already done. There are MAC:addresses for routers etc, it could be the ProductID of Windows or whatsoever – anything which is harder to get than a small file.
-
Hi Heinz,
I used to work for a major Unix manufacturer, with the entire kernel and platform source code base shared over NFS and with change control frontended via SCCS. It was horrid, but it worked.
If you have 50 people working on a shared project and using Dropbox as a backend, I would suggest moving onto something more suited, not because of this but because of the other operational risks.
But back to my original point: 50 people, shared filestore. Of course it would be visible via Dropbox as much as if there was a Subversion checkout that was available on a malware-infested machine.
-
-
I can only assume that paying $1k+/user in AV fees is someone’s idea of a straw-man, semi-troll argument. Please omit the hyperbole if you want us to take you seriously.
Using the rationale “they’re already on ONE of your systems, therefore the world has ended” is not an excuse for poor security management in a piece of multi-system software. I use passwords on my SSH keys – why? Because even if an attacker can ultimately break the password, the more time and effort it takes him, the less likely he is to bother and/or be effective. And the more time I have to find/stop him and replace the key before he hits other hosts.
I expect no less from Dropbox.
Instead of endlessly debating about issues that are, at best, tangential (and at worst unrelated or hyperbolic), I’m going to propose three changes that I believe would make Dropbox a more secure product. These changes will cost the user nothing, other than perhaps having to re-key a password from time to time.
1) Add a per-connection unique identifier (maybe have users give their computers “names” in the Dropbox software when first installing? Users love anthromorphism!). Also add “first-added” and “last-seen” fields, and a partial hash identifier field to the management UI. Couple that with a simple button that revokes a given login hash (or all hashes) and you can now trivially detect and lock-out most attackers. Cost to user? $0. Benefit to user? Quite a bit if they are concerned about keeping their account monitored.
2) Have a per-login password prompt. This will at least keep a given hash compromise lifetime to something reasonable. You could even go so far as to have the hashes time-out after a configurable period of time if you wanted. This might be unused by many people, but many others would welcome it. Cost to user $0.
3) Utilize a UID that is non-trivially ported to another host (and not stored on disk). Environmental generation comes to mind – as long as you have the legitimate password, even an environment change is a minor issue – just regenerate the hash if something changes. Cost to user: $0.
I can already see the “but what if you get keylogged!?!??!!”. Yes I know, the world has ended. I have never claimed, nor ever will, that all problems have a technical solution. If someone takes your password outright, then you clean up, create a new account and move on.
However even in that case, having the right tools (better UI management) could help you determine that you have a persistent problem instead of being in the dark.
-
+1. Best reply I’ve seen so far.
Dropbox is using a machine independent and persistent magical ticket to access your data. The “attacker access == ticket comprise == screwed” point is a valid point, but so are all the “make the ticket harder to transfer” points.
Arash from Dropbox pretty is silly to compare the id to an HTTP session cookie because those expires. Dropbox magic tickets don’t. Can drop box change the fact they are using a magical ticket? No can they limit the damage down by a stolen ticket and made it easier to detect and stop stolen tickets. Yes. Should they? Absolutely.
-
Hi Han – I’m sure you can cope with a little hyperbole and humour, and yes it was intentional.
The point was “not spend vastly more on a solution to one problem when a different vulnerability is exploitable much more cheaply”. I think most people took that away from my comment.
You say “I use passwords on my SSH keys” because “more time and effort it takes him, the less likely he is to bother” – I understand that point, and agree; however since we’re talking about a “vulnerability” that requires an attacker to already be inside your defences, it’s fair to assume they can probably propagate out to other machines you own by the same method. Again, that’s a guess, but that’s the point – one has to be inside to exploit this.
The thing is: there is nothing they can do without compromising either usability or cost.
Regards your suggestions:
1) dropbox already does something like that. go check the control panel for “my machines”
2) the idea of dropping creds after a lifetime is attractive, until a) it goes wrong in the middle of a transaction or b) somebody forgets the password / has to put a widely used password recovery mechanism in place, leading to social engineering along the lines of http://goo.gl/phWF0
3) there is no robust UUID that is non-trivially ported across platforms. Ask any software-licensing vendor. You’re getting into the realms of trusted hardware, and that’s both specialist and pricey. This is the one I used to work with: http://goo.gl/M3SYV – see the section on the HSM. Lovely beast.
I’ve been working on problems of this sort for the past 20 years – and honestly, none of it works. How on earth (for instance) are virtualised system instances / Xen / EC2 / VMWare going to have a robust UUID? There are no concrete assumptions that can be made.
Dropbox is prettymuch on the ball with this one. They’ve made a call, and it’s a good call. If what they offer is not suitable for your / anyone’s requirement (“we want to store nuclear launch codes” – probably not a good job for Dropbox[1]) – if it’s not good for you, then don’t use it.
But don’t say that it’s bad.
[1] oops that’s hyperbole again, isn’t it? but it makes a fair point…
-
Hi Alec:
Not to get too far off topic, but regarding HSM’s… as you note they have traditionally been complicated and very expensive. However, Yubico, makers of the Yubikey USB device, have just recently announced a USB-based HSM for about $500 that they call “YubiHSM”. More about it here: http://www.yubico.com/Yubico-introduces-YubiHSM
Leo LaPorte and Steve Gibson discussed this in fairly nice detail in a recent “Security Now!” podcast. You can listen to it at: http://www.twit.tv/sn295
-
-
ps: I have one comment in moderation at the moment, but here’s an additional thought.
What if I have a couple hundred EC2 instances which I want to deploy, hands-off, using Dropbox to sync config files?
Were I to require manual setup of each one to bind it to some UUID – a concept which doesn’t really work for virtualisation, but for the sake of argument – then the whole thing would be rendered infeasible.
So: sometimes there is a good argument for being able to cut-and-paste credentials.
-
-
-
-
What a great response to this topic. Companies need to share documents outside of their corporate networks and these apps are convenient, but users have to be aware of the risks.
The Dropbox issue is an example of the problems than can come up when one is using a cloud collaboration application that wasn’t designed to meet the strictest security requirements.
The good news is that apps do exist like Brainloop that let you share files and collaborate using two-factor authentication and other security measures.
-
Mac OS X provides a keychain system exactly for storing credentials of this sort, but a quick look at my OS X keychain suggests that Dropbox is not making use of this. ~/.dropbox/config.db contains the same kind of hash-id described.
Has anyone actually tested using the host-id on a different system for which the Dropbox password was never given?
And a note to those trying to dismiss the problem because “if they can get at config.db they can already get at everything in your Dropbox folder”. The concern is that one-time, brief, non-root access to the client machine can grant long term read and write access to the person’s Dropbox data.
-
#75 written by Derek Newton 2 years ago
Hi Jeffrey,
Yes – I did test moving the config.db file (containing the host_id) from one system to a another system (actually several) and was able to get access to the associated Dropbox without any prompt for credentials (you’ll need to modify dropbox_path to point to a valid, and empty, directory before running the Dropbox client). I only tested this on Windows systems so I’d be interested in hearing if the same process worked on the other OS’s that Dropbox supports (Mac OS, Linux).
Thanks for your comment.
-
“The concern is that one-time, brief, non-root access to the client machine can grant long term read and write access to the person’s Dropbox data.”
I think this point is not made strong enough……
I am new to all the crypto issues, but….
Why couldn’t the dropbox client use the hardware key to encrypt the condig.db. Then when the client does a query to the server for syncing it check the last time it inquired, and compare itself to the previous time it inquired, if they are different then there is an false user, thus raising a flag in the client to reconfirm user credentials.
-
-
-
I would be happy with the following 3 things. Can they be circumvented? Sure. But they go a long way to making a working solution without removing the convenience of DropBox (which I don’t currently use, but have been thinking of doing).
1) When a new device is accessing my files, which has never done so before, even if it is in the config file … prompt me via email to accept the connection. Yes, I know, if they got to my local device’s files they have access to my email … which is why the next item is important.
2) Give me an easy way to audit the list of devices in my config (like Gmail’s ability to tell you all currently logged in session locations).
3) (and DropBox may already do this, don’t know) Give me an audit trail to show me which files have been accessed by which devices. That way if my host IS compromised I can see which files I need to worry about.
I’m perfectly willing to accept risk for convenience. I am confident enough in the security of my home PC that I will probably go ahead and use DropBox for what I was planning (using DropBox to share an encrypted file of my KeePass entries between my home PC and my phone … since even if DropBox was compromised the file would still be encrypted). However, I also know how clueless the vast majority of people are and the changes above would give them a better way of protecting their data.
Heck, even make the items above optional (though they should be enabled by default). Yes, this means DropBox will need some additional infrastructure, but it should be minimal.
-
- Comment Feed for this Post
Thanks for this valuable piece of information. I would be truly interested in hearing about other similar services!