Google Drive Found Leaking Private Data
collaboristablog.com
collaboristablog.com
However, the meta-point rishabhsagar touches on is that with an authentication-free access model, this is but one of possibly many potential failure modes. The risk surface is undefined size, but probably larger than your IT professionals are comfortable with.
I just checked one of my shared documents. It has a 44 long “random” string, it’s alphanumeric with a few symbols. It looks like a version of base64, but let’s assume that it has only 50 characters to choice, so there are 50^44 = 5.7E74 possible addresses (2.9E79 if we assume base64). (Assuming they are using something like a cryptographically secure pseudorandom number generator.)
There are 7E9 live person, and assume that each one share less than 1000 documents, so there are less than 7E12 used addresses. Only one in 5.7E74 / 7E12 = 4.2E66 address has a document.
For a brute force attack, lets assume that the attacker use each valid ipv4 address 256^4 = 4.3E9 to do 1000000 tries per second, so there are 4.3E15 tries per second.
So the expected time to guess an address is 4.2E66 / 43.E15=9.8E50 seconds, that is 3.1E43 years. (For comparison, the universe is only 1.4E10 years old.)
You're assuming that there isn't, for example, a timing attack on the string comparison function. And it doesn't have to be just their server either. It could be, for example, an intermediate proxy server that leaks timing information.
And your comment is interesting. Are the proxy servers expected to be secure against a timing attack?
(Also, the proxy administrator may be able to see the logs ...)
I think it is reasonable for someone to assume it is a capability, and to be surprised by the cascading vulnerability.
Doesn't Google already have the right to parse your documents in Drive to show you ads?
They just recently pledged to stop parsing the paid Google Apps for Business emails to build ad preferences to show on other Google properties like YouTube.
I wonder if they're already scanning documents, and if we'd even know unless they were forced to stop making misleading statements acknowledge it in a court case like in the lawsuit over ad profiling students email in Google Apps for Education.
Not to mention that Schidmt or Nadella could have read your email or seen your company docs this morning and traded stocks based on them and Google/Microsoft are not even legally obliged to inform you that it happened.
http://gawker.com/5637234/gcreep-google-engineer-stalked-tee...
Hope they have better controls now so that snooping on your data is not so easy for a Google employee now. But they're under no legal obligation since you sign away your rights when you upload data to their server. No one in that case would have a legitimate case against Google in court.
[0] http://www.stardrifter.org/refcontrol/
The web wasn't built with privacy in mind. 3rd party cookies and HTTP Referers are just the low hanging fruit.
I suppose one might consider their previous url private information, but if that's the case you've go a lot more to worry about than http referers.
The general default behaviour has always been to let an http server know where you're coming from so that it can take whatever actions appropriate. I don't see how or why there is a fundamental violation of some "browsing privacy" rule here.
URLs aren't protected any less than cookies are, and cookies are the standard way of securing login tokens.
Heck with URLs you get the 'secure flag' cookie option for free!
> Clients SHOULD NOT include a Referer header field in a (non-secure) HTTP request if the referring page was transferred with a secure protocol.
As for why it's still that way... I'm sure no one has bothered to really think about it since.
FWIW, the web would survive without Referer, but it is genuinely useful to site owners, especially in aggregate. Maybe a compromise would be to trim it to just domain rather than full path?
Google Drive makes it very easy to say "only these named people" should have access, or "only people who have the link AND a google account for your company"
I'm not on my work computer, but I can't remember there ever being an option for only let people with a company google account see this. If that was the case, why wouldn't that just be on by default (which I would argue is everyone's expected behavior on corporate google drive).
They include:
Public on the Web
Anyone with the link
lynch.us
People at lynch.us with the link
Specific people
Yes, someone could shoulder surf it, but we don't tell you that your bank account has no security because someone could shoulder surf you entering your password.
I'm aware of a story where a local credit union assigned account numbers strictly sequentially. A customer setting up direct-withdrawal typo'd their account number by omitting a digit, i.e. their acccount number was '12345' and they entered '1234'.
Since the numbers are sequential, '1234' happened to exist. For about a year, the company in question cheerfully direct-withdrew from the inappropriate account, and the original owner of '1234' never noticed, never complained, or had their complaints ignored. To my knowledge, the error was never rectified.
End of the day, direct-draft is a badly-architected system from a security standpoint.
I mean after all, we assume that's true for passwords.
URL-shortened links can be an issue, but raw google docs links have crypto-length randomy numbers.
The first time you email that link out, you have technologically released your ability to predict who will view the document (was the e-mail sent over secure channels end-to-end? Did it go to a trusted party who won't reshare it? Did you typo the e-mail address and send it to an undesired party? Did a recipient print it out and leave a printed copy lying around in an accessible conference room? Was the printout shredded after use? Was the shredding functionally irreversible? Is the shredding being done by a third-party that might lose some loads of documents on the way to the shred facility? Did you leave the link in your local machine's pastebuffer then walk away without locking your terminal? Etc., etc., etc.).
Even when the link is functionally unguessable, allowing non-authenticated access is just "security through obscurity."
If I shared a document with only you (directly, not using the "anyone with the link" permission), I couldn't stop you from taking a screenshot and sending that to whomever you pleased (or printing them out and leaving them in a conference room, like you suggested). Sharing documents online in general can be troubling if you don't trust the people you send them to. It's easier to share a link than share a screenshot, though, and a link would provide continued access going forward, and could remove deniability that the screenshot was faked.
Whole-document transformation and copying are a concern, but I think that's usually treated as a different category of issue from "The server I trust to store the data securely gave it up to some anonymous person who passed a correctly-formatted request to it because the server can't know any better."
I was just making the case that "Anyone with the link" still provides some security. Just like you don't know if the people accessing the document are the ones that you shared the link with, you don't know that the people you shared the document contents themselves with aren't showing others without your knowledge.
I think that would be implied when the setting says anyone with the link.
It would be the same if I attached the document to a email, someone could still forward the email.
This has only been fixed for new links. All existing links are still vulnerable.
From Google's Blog:
>"Today’s update to Drive takes extra precaution by ensuring that newly shared documents with hyperlinks to third-party HTTPS websites will not inadvertently relay the original document’s URL."
The bug has been patched so that any document with the "anyone with the link" permission will no longer leak its location in the referrer when someone clicks an HTTPS link in it. But it's possible that that happened in the past and the link was already leaked (and unfortunately, they can't exactly fix that). So if you have an old document, it's not vulnerable anymore, but it may at one time have been vulnerable so you might want to update it to have a new link (following the instructions in the Google blog post).
In essence, you needed to have a non-native document format uploaded to Drive without converting it (PDF is a good example); explicitly share this document with others using a particular setting ("anyone with the link"); and then preview it in the web UI and follow an outgoing HTTPS link (HTTP wouldn't be a problem).
It looks like Microsoft Onedrive did a similar thing too:
https://blog.onedrive.com/update-for-shared-links/ >"We chose not to disable all previously shared links, because the change only applies to a small fraction of shared files. If customers disable and then re-share a document, this will prevent further access to a document that might have been accessed."
Native-native docs wouldn't have a referrer because they wouldn't be rendered by the browser, so links would be a direct hop.
Disclaimer: I work for Dropbox
Yes. I expect security from my bank, from my insurance company, from state agencies, from my email provider, etc. I surely don't expect them to leak my data, and if they do, cause of a bug or incompetence, I want them to fix it.
And I want to be informed when they have breaches or fail to secure my data.
>Hello! If I gave folk a key to my house I doubt I'll have any my A/V equipment or computers when I come back after a long weekend.
People hire babysitters, cleaning stuff etc, give them the key to their house, and expect to have their A/V equipment when the come back.
If a cleaning person is reckless, and e.g leaves the door unlocked when he leaves, or a babysitter brings her pals over and have a party with my stuff, they get fired and/or sued, and people hire a more trusty person. Businesses that want to keep our private data should be kept to the same, or actually much higher, standards.
The "helloooo, is this news, of course it's unsafe, whaddaya expected" etc attitude doesn't help raise the bar on data safety.
I would think just the opposite is true. Perpetuating the idea that "Anyone with a link" means anything other than "Anyone" doesn't help raise the bar on data safety.
I'm glad Google made the enhancement to this, but wouldn't classify it as a security issue.
Facebook Engineering's entry on various methods of hiding referrers. This was 4 years ago, so some of these techniques might not still work.
Deleted comment