Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Security The Internet IT

Dropbox Authentication: Insecure By Design 168

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."
This discussion has been archived. No new comments can be posted.

Dropbox Authentication: Insecure By Design

Comments Filter:
  • Duh? (Score:2, Informative)

    by zachriggle ( 884803 )
    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.
    • Re:Duh? (Score:5, Interesting)

      by meloneg ( 101248 ) on Friday April 08, 2011 @02:22PM (#35761712)

      But, according to the summary up there, this one survives password changes. That's really the gotcha. It sounds like they are using something similar to the SSH authentication keys. http://www.openbsd.org/cgi-bin/man.cgi?query=ssh-keygen&sektion=1 [openbsd.org]

      But, they really need to implement a way to reset the key files and force you to restart the authentication cycle.

      • I always assumed they were using an S3 backend, in which case it'd be the S3 public/secret key combination that wasn't being updated. There's an API to regenerate the key, but I know dropbox encrypts all of your files. I had always assumed that the simplest way to do that securely would be using the S3 secret key. If that's what they did, then regenerating the keys would become less trivial.
        • Re:Duh? (Score:5, Informative)

          by hoggoth ( 414195 ) on Friday April 08, 2011 @03:22PM (#35762500) Journal

          Then they did it wrong.
          Truecrypt encrypts your data with a key. This key is encrypted with ANOTHER key (your password). You can change your password and it will reencrypt the encrypted key, without having to reencrypt all of your data.

          • ... doing preciously nothing, if someone happens to have that first key... because they don't NEED your key to decrypt the data if they have that already.

        • This issue is just the host_id, which is different on every machine. Removing the machine from the list of devices on Dropbox's website will revoke access with that host_id, without affecting other machines. The password is completely separate and apparently only used for generating/retrieving a host_id.

      • by fak3r ( 917687 )
        Right, but if they did that all the keys on all your saved systems (and files?) would need the keys rotated; how would that be handled? This is an issue I'm coming across in one of my projects, and it's a similar problem.
    • Did you even RTFS?

      Once you're compromised, it's permanent, you cant change your password, you can't reformat, etc. Regardless of what they steal, changing your credentials though available means should lock them out.

      • If I steal your SSH key, and then you change your password, I can still access your box.

        The only difference here is that you're no longer in control of the effective authorized_hosts file, Dropbox is. Yes, they should regenerate the key every time you change your password.

        The article's hysteria seems to be much more about the file, rather than the fact that a password change doesn't change your API key / secret key / etc.

        • They use an SSL protocol I do believe (I do understand SSH uses SSL essentially internals, just no messy certificates).

          Your point is still perfectly applicable.

          This is why my online data is stored on a low pay-per-month server using SSH (and UNIX commands)... with sub-accounts I use for access. That way I can login as my own pseudo-root top level on a different key on a machine I consider more secure... but my netbook/etc. actively uses the sub account.

          In addition having a paper trail (credit card) with my

      • Unlink the affected computer through the Dropbox website (accounts -> My Computers -> Unlink), relink the affected computer and the token is changed, the "attacker" is locked out.
    • Did you read the article? What Dropbox does is the equivalent of authenticating using only a username -- with no password, and no way of changing your username. Once your account is compromised, it is compromised forever.

      • What Dropbox is doing is saving an authentication credential after initial authentication and reusing it - no different to a website storing a cookie that tells the website you are logged in.
      • Isn't this a fundamental flaw of WebDAV? You authenticate a user, but an authenticated user's permissions are generally cumbersome to enforce.

      • Did you read the article? Unlink the computer and re-add it if you suspect you have been compromised.

  • by josgeluk ( 842109 ) on Friday April 08, 2011 @02:10PM (#35761584) Homepage
    Ubuntu One is a similar service, running native on Ubuntu systems. I wonder whether that has the same built-in vulnerability.
    • by Dr_Barnowl ( 709838 ) on Friday April 08, 2011 @02:30PM (#35761808)

      Ubuntu One uses OAuth, which should have a sensible means of expiring tokens.

      And seeing the sibling poster - obligatory extra SPAAAAM! Ahem... U1 is currently cheaper than Dropbox, being a buck fifty per GB per year, rather than the 2 bucks per GB that Dropbox charge, and you can get extra storage in smaller increments, so if you need 60GB you'll only need to shell out $90 per year for 3x20GB packs, not $200 for the 100GB account on Dropbox. The downside is that the service isn't quite as good as Dropbox ; their Windows client is less mature than their Linux client, it doesn't AFAICT have LAN syncing, or delta compression. The upside is that you could view it as supporting something important to you, if that has value in your personal catalogue. And it's cheaper for the same volume of storage.

      • Ubuntu One uses OAuth, which should have a sensible means of expiring tokens.

        DropBox should have a sensible means of controlling access as well, but it doesn't.
        As the old adage goes: trust, but verify.

      • I really wanted to like Ubuntu One. I was even okay with the crappy windows client, but I need to use several distributions of Linux. I couldn't get it to install at all on CentOS, or other derived OS's..

  • /.'ed (Score:4, Informative)

    by just_another_sean ( 919159 ) on Friday April 08, 2011 @02:11PM (#35761600) Journal

    Site seems to be /.'ed already. Here is another site mirroring the original blog [greyhat-security.com].

    • Re:/.'ed (Score:5, Informative)

      by clang_jangle ( 975789 ) on Friday April 08, 2011 @02:30PM (#35761820) Journal
      FTFA (emphasis in bold added)

      Dropbox Insecure by Design
      / by / Mr. P / on / April 08, 2011 @ 4:54 am
      References
      Sources:
      http://dereknewton.com/2011/04/dropbox-authentication-static-host-ids/ [dereknewton.com]
      Security Engineer Derek Newton recently discovered a vulnerability in Dropbox's authentication mechanism, whilst looking for forensic traces left behind by such software. Derek discovered that in one of Dropbox's SQLite Database files, config.db, there are 3 fields contained:

      Email
      Dropbox_Path
      Host_ID


      After testing (by modification of existing fields), Derek was able to determine that the only field that affected authentication in any way, was host_id. Any other fields did not affect the way in which the machine was able to communicate or sync files with Dropbox. After some more testing, Derek was able to prove that by taking the config.db, and installing it/copying it to another machine, that he was instantly able to access/sync the existing files of that users' Dropbox. In doing so, he was not once prompted for authentication or credentials, and the user was not notified of any access to their files.

      This carries a lot of implications, as stated by Derek, as it allows Malware to quickly and quietly steal access to your files, without you knowing. It also allows malicious users to copy over a very small file in order to steal many larger files later, rather than copying over all the files at the time of theft. Malware would also be able to be persistently installed in the Dropbox files, so that when a user reformats their computer, it is simply synced and run all over again.

      A user would need to delete/revoke the affected device ID from their Dropbox after infection to prevent continued access.

      Note this requires an attacker to already have access to the config.db, i.e. one must have physical access to the machine and already be logged in as a privileged user or owner of the config.db.

      • Note this requires an attacker to already have access to the config.db, i.e. one must have physical access to the machine and already be logged in as a privileged user or owner of the config.db.

        Or have network access to the machine and a way to copy config.db off of it.

        Unlike say ... using the OS X keychain facility or the Window Protected Storage facilities for storing information in such a way that it requires authentication to get the data out.

        As a domain admin, I can pull data from any dropbox account for any user on my network just by grabbing their config.db.

        I can't change their network password without them noticing a change, which would prevent me from gaining access to their dropbox confi

        • As a domain admin, I can pull data from any dropbox account for any user on my network just by grabbing their config.db.

          I understand that, and yes it should be fixed -- but it's a far cry from being as scary as some people are making it sound. I'm glad I use rsync though. :)

      • by njvack ( 646524 )

        Note this requires an attacker to already have access to the config.db, i.e. one must have physical access to the machine and already be logged in as a privileged user or owner of the config.db.

        You don't need physical access, just the ability to run code as the logged-in user. So any number of browser driveby attacks or emailed trojans should be able to grant an attacker irrevocable access to your dropbox.

        If true, this is actually a big deal.

        • Not irrevocable. You just need to deauthorize the affected host, then readd it back again.

          • by narcc ( 412956 )

            No problem at all ... millions of iPad users who rely on dropbox are totally capable of understanding what that means.

            • Still doesn't make it "insecure by design", nor once compromised gives them irrevocable access.

              The headline, and summary are both misleading and sensationalist that are factually incorrect.

              I agree it would probably be best if after you change your password that it then asks if you want to unlink all the computers as well, with some informative box on why you may want to do so, but that is hardly the huge deal the article portrays it to be.

      • My mistake regarding the statement "one must have physical access to the machine". But one must be able to execute code on the machine as the user in question, i.e. the account would have to be already compromised.
      • Re:/.'ed (Score:5, Interesting)

        by JimFive ( 1064958 ) on Friday April 08, 2011 @03:59PM (#35762942)

        Note this requires an attacker to already have access to the config.db, i.e. one must have physical access to the machine and already be logged in as a privileged user or owner of the config.db.

        No it doesn't. It requires an attacker to create their own config.db file and guess the hostID. How long is that HostID and how is it generated?
        --
        JimFive

  • by Anonymous Coward

    --- 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 th

    • by Hatta ( 162192 )

      Dropboxâ(TM)s primary feature is the ability to sync files across systems and devices that you own, automatically.

      I use rsync for this. It can use SSH as the transport, so it should be as secure as SSH. Why would someone need to involve a third party for such a simple feature?

      • by Carik ( 205890 )

        Because most users don't have a handy server, or know how to use rsync.

        Yeah, yeah, you're a linux user and you don't care. But the average "power user" with a desktop and a laptop doesn't have a spare server in their closet, and isn't running a system that makes rsync easy. They're running Windows, and there isn't an automated system to sync the two computers. They want to just start up whichever computer they're in front of and know their files will be there. That's what Dropbox does.

      • Because they don't grok / can't be bothered / can't see the value.

        Setting up regular SSH / rsync backup is fiddly, and not even easy on Windows. Installing Dropbox is easy on every OS I've tried it on.

        Couple that with a full backup history for files (even for every version of a file), syncing between machines across the LAN (faster than uploading files via the web), and a hosted solution for backups that you don't have to administer ; it's a lot more capable than just SSH / rsync. Although obviously not as

        • by lwsimon ( 724555 )

          I use Dropbox for a lot of my vector files. It's very effective - versioning is dead easy, it syncs instantly across three notebooks, a desktop, and my iPhone, and I don't have to think about it.

          That said, when I needed to store some financial documents there, I put them inside a Truecrypt archive. Even assuming Dropbox is 100% safe end-to-end, there are still multiple ends to deal with here, one or more of which is outside my physical control at just about all times.

      • by npsimons ( 32752 ) *

        I use rsync for this. It can use SSH as the transport, so it should be as secure as SSH. Why would someone need to involve a third party for such a simple feature?

        Because they are lazy, ignorant, or just too distracted by teh shiny. A friend of mine (a Mac user) tried to convince me to use dropbox, and was flabbergasted when I told him I already synced my personal files on my phone (N900), laptop (Debian) and web/email server (Debian again) via git. Personally, I use git for the same thing you use rsync for

      • by hoggoth ( 414195 )

        Ignore all those other replies that say, basically, "because they are too stupid to use leet things like rsync."

        Dropbox offers a few advantages over rsync:
        It runs in real time and detects changed files, syncing them instantly without polling the filesystem. (using services like inotify).
        It has iPhone and Android clients.
        It's easy to install and doesn't carry other requirements like cygwin, and doesn't break in all kinds of odd corner cases like rsync on windows does.
        It offers central management of which com

        • by hacker ( 14635 )

          Dropbox offers a few advantages over rsync: It runs in real time and detects changed files, syncing them instantly without polling the filesystem. (using services like inotify). It has iPhone and Android clients. It's easy to install and doesn't carry other requirements like cygwin, and doesn't break in all kinds of odd corner cases like rsync on windows does. It offers central management of which computers sync which files and folders (well, SugarSync does this much better). It offers a web based view of y

      • For starters?

        Because rsync doesn't always work well with firewalls and NATs.
        Because rsync doesn't work if one (or more) systems are on only sporadically.
        Because rsync doesn't work if you have multiple devices to sync and you don't have a "master" device.
        Because rsync doesn't allow you to see your data from any device that can access the web.
        Because rsync doesn't sync nearly immediately (24/7) to all devices (if they are connected) automatically.
        Because rsync doesn't allow you to see previous versions of you

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

    • For me, the surprising part is that someone can access your dropbox after you've changed your password. I guess I'm an idiot then.

    • by Hatta ( 162192 )

      Saving passwords to a file is only a problem if your permissions are fucked up. I can keep my SSH credentials in a file, and no one else can copy it because it's set to mode 700.

      • Which falls over in cases where someone else is root/administrator on the box you have an account on.

        GP's view is a bit incomplete in any case, though - it's not the password that's saved, but an authentication token that is independent of password changes.

    • If you're surprised by this then you must be new. Enormous service built from an amalgamation of tools with a history of obscure insecurities on top of transport technologies riddled with obscure insecurities is found to have obscure insecurities. This has been going on since before the registry.

  • 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.
    • by Binestar ( 28861 )
      I prefer individual file encryption for my dropbox files. I use AxCrypt http://www.axantum.com/axcrypt/ [axantum.com] which has right click integration to encrypt files.
    • If the attacker has access to your computer (as is the case in this article), your TrueCrypt keys stored in memory are already hosed. The only way TrueCrypt will help you in this case is if the attacker is accessing the files remotely somehow and has no access to RAM.
      • by maxume ( 22995 )

        TrueCrypt would help in the event that physical access was gained by stealing the hardware (assuming some exercise of diligence. i.e., the volume was not left open while the hardware was unattended).

    • by gfilion ( 80497 )
      I tried using truecrypt with dropbox, but I wasn't able to open a truecrypt volume on windows that had been created on Mac (and vice versa). Is it me who screwed up something or is it a limitation of the software?
  • ... 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

  • I only store encrypted data (TrueCrypt containers) in my Dropbox. I'm glad the extra work proved usefull...
  • 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.
  • by esme ( 17526 ) on Friday April 08, 2011 @02:43PM (#35761948) Homepage

    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.

    • by Anonymous Coward

      Any session based system has this same issue. Dropbox just has insanely long lived sessions. Unlike most places, however, they do provide the ability to de-authorize a session. System compromised? De-authorize your computer and re-login. The fact is you don't have to rotate your password to defeat this problem, just log out (de authorize you computer) from time to time. You should do this with any website really.

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

    • "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.
  • (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 [dropbox.com]

  • 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 obscur

  • the Cloud is ... (Score:4, Insightful)

    by Tumbleweed ( 3706 ) * on Friday April 08, 2011 @03:17PM (#35762416)

    Someone else's computer

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

  • by AgentPhunk ( 571249 ) on Friday April 08, 2011 @03:39PM (#35762692)

    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.

    • by slyborg ( 524607 ) on Friday April 08, 2011 @03:59PM (#35762924)

      Maybe you should find out what people are using the DB access for first...at my company, we use it as a working drop for communicating external documents with outside vendors, more convenient than shoveling everything around via email.

      My old joke about the ideal network for the network admin is a single computer in a bank vault, unplugged. It's unfortunate that the job basically is all downside in terms of incidents, but ultimately the job should still be to *facilitate* employee access to company data, customers, and each other. Otherwise you are actively impeding the profitability of your company.

      • I'm sorry, I know this is /., but did you not RTFA?

        I completely understand the concept of facilitating employee communications - we have a solution for that - secure file transfer (SFT), which we implemented after our FTP server was hacked and sensitive files went god-knows-where. SFT is quantifiable, controlled, and far more secure than something like dropbox, especially when you consider the issues described in TFA.

        And I disagree with the anon poster below who compares this to flash drives or CD's. Agai

      • Your communicating with clients via DropBox? Why not use a "real" solution like http://www.accellion.com/ [accellion.com] that supports things like actual user authentication, SSL transfers (that will work through any firewall) and can notify you when its updated? not to mention much, much bigger file sizes?

  • 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.
    • by snookums ( 48954 )

      You think Dropbox is less secure than a protocol which sends passwords and data in clear text, and reads passwords in clear text from a .netrc file? Please.

      The only mistake Dropbox have made is not re-keying on password change. Linux doesn't re-key your SSH authorized_keys file when you change your password either.

      • by dbIII ( 701233 )

        You think Dropbox is less secure than a protocol which sends passwords and data in clear text

        In this case where changing the passwords doesn't keep them out - most definitely. That's a very nasty failure. So yes, FTP is insecure so that makes dropbox a truly epic failure.

        As for SSH with keys - if you are doing it with keys you know you are doing it with keys and you know to change the key if you don't want to let people in. The epic failure of dropbox is it looks like you have a mechanism to change acce

  • by locust ( 6639 ) on Friday April 08, 2011 @05:34PM (#35763818)

    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.

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

When your work speaks for itself, don't interrupt. -- Henry J. Kaiser

Working...