The root of his concern is that Dropbox is vulnerable to local attackers. There is little Dropbox could reasonably do to meaningfully change this††. The Dropbox client needs to be able to authenticate itself to the Dropbox server as the price of entry to make Dropbox work. The Dropbox client is usually always running, and is in any case often running. While it's running, anything it did to prevent attackers from stealing authenticators could be circumvented by attacking the running Dropbox process.
If you think about it, this is a problem essentially shared by Google, and your bank. It is fair to critique the application for not making it even easier to revoke access to all but your current authorized machines (in other words, to make rekeying understandable and simple). But it's a UX issue, not a fundamental security problem.
† I may not; I'm going from 'trotsky's mirror.
†† Irony, based on previous comments from me today, noted.
Well, it's a stored authentication token mechanism, which is the same as is used by many other client-side software. However, there are two possible ways to improve the authentication:
- use a second factor in the authentication, such as the MAC address of the primary NIC in the machine
- limit the time that the token is valid by getting the client to periodically get a new token from the server. This prevents two clients using the same token indefinitely without detection.
Both these would be good improvements to the security of the host_id data that Dropbox uses for authentication.
Hypothetically, dropbox could install on the system a second, isolated authentication process, which generates a keypair for that machine, and hides it somewhere with an ACL that does not allow the normal user direct access. Then, upon login, the dropbox client asks the auth process to sign a nonce to login.
This would mitigate the problem to an extent; an attacker then wouldn't be able to succeed with just the user's data, they'd need to get administrative access to extract the authentication keypair as well. It would, however, require administrative access to install the authentication agent program, unless there's a suitable blind keystore in the OS already.
I think those saying "this is a minor issue" are downplaying the problem here. Imagine your co-worker gets up for a 2 minute bathroom break (or you had 2 minutes in the boss' office alone, or at an associates house, etc) - what could you do in 2 minutes? Sure you could try to install a keylogger but this requires some knowledge, prior preparation and is susceptible to detection. You could copy off his private work but this is slow, not much you copy in 2 minutes.
Knowing this security hole, within seconds i could easily copy one small file (or upload it to crate, or just write down the machine hash or upload it to codepaste etc etc) and know i now have all his private files - for life - and not just files now but all future possible files (or at least until he changes his password; but how many people really do that regularly?).
Checking that 2 machines aren't using the same key would at least notify you that something had happened, although it may occur too late to secure your existing files.
Another option is tie the key with your IP address, and when a new IP address is detecting you need to enter in your credentials to get a new pass.
I think at least some hashing with create a unique computer stamp (username, OS version, mac address, processor hardware name, etc) would go a long way in making this more secure; it's not perfect (these things can be faked), but it certainly stops Johnny Amateur Hacker in gaining access to his friends/co-workers/bosses private files.
Even in this contrived scenario where there's an opportunistic amateur attacker with full access to your computer but only for two minutes, any changes to Dropbox client security only marginally improve your situation. I've got a USB 3.0 flash drive on my keychain that could grab about 6GB in two minutes. How much secret data you got there anyway?
And as a naive attacker, I would probably just but a $40 hardware keylogger if I wanted to steal a coworker's data.
As for tying the key to IP, it adds only some security (doesn't help in your example where your coworker likely shares the same IP) and, moreover, it's a customer support nightmare. Trust me, I tried it once. Some people have IP addresses that change very often. You can't have them re-entering a password with every request.
There should never be an expectation that your data is secure on Dropbox unless you use local encryption/decryption. Your data is sent to the dropbox server where it is encrypted by their server (according to their web site) and stored. They secure the data in transit, and then again for storage, but they have access to the keys.
There seems to be strong evidence that some checking is done before file transfer to see if the file you are syncing is already available somewhere on the server, and if so the file is not transferred, but does appear sync'd in your account. I noticed this personally when I placed the Access2007 Runtime installer into a folder and the 52MB file was nearly instantaneously flagged as synced.
Insecure authentication of an insecure system is not really a big deal. The lack of convenience for users if stronger authentication was used is probably a bigger concern.
If I have access to your local machine such that I can extract your local credential, I would easily copy all of the existing data from that machine, and could install a key logger to catch your password.
So, it's equivalent to nabbing someone's session by capturing their cookie.
Problematic, but not horrifying - unless you think we shouldn't use cookies either. Though absolutely, changing the password should invalidate the old one. Without that, theres no way to stop the use of a distributed file.
It's even less than that, as with dropbox you cannot 'capture' someones cookie using firesheep or a sniffer, as they use TLS. The only way to steal the key is by hacking into someones computer and copying it.
Dropbox is doing nothing wrong here. All computer security suffers from this issue. When your machine is compromised, security is toast and you better damn fast change all your passwords/ssh keys/...
No amount of security by obscurity will change this basic fact. The article is extremely alarmist and really doesn't tell anything new.
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 writeup helps brings to light how the authentication method used my 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.
I wrote an application that verifies that a user's license key is valid. The method I use is that I have a private key on the server that takes the host ID, serial number, username, then digitally signs the data with the private key and sends back the signature.
When the software is reading the key, it verifies the signature (with the same data as sent to the server), then verifies that the host ID in the license file matches the actual host ID from the machine. If anyone attempts to change the host ID to match their computer, then the signature becomes invalid.
Dropbox could generate a signature based on their host-ID + a calculated hardware or OS installation value, then use the signature to validate the host-id in the database plus the calculated value. If the signature is valid, then the machine must be the machine that was originally validated.
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.
Well, _my_ ssh and gpg keys are password protected;)
I agree though, there is only so much Dropbox could do. Since you can already deauth a computer, it doesn't need to be done by password resets.
I think if Dropbox detects two host_id's at the same time (not just in the same time, but both after each other in, say, double the sync period) then it should deauth the host and alert the user to what's going on.
I very much doubt dropbox is insecure by design. Skipjack was insecure by design. Dropbox is (arguably) insecure by oversight, or by lack of thoughtful security design.
The problem is that in today world people tend to be alarmist: There is rare case where data is perfectly safe or at least just an app can't make a SYSTEM secure.
Notice the upercase: it is the whole system that need to be secure. If the system is compromised, then there is nothing an app can do.
The token in cookie stored by browser is portable, either. How can web apps prevent the attackers exploiting the system from stealing the cookie token?
[+] [-] tptacek|15 years ago|reply
The root of his concern is that Dropbox is vulnerable to local attackers. There is little Dropbox could reasonably do to meaningfully change this††. The Dropbox client needs to be able to authenticate itself to the Dropbox server as the price of entry to make Dropbox work. The Dropbox client is usually always running, and is in any case often running. While it's running, anything it did to prevent attackers from stealing authenticators could be circumvented by attacking the running Dropbox process.
If you think about it, this is a problem essentially shared by Google, and your bank. It is fair to critique the application for not making it even easier to revoke access to all but your current authorized machines (in other words, to make rekeying understandable and simple). But it's a UX issue, not a fundamental security problem.
† I may not; I'm going from 'trotsky's mirror.
†† Irony, based on previous comments from me today, noted.
[+] [-] mryall|15 years ago|reply
- use a second factor in the authentication, such as the MAC address of the primary NIC in the machine
- limit the time that the token is valid by getting the client to periodically get a new token from the server. This prevents two clients using the same token indefinitely without detection.
Both these would be good improvements to the security of the host_id data that Dropbox uses for authentication.
[+] [-] bdonlan|15 years ago|reply
This would mitigate the problem to an extent; an attacker then wouldn't be able to succeed with just the user's data, they'd need to get administrative access to extract the authentication keypair as well. It would, however, require administrative access to install the authentication agent program, unless there's a suitable blind keystore in the OS already.
[+] [-] heyitsnick|15 years ago|reply
Knowing this security hole, within seconds i could easily copy one small file (or upload it to crate, or just write down the machine hash or upload it to codepaste etc etc) and know i now have all his private files - for life - and not just files now but all future possible files (or at least until he changes his password; but how many people really do that regularly?).
Checking that 2 machines aren't using the same key would at least notify you that something had happened, although it may occur too late to secure your existing files.
Another option is tie the key with your IP address, and when a new IP address is detecting you need to enter in your credentials to get a new pass.
I think at least some hashing with create a unique computer stamp (username, OS version, mac address, processor hardware name, etc) would go a long way in making this more secure; it's not perfect (these things can be faked), but it certainly stops Johnny Amateur Hacker in gaining access to his friends/co-workers/bosses private files.
[+] [-] eli|15 years ago|reply
Even in this contrived scenario where there's an opportunistic amateur attacker with full access to your computer but only for two minutes, any changes to Dropbox client security only marginally improve your situation. I've got a USB 3.0 flash drive on my keychain that could grab about 6GB in two minutes. How much secret data you got there anyway?
And as a naive attacker, I would probably just but a $40 hardware keylogger if I wanted to steal a coworker's data.
As for tying the key to IP, it adds only some security (doesn't help in your example where your coworker likely shares the same IP) and, moreover, it's a customer support nightmare. Trust me, I tried it once. Some people have IP addresses that change very often. You can't have them re-entering a password with every request.
[+] [-] bruceboughton|15 years ago|reply
[+] [-] dubious_1|15 years ago|reply
[+] [-] limmeau|15 years ago|reply
[+] [-] Groxx|15 years ago|reply
Problematic, but not horrifying - unless you think we shouldn't use cookies either. Though absolutely, changing the password should invalidate the old one. Without that, theres no way to stop the use of a distributed file.
[+] [-] wladimir|15 years ago|reply
Dropbox is doing nothing wrong here. All computer security suffers from this issue. When your machine is compromised, security is toast and you better damn fast change all your passwords/ssh keys/...
No amount of security by obscurity will change this basic fact. The article is extremely alarmist and really doesn't tell anything new.
[+] [-] tybris|15 years ago|reply
[+] [-] randall|15 years ago|reply
Improperly cached by design. :)
But seriously, anyone got a mirror? Definitely curious to read this.
[+] [-] trotsky|15 years ago|reply
You may be able to see it in all of its html glory on http://dereknewton.com.nyud.net/2011/04/dropbox-authenticati... if you wait for a considerable amount of time for something to time out.
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 writeup helps brings to light how the authentication method used my 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.
[+] [-] nbpoole|15 years ago|reply
Full (seems to be timing out): http://webcache.googleusercontent.com/search?&q=cache%3A...
Text-only: http://webcache.googleusercontent.com/search?&q=cache%3A...
[+] [-] Osiris|15 years ago|reply
When the software is reading the key, it verifies the signature (with the same data as sent to the server), then verifies that the host ID in the license file matches the actual host ID from the machine. If anyone attempts to change the host ID to match their computer, then the signature becomes invalid.
Dropbox could generate a signature based on their host-ID + a calculated hardware or OS installation value, then use the signature to validate the host-id in the database plus the calculated value. If the signature is valid, then the machine must be the machine that was originally validated.
[+] [-] jimktrains2|15 years ago|reply
[+] [-] joejohnson|15 years ago|reply
[+] [-] jimktrains2|15 years ago|reply
I agree though, there is only so much Dropbox could do. Since you can already deauth a computer, it doesn't need to be done by password resets.
I think if Dropbox detects two host_id's at the same time (not just in the same time, but both after each other in, say, double the sync period) then it should deauth the host and alert the user to what's going on.
[+] [-] netnichols|15 years ago|reply
[+] [-] kevinpet|15 years ago|reply
[+] [-] gumbo|15 years ago|reply
[+] [-] schumihan|15 years ago|reply
[+] [-] jimktrains2|15 years ago|reply
[+] [-] crocowhile|15 years ago|reply
[+] [-] tybris|15 years ago|reply
[+] [-] svag|15 years ago|reply
~/.dropbox/
[+] [-] jemond|15 years ago|reply
[+] [-] drivebyacct2|15 years ago|reply