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?

  1. 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…
  2. 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).
  3. 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.

Comments

  1. Dwayne Litzenberger says

    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. :)

    • Derek Newton says

      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.

      • Dwayne Litzenberger says

        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?)

        • Derek Newton says

          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… :)

          • Jacob says

            krb5 tickets expire after a set period of time. That is what prevents someone from extracting kerberos tickets from a local machine.

          • tom says

            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.

        • Robert Drake says

          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.

          • Noah Kantrowitz says

            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.

          • Ernie Brodeur says

            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.

          • Ben says

            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…

        • Kamil Kisiel says

          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.

        • Nicholas Karonji says

          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

          • marian says

            @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.

          • Nicholas Karonji says

            @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??

          • Ger says

            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 :)

    • Alex says

      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.

      • Alex says

        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.

        • Sky says

          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.

    • Harry Johnston says

      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)?)

      • marian says

        > (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.

    • Dan Warne says

      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.

  2. Alpha says

    @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.

    • Dwayne Litzenberger says

      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.

  3. Alex says

    @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.

    • Dwayne Litzenberger says

      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.

  4. clayg says

    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.

  5. Aleksandr Yampolskiy, Ph.D. says

    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

  6. Jack Florey says

    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.

    • Arbi Arzoumani says

      +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.

      • Lerris says

        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.

    • Dwayne Litzenberger says

      “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.

  7. Lex says

    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).

  8. bzhmaddog says

    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 !

    • mytigio says

      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.

      • sombody says

        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….

  9. Arialia says

    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 ….

  10. Arash (Dropbox) says

    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

    • Jerry says

      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.

    • Olivier says

      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.

    • Tim Dyke says

      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

    • Will Peavy says

      “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?

  11. alec muffett says

    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

  12. Rodolfo says

    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)

  13. Girish Kolari says

    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.

  14. Tonetheman says

    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.

  15. Von Welch says

    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.

  16. John Minnihan says

    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

      • Kevin Neely says

        +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.”

  17. JH says

    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?!?!?

  18. HandSolo says

    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]

    • alec muffett says

      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.

      • Heinz says

        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.

        • alec muffett says

          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.

      • HandSolo says

        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.

        • Billy Hoffman says

          +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.

        • alec muffett says

          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…

        • alec muffett says

          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.

  19. Victor Cruz says

    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.

  20. Jeffrey Goldberg says

    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.

    • Derek Newton says

      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.

    • Paul Morel says

      “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.

  21. Matt says

    A database called Dropbox.sqlite is sitting in the Dropbox/Documents folder on my iPhone. Takes about 30 seconds of device possession to get a copy, and .dump in sqlite3.

  22. Geoff Baysinger says

    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.

Trackbacks

  1. [...] Security researcher Derek Newton began looking into how how some of the file synchronisation tools operated, particularly what traces of information were left on a system as a result of using the tools. Focusing on Dropbox, the darling of cloud-hosted file synchronisation tools, Newton came across a route that potential attackers could take to gain access to a Dropbox user’s files without their authorisation, possibly without them ever realising their account was being spied upon. [...]

  2. [...] Security researcher Derek Newton began looking into how how some of the file synchronisation tools operated, particularly what traces of information were left on a system as a result of using the tools. Focusing on Dropbox, the darling of cloud-hosted file synchronisation tools, Newton came across a route that potential attackers could take to gain access to a Dropbox user’s files without their authorisation, possibly without them ever realising their account was being spied upon. [...]

  3. [...] Security researcher Derek Newton began looking into how how some of the file synchronisation tools operated, particularly what traces of information were left on a system as a result of using the tools. Focusing on Dropbox, the darling of cloud-hosted file synchronisation tools, Newton came across a route that potential attackers could take to gain access to a Dropbox user’s files without their authorisation, possibly without them ever realising their account was being spied upon. [...]

  4. Cloud Storage – Dropbox…

    “Just the facts, ma’am.” In an effort to ascertain different artifacts for various cloud storage services, the following procedures were used. A clean, unpatched Windows 7 x64, install was used wit ……

  5. [...] חקיקה חדשה בצרפת תחייב, ככל הנראה, את ספקיות השירות להמנע מלהצפין את ססמאות משתמשיהן. (ויה, ויה). כיום, חלק ניכר מאבטחת השירות מתבצעת על ידי כך שססמאות משתמשים לא נשמרות בצורה פשוטה על השרת, אלא בצורה של הצפנה חד-כיוונית: למפעיל האתר אין גישה לססמאות או יכולת לשחזר אותן, אלא רק לאפס את הססמא עבור הלקוח (קצת על איך Hash עובד). אגב, אם כבר גיבוב ססמאות, כדאי להסתכל על סיבה טובה מאוד לגבב. [...]

  6. [...] At least it is a funny coincidence that the SPIEGEL recommends a service like Dropbox, while at the same time the renowned IT magazine Heise online reports security holes in the Dropbox client discovered by the security expert Derek Newton. [...]

  7. [...] Check out Derek’s full post here. He agrees that the only remedy at this time is to encrypt the files in your Dropbox folders. I also recommend you read the discussion occurring after his post, as there’s a vibrant discussion on the topic and Derek responds to some of the more cogent remarks. In this matter, I agree with Derek entirely that Dropbox (while very convenient) is vulnerable to some trivial attack vectors. Dropbox may decide that for convenience, this design merits keeping without correction. If they should decide that, I’m OK with that since I encrypt my data anyway. This does stand as a warning though to those that don’t, that your files could be at risk and you should either avoid putting any sensitive data in Dropbox folders, or employ encryption. [...]

  8. [...] insecurity, as rare as its exploitation may be, needs to be fixed by Dropbox. You can read Derek’s article and several interesting comments on his personal website.TweetShareEnjoyed the article? [...]

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>