Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×
Cloud Data Storage Links Security

Dropbox and Box Leaked Shared Private Files Through Google 92

judgecorp writes: "People using shared storage providers such as Box and Dropbox are leaking data, a competitor has discovered. Links to shared files leak out when those links are accidentally put into the Google search box, or if users click links from within the documents. Dropbox competitor Intralinks stumbled across mortgage applications and bank statements while checking Google Analytics data for a Google Adwords campaign. Graham Cluley explains the problem in detail and suggests answers: for Dropbox users, it means upgrading to the Business version, which lets you restrict access to shared document links." Dropbox has posted an official response and disabled access to previously shared links. Box made a vague statement about their awareness of the issue.
This discussion has been archived. No new comments can be posted.

Dropbox and Box Leaked Shared Private Files Through Google

Comments Filter:
  • To the cloud (Score:3, Insightful)

    by Anonymous Coward on Tuesday May 06, 2014 @10:20PM (#46936069)

    ...and this is why we should all be wary of cloud providers.

    • by Anonymous Coward

      ...and this is why we should all be wary of cloud providers.

      And now we know why UX designers don't want to show the URL in Chrome anymore.

      • Re:To the URLbar! (Score:5, Insightful)

        by immaterial ( 1520413 ) on Tuesday May 06, 2014 @10:53PM (#46936219)
        I've always hated the move toward "omnibar" seach field/URL field combos for this very reason. Add in dynamic search suggesting and every damn thing many (if not most) of the people on the planet put in that field gets sent to Google. Anything Google does with the URL bar is solely for their own advantage. No thanks.
        • by dysmal ( 3361085 )

          I agree and thoroughly hate the whole "omnibar" trend that is happening with the browsers but What alternative are you going to use once Google has successfully rolled out their "omnibar" crap? The Firefox camp is doing everything they can to fuck themselves over while trying to mimic Chrome. They'll roll out the same thing with FF ver 45 (in 6 weeks at the rate they're going). The only difference is that the FF version will be buggier than shit.

          IE?

          • by lgw ( 121541 )

            Call me crazy, but I like IE (after I found adblock for it). The horror that is IE6 was long, long ago and you can turn off searching from the address bar. When I mis-type a URL (and anyone familiar with my posts knows I have about 1 typo per 5 words), it just sits there waiting for me to correct my typo - it doesn't send anything to anyone beyond the DNS server.
             

          • I'm using IE at work, the version where there is no omnibar. I hate it. Every time I want a website I'm used to typing part of it the URL and hitting enter. With IE7 or 8 (not sure) I have to type in the whole URL correctly. Brrr...

            • by Gr8Apes ( 679165 )

              This is a history lookup, not a search result. No need to go outside your own browser, much less your own computer. For this reason I don't use chrome, and I turn off autosuggest on everything that can be turned off. I also don't use Chrome except for testing or to connect to Google. Frequently clearing all cookies helps as well.

              Honestly, the omnibar setup may be the final stroke that blacklists all google addresses at my firewall. I've already been considering it and only having 1 machine proxy for google

            • Gr8Apes is correct. What you are talking is a part of omnibar functionality but is NOT what TFA is talking about (local v. remote data access)...

        • by AK Marc ( 707885 )
          I've been using (and loving) the omnibar for 15 years. That someone did it wrong isn't a problem with the feature, but the implementation. Opera had it long ago, though possibly not in exactly the same manner as done today.
        • Privacy issues aside, it's also a UI disaster. Previously, I could switch from URL mode to search mode by hitting tab. It became a reflex - create new tab, focus is in URL bar, hit tab, type search term. It took several months to unlearn that bit of muscle memory. And now, rather than a key press that takes a fraction of a second, I have to rely on some flakey NLP code to determine whether I want a search or a URL. I significant amount of the time, it decides that my search term is actually something t
        • by mcvos ( 645701 )

          Quite often, when I type a local url without the protocol in front, Chrome assumes I want to google for it. It's very annoying. I'm all for separating the search box from the address box.

        • The confusing thing is why this is so popular, anyway. As far as I see it, it is nothing more than Clippy, the next generation.

          Maybe people only disliked Clippy because it seemed like a distraction. I suppose the "omnibar" wouldn't be as popular if, every time it got focus, put up a large overlay box with the content: "It looks like you are trying to type a URL".

          Alternatively, it means people _would_ have liked Clippy if it just started silently writing the letter for you or if it sent the letter to Micr

  • by mlts ( 1038732 ) on Tuesday May 06, 2014 @10:20PM (#46936073)

    I've used DB to allow a couple colleagues to download some reports as well as larger amounts of data. IMHO, if a link is generated, even if the link isn't public, someone or something will find it and have the ability to snarf that file.

    The trick is simple -- if the files are small, but too big to E-mail, PGP/gpg encrypt them, then send the links via a secure message. If the files are bigger (~50-100 megs or larger), then the file goes into a TrueCrypt volume that uses a keyfile, and the keyfile is GPG encrypted and E-mailed.

    This way, even if the link appears on Google and Mallory does get a copy, other than size and the public keys used [1], the file is encrypted and useless.

    [1]: One can always put the file in a WinRAR wrapper and send the password via encrypted E-mail as well, further obfuscating the contents.

    • by hawguy ( 1600213 ) on Tuesday May 06, 2014 @10:39PM (#46936159)

      >The trick is simple -- if the files are small, but too big to E-mail, PGP/gpg encrypt them, then send the links via a secure message. If the files are bigger (~50-100 megs or larger), then the file goes into a TrueCrypt volume that uses a keyfile, and the keyfile is GPG encrypted and E-mailed.

      You have a much different definition of "simple" than most people. Few people (who are not techies) find transferring a file via GPG or TrueCrypt to be "simple". Even getting them to download the file from a cloud provider can be a chore "I clicked on the link but nothing happened! What do you mean I need to look in my Downloads folder?"

      • Re: (Score:3, Insightful)

        by ko7 ( 1990064 )

        When dealing with 'users' of the caliber that you describe, it really isn't possible to securely exchange data. Unfortunately, most 'users' can't be trusted not to have the file scraped off of their own box once they've received it. Without a minimal amount of computer knowledge and skills (which appears to be beyond the capabilities of most users), it just isn't possible to guarantee any security at all.

        • by Anonymous Coward

          What about the various "dropbox encryptors" out there? SecretSync/Viivo, Boxcryptor, Cloudfogger? They all provide "easy" to use client side encryption for the file sync and share guys (like Box/Dropbox)

          Some of them even support Dropbox Sharing (both DBX Shares and Public Links) with back-end key management.

      • The actual trick for this specific problem is actually even simpler: Have everyone sign up to dropbox (or GoogleDrive or whatever) and eliminite the need for the lazy "give file to anyone who knows the URL"-"Security". That's what logins are for.

        • Yup. I find it an extremely rare occasion where I have to send a Dropbox link out. I only do that for semi-public files anyway, otherwise they can indeed get an encrypted file and good luck with it.

    • It seems like the "vulnerability" that the article is talking about only happens when a recipient of the dropbox file link copies that link address into a google search query. If the user just clicks the link like a normal person, there is no problem.
      • It seems like the "vulnerability" that the article is talking about only happens when a recipient of the dropbox file link copies that link address into a google search query. If the user just clicks the link like a normal person, there is no problem.

        No, that's only half the problem. The other half is that if your shared document contains a link to, say, cnn.com and someone clicks this link straight from within the document, cnn.com can look at the referrer field and get the "secret" link to your document.

      • If the user just clicks the link like a normal person, there is no problem.

        This is also assuming that the user uses a "normal" mail program where you can actually just click on the link. Apparently, this is not necessarily possible in some of the Microsoft offerings.

        Also, if the link is too long, the mail program may break it in 2, and not consider the whole thing to be the same link.

    • by blueg3 ( 192743 )

      More simple, though "differently convenient", is to use the Dropbox sharing feature. The one where you share to individual users rather than making a public link. I thought the Dropbox application was pretty clear about the fact that the links were fundamentally public (though I'm in security, so I read things differently). The user-based sharing is less convenient, in that it requires some degree of "registration" with Dropbox to use it, but it has actual access controls.

      If there's a "shared link" to the d

      • by gl4ss ( 559668 )

        somehow the story is made about to be dropbox/box leaking files when the actual story is browsers leaking urls...

        • by blueg3 ( 192743 ) on Wednesday May 07, 2014 @12:25AM (#46936557)

          They do that by design. Referer is part of the spec. URLs -- or GET requests in general -- should not contain any private data. It's even CWE-598 [mitre.org].

        • Actually it seems the real story is that dropbox has now disabled these links.
          The link in the summary is full of people who used dropbox to share content with customers who now get a 404 or 403 instead.

          It's understandable that they use dropbox this way, e.g new promotional leaflet on garage doors upload it to dropbox and share the link, simple anyone can do it.

          Alternative options could be run a website with a cms system, require everyone to learn how to use it, make users create an account so they can acce

      • by amxcoder ( 1466081 ) on Wednesday May 07, 2014 @01:12AM (#46936733)
        Yes, dropbox used to mention this in the documentation (don't know if they still do), but if you put it in your public folder, it is public. I believe they used to say that it was even accessible without a link, if someone knew (or guessed) the specific folder+filename. One reason why I keep everything inside subject folders (within the public area) and not just plopped into the public folder en-mass, as it makes it harder to guess as you would have to guess the folder-name as well.

        On another note, another think I do when I send a document (like applications or forms with personal data on them), is I upload the file to a custom folder, then send the link to the recipient with the specific instructions that they let me know once they've downloaded it, so I can delete it off dropbox. That way, in most cases, it's only available for a few minutes to maybe a couple hours at most, and if anyone happens to intercept the URL, the chances of the file still being there are slim, as it's deleted as soon as the intended recipient gets it. The only way it can be stolen, is if someone intercepts the email AND tries to download the file faster than the recipient does. While it's not fool proof, it's not a bad idea completely. Surely it's better than attaching the file to an email that gets passed through several servers along the way and copies are kept at each of those points.

        I have to say though, in most cases, when someone sends me a file, I despise when they want to do a "share" rather than send me a download URL. The share semi-permanently links my account to theirs at that point, and takes up space on my allotment of space. Just send me a download link.
        • by geirlk ( 171706 )

          I have to say though, in most cases, when someone sends me a file, I despise when they want to do a "share" rather than send me a download URL. The share semi-permanently links my account to theirs at that point, and takes up space on my allotment of space. Just send me a download link.

          Must say I share that sentiment when it comes to sharing within Dropbox. When 1 person shares 1 file with, say 5 persons, that 1 file is weighted against all 5 persons quotas, thereby "stealing" alloted space. I find that kinda morally dubious at best, as people pay for their quotas.

          • The upside of it is that you can also delete the file, thereby reclaiming all that nice space! :)

        • Yes, dropbox used to mention this in the documentation (don't know if they still do), but if you put it in your public folder, it is public. I believe they used to say that it was even accessible without a link, if someone knew (or guessed) the specific folder+filename. One reason why I keep everything inside subject folders (within the public area) and not just plopped into the public folder en-mass, as it makes it harder to guess as you would have to guess the folder-name as well.

          On another note, another think I do when I send a document (like applications or forms with personal data on them), is I upload the file to a custom folder, then send the link to the recipient with the specific instructions that they let me know once they've downloaded it, so I can delete it off dropbox. That way, in most cases, it's only available for a few minutes to maybe a couple hours at most, and if anyone happens to intercept the URL, the chances of the file still being there are slim, as it's deleted as soon as the intended recipient gets it. The only way it can be stolen, is if someone intercepts the email AND tries to download the file faster than the recipient does. While it's not fool proof, it's not a bad idea completely. Surely it's better than attaching the file to an email that gets passed through several servers along the way and copies are kept at each of those points.

          For actual documents that can be PDFed the password based encryption function (set to aes128 or better, with a long password) is highly effective. You just need a pre-agreed password, or simply give the recipient a phone call and deliver the password verbally. For information that can't be PDFed, sadly there isn't anything as standard as PDF so obfuscation techniques may be the most effective approach.

  • by StormReaver ( 59959 ) on Tuesday May 06, 2014 @10:24PM (#46936091)

    This will work itself out. Those people stupid enough to put important data on other people's servers, where the have no control over who sees them and now, after being warned time and time again that this very thing is inevitable, will find themselves devoid of a bank account eventually. At that point, they will:

    1) Learn their lesson the hard way.

    2) Not have enough money left to pay to host their data on other people's money siphon.

    3) No longer have a need to host anything anywhere.

    • by Anonymous Coward

      Those people stupid enough to put important data on other people's servers, where the have no control over who sees them

      Right, I forgot, any people that aren't fully versed in how technology works are "stupid". For the lay person operating the Dropbox desktop or phone client, it gives the impression that only you, and people you share a link with, can see your document. It isn't well explained that the document can be seen by *anyone* in possession of the URL, not necessarily only those you explicitly gave it to. If we ever want to improve security culture among non-computer-people, the view can't be that they're "stupid".

    • by Camael ( 1048726 ) on Tuesday May 06, 2014 @11:24PM (#46936323)

      Those people stupid enough to put important data on other people's servers, where the have no control over who sees them and now, after being warned time and time again that this very thing is inevitable, will find themselves devoid of a bank account eventually. At that point, they will:

      1) Learn their lesson the hard way.

      Calling them stupid is not fair, I think. A majority of the older generation, especially those in their 60s or 70s are only just dipping their toes into using things like smartphones, iPads, emails, a little Facebook, Skype and maybe services like Dbox or Box to "keep their pictures". They did not grow up being exposed to personal computers or smart devices. They also grew up in a time when it was more common to trust authority figures. So now, they are bombarded by ads etc from M$, Apple and Google saying their services are safe- why would they not trust them?

      Your comment about "being warned time and time again that this very thing is inevitable" is specious. Certainly, if you are a techie or geek, you would see and take note of these warnings form the tech sites that you visit. The average Joe would not see it, and even if he did would not understand.

      You speak as someone who never had to guide an older family member/relative in how to use smart devices.

      • Calling them stupid is not fair, I think. A majority of the older generation,

        Actually, the older generation are not the worst offenders. They are often surprisingly mature as far as risks in technology go.

        The worst offenders are actually the facebook generation, who are so accustomed that they need to completely open up their browsers to play a game that they won't give any second thought if a malware site asks them to do the same.

      • You speak as someone who never had to guide an older family member/relative in how to use smart devices.

        I have guided my fair share of older people through technology, but I wasn't thinking of them when I called people stupid. You're right that it makes a difference, so I shouldn't be so judgemental. I was thinking of the tech types who still think that it's safe putting important data on some stranger's Internet-connected server, unable to see the inevitable consequences of doing so.

        A majority of the older generation, especially those in their 60s or 70s....

        Thank you for the perspective check, though. I'll keep older people in mind when I'm raging against stupendously bad choices

        • There's a difference between important data and confidential data. The data gathered by the LHC at CERN is pretty important, but it'd be hard to classify as "confidential". Unless they really accidentally created a black hole somewhere :)

          If you know what you do, you can store everything in Dropbox, no problem. If you don't understand the consequences, steer clear. Pretty much the same advice given by Warren Buffett about shares, I think. It applies to a lot of stuff :)

  • by Anonymous Coward

    Google should've put a filter to stop advertisers from seeing searched URLs that are obviously private (e.g. containing unique tokens like session IDs, order IDs, access of otherwise "hidden" files, etc). It's not necessarily good practice to send some of this info as a GET parameter, but the fact is that it's a very common thing.

    Most browsers will default the address bar to search if the input isn't a valid URL -- so all typoed URLs have probably been leaked to unknown 3rd parties too.

    • by jrumney ( 197329 )
      Agree - this is a Google problem, not a Dropbox problem. Google should not start indexing data deep within a site just because a user once tried to search for a URL.
      • Google should not start indexing data deep within a site just because a user once tried to search for a URL

        And it won't, if you know how to use your robots.txt.

    • Google has no interest in omitting data collection to mitigate other sites' security flaws.
    • That's up to the web site creator. Robots.txt is what determines whether a URL is truly private.

  • by Todd Knarr ( 15451 ) on Tuesday May 06, 2014 @10:27PM (#46936121) Homepage

    Technically they didn't leak private files, because the files weren't ever private. They were public with the URLs not published in an index anywhere, so you had to know the URL to access them. Dropbox and Box simply forgot that those URLs would appear in HTTP Referer headers, exposing them in the logs of any site linked to from within those "private" documents. Security by obscurity... isn't.

    A document isn't private unless it requires at least some kind of authentication to access it, eg. setting up HTTP authentication, or using a system like Google Drive uses where you have to be logged in on your Google account to see documents shared with you.

    • by jopsen ( 885607 )

      Technically they didn't leak private files, because the files weren't ever private. They were public with the URLs not published in an index anywhere, so you had to know the URL to access them.

      Yeah, but this is quite useful... I suspect the solution though is to do a redirect from the static access-url to a temporary content-url.
      I do, however, still fear that history would leak... Maybe two redirects would do the trick. As the content wouldn't possible to able to see the static access-url.

      Sure, authentication is nice... but sending non-published URLs is really nice.

      • by jrumney ( 197329 )
        Redirects won't work at all. The static access URL is the one that users are entering into the search box (because the browser hides the URL box, or puts them alongside each other and the user doesn't really know which is which), and is the one that falls into advertisers' hands. Any redirects that happen after the static URL are going to happen whether the user is the legitimate user, or someone else who got that static URL from a log file.
    • by aXis100 ( 690904 )

      Yeah, that's how I saw it too.

      Dropbox and Box should be quite embarased by this, it's shamefully lazy design in a world where online security matters.

      • by blueg3 ( 192743 )

        It's an extremely common design, and they also implement the other major alternative -- sharing with individuals that use per-user authentication. You can share Dropbox files either way (or both ways at once).

      • by gl4ss ( 559668 )

        but the users deliberately wanted to just share an url and not share between specific dropbox users. the real problem is the mechanism that got the urls to be indexed by google. which is entirely due to browser design and affects any url.

    • They were public with the URLs not published in an index anywhere, so you had to know the URL to access them. Dropbox and Box simply forgot that those URLs would appear in HTTP Referer headers, exposing them in the logs of any site linked to from within those "private" documents. Security by obscurity... isn't.

      No, you buy AdSense words, and it delivers matching URLs entered into Google -- then you grab the data there. Anyone can set up a data-collection like that.

      There is no conceptual difference between entering a password and a secret URL. It is not security by obscurity, it is security by "something you know". Once someone else knows, it's not secure anymore.

      The difference to passwords entered into other sites or Google is that it may not be immediately clear on what site to use the password, and with which us

    • by Mask ( 87752 )

      A document can still be shared, via URL and still be private as follows:

      As a dropbox user I want to share a file with you, but you are not a registered user. Dropbox generates and sends you a URL. Once you open the URL from a browser you get a cookie and the URL is no longer valid without this cookie. After this, no one but you can use the URL.

      Disadvantage: you can open it only from a specific browser on a specific machine.
      Solution: If you open the URL from a different browser you get the option to get a ne

    • Actually, a document isn't private unless you physically own it (hence, no "cloud" anything) and control the access to it (private links, self-destructing links, HTTP sessions, etc). Relying on an external walled garden means that you gave them ownership (either legally, or physically).

      As bandwidth increases, owning a link which resolves a piece of information will become increasingly equivalent to owning that information.

      • Actually, a document isn't private unless you physically own it (hence, no "cloud" anything) and control the access to it (private links, self-destructing links, HTTP sessions, etc). Relying on an external walled garden means that you gave them ownership (either legally, or physically).

        All of which is irrelevant to the vast majority of people, who can reasonably assume that the cloud provider is more interested in their business than in stealing their content.

        To most, security here means "the people I want to give this to can see it, other people can't". The fact that some cloud server must have access to it, and that an employee of the company operating the cloud could get in there and see it doesn't matter, since it's reasonable to assume that a reputable cloud service provider has po

    • I totally agree. This is the opposite of a leak. This is called "sharing". If you don't want your private documents put on the internet then don't put your private documents on the internet. If you don't want Google to know about your secret links then don't tell Google about your secret links.

      I'm having a hard time figuring out how this got onto Slashdot... oh, Soulskill, well that explains it.

    • Neither Dropbox nor Box are going to accidentally publish their HTTP server's logs publicly.

      It is up to them whether to put up a Robots.txt file to determine this. Both even have one- but it doesn't include shared private files:

  • People using shared storage providers such as Box and Dropbox are leaking data, a competitor has discovered. Links to shared files leak out when those links are accidentally put into the Google search box, or if users click links from within the documents.

    This sounds more like an ID10-T problem to me. If the user wants the links kept quiet they need to make sure not to type them in public places or link them in files they give others.

    • by blueg3 ( 192743 )

      In the latter case, they're actually talking about you (party A) sharing a file that contains links. That file is shared to party B, who clicks on one of the links. The target of the link is a website, party C. The URL to the shared file is exposed to party C via the Referer header, which contains the URL to the shared file.

      This exposure is non-obvious even to technical people, but it's commonplace. Paths get leaked all over the place, so information in paths absolutely must not be considered secure. For in

  • When dropbox wrote blog regarding that issue, it simply means that they did action to fix that issue. So, why making that issue big deal to public.
  • by NitroWolf ( 72977 ) on Tuesday May 06, 2014 @11:58PM (#46936461)

    A more important question is why are you using a cloud provider without using encryption? No one should be storing any sort of sensetive file on a cloud service without first encrypting it. I use Boxcryptor on all of my cloud services... Truecrypt also works well for that sort of thing... anything. Use something to protect yourself instead of giving unfettered access to the cloud provider and their (lack of) security.

    They have little reason to protect you.

    • by pla ( 258480 )
      No one should be storing any sort of sensetive file on a cloud service without first encrypting it.

      Came in here to say exactly this.

      Whether or not you trust Joe Sixpack with your files, why the hell do you trust DropBox themselves? Corporate America has proven to us, over and over and over, that they'll sell us out to the highest bidding government in a frickin' heartbeat. Encrypt, encrypt, encrypt!


      I use Boxcryptor on all of my cloud services... Truecrypt also works well for that sort of thing.
  • Box and Dropbox are forbidden where I work, as they host data on external servers. Company data should be stored on company servers.

    • by AK Marc ( 707885 )
      They are forbidden where I am too. Putting SOX or customer data on them is not just frowned upon, but illegal (and no, not SOX data, but data that falls under SOX rules).
      • Why is storing SOX or customer data r/t SOX on Box or DropBox illegal? Is it an auditing / Access Control issue? Or is it the fact that it's merely kept on an owned server?
        • by AK Marc ( 707885 )
          Illegally sending sensitive insider information that could affect stock price to a 3rd party is considered illegal. That you "trust them not to tell" doesn't change that.

          Privacy laws prevent sharing of customer data with 3rd parties without explicit permission, and we have explicit permission for billing and collections only, as far as I know. So customer data is out.

          So any publicly traded company is likely breaking the law if they use dropbox for anything not cleared for public distribution.
  • Condi is on the job!

  • by crioca ( 1394491 ) on Wednesday May 07, 2014 @03:25AM (#46937149)

    Drop/Box gave these users the option to make these files publicly accessible, they chose to make them publicly accessible, which made them publicly accessible. THE HORROR!

    How is this getting reported? Is this some kind of weird post Heartbleed security reporting bandwagon? /. editors, this is a wood league effort, step it up please.

  • Someone typed a full, unsecured, web link into a search and Google AdWords reported it to the advertiser. I don't believe this would be considered a security issue or flaw with any cloud provider. This is customer error, not securing sensitive information with a password or permissions. If anything, it'd be a flaw with Google AdWords reporting the full search terms, but even that is stretching it.

  • The "cloud" hate is strong here so I suppose I shouldn't be surprised that nobody has mentioned this yet, but this is quite simply a non issue. Box and Dropbox allow you to share files publicly, but it is not the default. While each have had genuine security issues in the past, this is not one. This is simple, common user ignorance. Both services have proper and secure sharing methods to share documents with other users of the service that require authentication on both ends.

    What happens is:

    - User clicks "S

"Protozoa are small, and bacteria are small, but viruses are smaller than the both put together."

Working...