Slashdot Mirror
Dropbox Authentication: Insecure By Design
An anonymous reader writes "Dropbox can be very useful, but you might be a little surprised to learn that by copying one file from a computer running the application, an attacker can access and download all of your files without any obvious signs of compromise. Normal remediation steps after a compromise such as password rotation, system re-image, etc will not prevent continued access to the compromised Dropbox. Derek Newton, a security researcher that published this finding yesterday, discusses the security implications of this by-design security authentication method on his blog."
If your local machine is accessed by an untrustworthy party and they get your shared secret/API token/whatever, they can impersonate you. ALSO: Applications store your login information locally when you request that they save your login information!!! News at eleven.
Ubuntu One is a similar service, running native on Ubuntu systems. I wonder whether that has the same built-in vulnerability.
Site seems to be /.'ed already. Here is another site mirroring the original blog.
Creationist Textbook Stickers Declared Unconstitutional by CowboyNeal
There is a significant difference between a service I find useful for embedding photos on web forums, or similar things, and one I'd store my plain text tax forms on.
"Sacrifice for the good of The State" - The State
Agreed! I upload my tax forms to Pastebin and keep my photos securely locked away.
Replying to undue accidental 'redundant' instead of 'informative'.
Doh. Also poster is right. Different data have different security requirements -- think about that for a while.
--- snip ---
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
If you're surprised by this, you're an idiot. Drop box saves your password to a file (obviously: you don't type it every time you boot). Files can be copied. By the rules of logic, then, your password can be copied. Quite simple, and not at all surprising.
A slashdotter who didn't build his own computer is like a Jedi who didn't build his own lightsaber.
This could be a big problem for me as well. In my startup, we'll continue using Dropbox as it's proven invaluable for a company of 50 spread across US, Canada, China, and Australia. But for companies that are more conservative, and especially for large firms with more to lose, this is a potential deal breaker. The way I mitigate risk for my company is to keep all sensitive documents like legal filings, tax docs, etc off of Dropbox and in another system that's less accessible.
Truecrypt works really nicely with dropbox, even if an attacker gets your Truecrypt file, they would still need the password to get the files inside of it.
Actually I find Dropbox to be very useful for things like ebooks and technical PDFs.
I can access them from my desktop, iPhone, iPad, wherever.
Trolling is a art,
... but I would never put anything on there that I wouldn't be just as happy nailing to my local telegraph pole for everybody to read. If it's in the 'cloud' then it cannot possibly be considered to be secure as somebody has physical access to the server holding my data. If I really want to put something 'personal' on DropBox, Ubuntu One or whatever, then I encrypt it, archive it with a password, then upload it as something else innocuous-looking.
Anyone who actually believes there's any level of security to something that's 'out there' then they need their head examining.
I only store encrypted data (TrueCrypt containers) in my Dropbox. I'm glad the extra work proved usefull...
Let's face it. Many times, it doesn't matter whether you or I find such sites useful. What matters is whether or not senior executives, marketing partners, or "the guy who signs the checks" finds them useful. The rest of us are just screwed until we can convince management otherwise.
I use irony whenever I can, but my shirts are still wrinkled...
I guess it's a good thing I only used Dropbox to share a bunch of images that were being deleted by other image hosts. I'd been meaning to use it for actual backups (since I don't have any real backup systems), but maybe I shouldn't. Guess I'll have to RTFA to see how bad this is.
I'm always shocked by how much load is put on a server by people not reading the article.
This isn't what I think of when I think of "insecure by design". This term is usually applied to things like DRM, where it would be impossible, or very very difficult, to fix, and would require completely redesigning how the access control system works.
In this case, dropbox writes a sqlite db after authenticating, and then doesn't check to make sure that it's valid later on. So you can alter the db file to access other people's accounts without having to re-authenticate.
It would be trivial for dropbox to update their app to at least check that the sqlite db is internally-consistent, and require re-auth if not. So there is no giant design issue preventing them from fixing this.
Actually I find Dropbox to be very useful for things like ebooks and technical PDFs.
I can access them from my desktop, iPhone, iPad, wherever.
And so can I! Thanks for putting those up there, by the way, it doesn't work if everyone leeches.
Socialism: a lie told by totalitarians and believed by fools.
Because when you change your password on other services the attacker won't continue to be able to access your account?
Pastebin is the absolutely most outstandingly wonderful idea in the world. I love pastebin.
the NPG electrode was replaced with carbon blac
Dropbox is ideal for transferring large amounts of things like photos, pdfs, artwork and in general non-sensitive information that just needs to get from person A to person B without having to rely/setup/use FTP or email.
At my last job we mostly used it to transfer/archive press releases in Word and PDF format as well as some design files so that our other departments (not always in the same building or city) could grab them easily. Nothing with sensitive information was ever stored on it.
Ave Molech Setting
Remedy for company owned computers/laptops:
Run Dropbox on an account that's not accessible by users. You can set it to run at startup via Scheduled Tasks or crontab. For added security, encrypt those db files containing the authentication keys with EFS (Windows only). The Dropbox folder will then be made accessible to authorized users via filesystem permissions. Unfortunately, this won't scale well for multiple Dropboxes per computer.
One should not use Dropbox for sensitive documents anyway, because:
1. Dropbox staff can read file names
2. They can obtain the decryption key if they really wanted. (If you can reset your password, they obviously can, too.)
If this is true, then the problem described in the article is a design flaw. Changing your credentials should block access by any box which does not have the new credentials.
Here'st he discusson in the Dropbox Support Forum http://forums.dropbox.com/topic.php?id=36146
[-- Trust the Monkey --]
"Nothing with sensitive information was ever stored on it"... That you know of. Once people start using it in a business environment they (or others that learn about it) are likely to use it for more sensitive files in a crunch. It is inevitable.
The Dropbox issue is the same as what would occur if someone stole your .ssh directory full of un-encrypted private keys.
With Dropbox, unlinking the 'machine' from your account will disable the attacker's access. With SSH, revoking access on any servers the comprimised public key had access to would do the same.
Of course, SSH allows you to encrypt your private keys (you'd have to enter a password before using them). Dropbox doesn't want to inconvenience you with password dialogs, so they just rely on obscurity. How's that for a security mindset?
They could have hashed their token with some hardware-specific values and system configuration details so that the client could force a re-keying if it found itself on a different host. Still not a solution to the hole - a hacked client could still get access, but we might not be reading this if they had taken that step.
Really, they can't close this hole without encrypting their local settings and asking users for a password when Dropbox starts up.
Dropbox users: unlink and relink your machines from your Dropbox account regularly until some future version of Dropbox starts asking you for a password on startup. You should really stop using Dropbox for anything private if other people regularly have access to your machine, or you run an OS that is virus bait...
Virus writers: You now have a nice, easy target: Dropbox settings may give you access you to gold! Or a pile of pr0n!
It is amazing to me that these proprietary storage clients don't just use SSH for their authentication and transport. Really, guys, this is a solved problem. Reinventing the wheel gets you nothing but bad press.
Someone else's computer
I'm a big fan of Dropbox.
Having said that, long before I read this, I realized that anything I put into my Dropbox folder would be visible by *OTHER PEOPLE*. After all, the data is being stored on a server that I don't own. In this day and age, anything that is out of your hands is likely to be stolen, sold or lost by whatever company you are dealing with.
Dropbox is great for storing crap that is either....
1.) Not personal (my collection of .mp3s - I don't care if the world can access them)
2.) Personal, but trivial (pictures of my home renovations....I don't care if the world can access them)
3.) Encrypted
If you want to store your important tax documents or scans of your birth certificate or whatever else; cool. Go for it. But you'd better encrypt the heck out of it.
That's a gross oversimplification. A better one-line summary is:
"If someone gets access to your Dropbox credentials, they have permanent access to your files, even if you change your password."
That last bit is what the article is about.
"They redundantly repeated themselves over and over again incessantly without end ad infinitum" -- ibid.
Also: schoolwork. If you wanna read my mathematics, then - quite frankly - I would be honored to let you!
No kitty, this is my pot pie!
TFA is surprisingly kind. This isn't "insecure by design" - this is a whopping giant security hole that you can drive a truck through, with no justification whatsoever. Surprising, since Dropbox's implementation seems to be otherwise pretty robust and well-implemented.
I certainly hope and trust that they will fix this idiocy in the next release!
Enjoy life! This is not a dress rehearsal.
My IPS sensors went berzerk today after I updated my sigs from Emergingthreats.net:
emerging-all.rules:alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"ET POLICY Dropbox.com Offsite File Backup in Use"; flow:established,to_server; uricontent:"/subscribe?host_int="; uricontent:"&ns_map="; uricontent:"&ts="; content:".dropbox.com|0d 0a|"; classtype:policy-violation; sid:2012647; rev:2;)
I was shocked how many users have this installed and running on their systems. Now I just need to convince management why I should change this rule to BLOCK. TFA and the /. comments will sure come in handy.
Kudos to the folks at ET and the community that writes these sigs. Simply amazing.
Not permanent - unlink and relink the computer, the token changes.
Seriously, Dude? I wouldn't exactly let our A/P or HR departments start storing their docs on Dropbox just yet (and you can forget about the R&D kids doing that).
Quo usque tandem abutere, Nimbus, patientia nostra?
By logging into your dropbox account through this new invention they're calling the 'world wide web', whereupon you can unlink/relink the machine from which the credentials were stolen. This renders the lost certificate useless.
With all this modern technology they reinvented FTP very very badly. It takes very special people to be able to muck things up that much and have the audacity to release such a failure on the world when a 30+ year old program does it better. I'm not saying FTP is good, it isn't (and should be replaced where possible), I'm saying these guys missed a very easy goal.
Given that the id is the only token used to get data, what in the drop box system, prevents me from iterating across the id space, until I find some really juicy data?
but you might be a little surprised to learn that
Do you know what would surprise me? If someone came along and told me "I've built an unbreakable, un-hackable, totally trustworthy system. Here's the proof. It's free. Enjoy." Anything short of that can only aspire to be amusing, but never surprising.
Perhaps I'm trolling, perhaps I'm not.
The issue isn't would you let them...if they get it in their heads that this would be easier, they very well might just do it regardless of what you say.
At least for me, the people who I worry about doing things like that are also the ones who sign my checks. There is little to nothing I could do to stop them even if I ever did find out they were using something like this. Most non-IT people don't want to care about IT security if it gets in their way.
RTFA is Known to the State of California to cause cancer.
Only if you use FTPS (or, of course, run FTP over SSH yourself--difficult because it uses so many ports--or use SFTP, which is technically unrelated but superficially similar).
R.Mo
The host_id seems to be base64 representation of 32 hex digits. I hope it's just random but if it's an MD5 hash of something related to the host PC then the real security problem will be when someone figures out what the something is.
Or at least a nice house.