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.
Ugh.
Site seems to be /.'ed already. Here is another site mirroring the original blog.
Creationist Textbook Stickers Declared Unconstitutional by CowboyNeal
I guess we won't be using Dropbox at work anymore.
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.
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...
Can be found here: http://thenextweb.com/industry/2011/04/08/dropbox-security-hole-could-let-others-access-your-files/
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.
How is this different than any other service which allows you to store your password locally? Whether it's called host_id or username & password realy doesn't matter....
Note that I am all against using proprietary services like Dropbox, but I fail to see how this has any security implications. If your computer is compromised, all your credentials, saved on disk or not, are compromised anyway. Whether the file is called .netrc or .dropbox.sqlite doesn't matter that much.
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.
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
I use dropbox extensively, and I decided up front to assume that any plaintext file may as well be public (particularly since I share the account with my wife). Anything I'm not comfortable being public I keep in a truecrypt volume.
Too bad they're not using SSL encryption like other well made software is *cough*
(Embriefened or the attention span impaired)
"I have spent the last few minutes investigating the inner workings of Dropbox, and it suddenly occurred to me that if someone else gets hold of your usename and password then they could log in and download all of your files.
"And, like, your login information is all stored on your computer 'n' stuff. So this is bad, right?"
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.
What the fuck are you talking about?
If you DON'T find cloud services useful... you must have a very nice basement you enjoy spending all of your time in.
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.
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?
I now no longer feel like a paranoid weenie for using openssh and unison.
I go for option 3 for any sensitive data; I store passwords on Dropbox for example. As for encrypting the heck out of it... you make it sound like a chore. "gpg -e" and I'm done :)
With Google 2-Step auth or any online banking auth, even if you mark a machine as trusted, every so often, the machine loses that status. Perhaps machines should simply be unlinked by Dropbox every 30 days?
I know this means, once again, that Dropbox would have to make the change, but it would be a thought too.
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?
FTP uses TLS (ssl)
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.
Dropbox provides on its website under the 'Account' tab a way of listing each of the machines that you've allowed to connect to your account, giving you a way to invalidate their access, look at the time, ip address and geoip of the access, and the OS of the machine with that authentication token.
The most sinister security problem is that someone who accesses your machine without your knowledge can steal you credentials, in exactly the same manner they can steal the passwords out of your firefox, the passwords out of your email client, and install a fake root CA in your certificate stores so they can inspect all your SSL traffic and get your banking authentication details.
So it turns out that the entire computer you're using is insecure by design because an attacker can steal your credentials without your knowledge. In other news, the sky is blue and if an attacker on an unsecured street mugs you, they can take all your money and use it to buy crack.
I think this article is mostly hyperbole, but also an interesting condensation of what's wrong with security on the Internet as it stands at the moment, if your edge device is compromised, you have to do significantly more than change a password or two. You have to be vigilant in checking on websites the last locations you logged in from, to check for any patterns that would indicate an attacker accessing your accounts without your knowledge.
These kinds of one-time, per-device, invalidatable authentication tokens are useful, because you can invalidate a specific token from a web interface, as well as track it's use. Perhaps we should encourage more applications to be more like dropbox, instead of, perhaps, requiring that we store our passwords in an easy to download and open password database.
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.
Personally, I'd only ever seen dropbox used to store TV shows, movies, and warez. Which, doesn't trouble anyone too much who gets it. I didn't realize anyone would try to use it for anything secure.
Running DropBox 0.7.110 on Windows 7 32 bit. DropBox thinks its up to date.
There is no file called 'config.db' in %AppData%\Dropbox. There is a 'dropbox.db' and a 'host.db'.
The file 'dropbox.db' is a SQLite3 database, and there is a table called 'config' in it with some interesting settings.
sqlite3.exe complains about 'host.db' (Error: file is encrypted or is not a database).
Maybe the assessment is in regards to an older, less secure version ?
Just my $.02 worth . . .
I just tried this, and it works flawlessly. It was harder to install Dropbox than exploit it, considering the installer crashed on me once through (it was on Windows, ok?).
I didn't even sync the second computer to ANY account to begin with. All I did was copy the file over, start Dropbox, and bingo, it started syncing. And just to confirm the password concern, I went to the Dropbox website on the original computer and changed the password (on the original computer, so that there's no chance that Dropbox could have changed it for me as a convenience). Threw a few more files in, and away it went. Synced right up with the second computer. I never typed a single username or password on the second computer. I also deleted a couple files just to be sure.
So ya, it works. Now, for most people on /., who know not to click on "Pamela Anderson Nude.jpg.exe" that came in email, this probably isn't too big a deal, but for the users that we have to support . . . well, I had to say "STOP" four or five times to keep my boss from opening a virus that came in email -- and that was on the computer we use to do ALL of our organisation's finances. Fortunately, the antivirus program (that I keep up to date because I'm the only one who knows how) did its job and kept it from running.