Oh, special -- how is Google leaking information now?

[jducoeur]

I just got an email that is clearly from some random spammer, asking for permission to share my spreadsheet "Wedding Stuff". This is the spreadsheet Kate drew up, that outlines the Wedding App that I have to have ready in Querki by April. (Yes, our wedding invitations have a spec. This simply demonstrates that we are well-suited to each other.)

That's not the disturbing part -- I expect random spammers to request random stuff all the time. What's disturbing is that it was even *possible* for him to request this. I mean, this is a private document in Google Docs, shared with nobody except Kate. Nobody else should even be able to see its existence, much less request access to it. So in principle, this email shouldn't have even been possible.

For now, I'm going to be optimistic, and guess that the spammer is simply plugging random numbers into an API -- not targeting any particular documents, just scatter-shotting requests in the hopes that some people will be dumb enough to grant access to something with personally identifying information. (Which, sadly, will probably work.) That wouldn't be *too* big a security hole. (Certainly not as bad as the possibility that Google is actually leaking the structure of my document tree.) But even that is somewhat sadly careless: as this particular phishing scam demonstrates, this approach does make it too easy for the bad guys to do something nasty.

The moral of the story is a basic security principle (which I should remember myself for Querki): simply knowing an object ID shouldn't allow you to do *anything* unless that object is fully public...

Comments

[dragonazure.livejournal.com]

As an isolated incident, it might not be as concerning, but when you consider that many people and companies are now moving to "the Cloud" to store their stuff, it suddenly becomes much more of a problem. My rule of thumb is If you want it to be private, don't put it on the Internet. :)

[jducoeur]

Yeah, I have mixed feelings there. On the one hand, I kind of agree; OTOH, I'm trying to start a cloud-based data company myself, which is going to have a *strong* focus on privacy controls. So I figure, it's going to behoove me to be careful about security, and very clear about what Querki does...

[metahacker.livejournal.com]

For many people that rule is insultingly unattainable. Just for starters, *you* may not be the one to put it on the internet...

[dragonazure.livejournal.com]

Point taken. I was thinking of files and things I personally produce. I'm not in the habit of distributing things electronically that should be otherwise secure. Considering it was my state's Department of Revenue that got hacked, that is a more sensitive point than normal.

[ilaine-dcmrn.livejournal.com]

You got me worried, so I did some testing. If you go to a link for an existing document (because it was leaked to you, or you brute-force guessed) and are signed in as a user that doesn't have access, google pops up a box offering to let you request permission to see it.

If you click 'request access' google sends the mail to the file owner, but doesn't tell you who that is, or anything about the document. The mail the file owner receives comes from google, not the spammer (unless forged, natch, but that is unlikely given the scenario).

So, the gmail address you got in the request is a real address belonging to the spammer, you could report it to google if you were feeling energetic. It doesn't appear they actually leaked any information.

[mneme]

True -- but ideally they should only be able to request the info if they already have the ownerid/docid pairing known. Since requesting access means they're emailing the owner, it would be useful if they needed to know -something- about the document more than the ID before they could do so.

[umbran.livejournal.com]

In the business use-case:

Person A creates a document, shares it around to Person B

Person B sees it, thinks it may call for view by another stakeholder, forwards the link to Person C.

Person C tries the link, and it fails. Person C doesn't know the ID of person A who made the document. All they know is a url and that a common acquaintance thinks he should see it.

You are trying to get business customers. Do you let the thing just fail, or do you give C a path to request access?

[serakit.livejournal.com]

Can't you solve that by allowing Person A to let other people grant access upon making the document?

[jducoeur]

Well, the relevant question is how they found the link for the document at all. I'm *hoping* it was simply brute-force-guessed: if the ids are sequential or anything close, that's plausible. (I had been assuming they were too long to be sequential, but that might be incorrect.)

But otherwise, that's the leakage I mean. This was a highly private document that AFAIK is accessible only to me and Kate. The *existence* of the document should be private. So any answer other than "brute force" means that there is an information leak.

(Even in the brute force case, there is a slight leakage: it looks like Google has admitted that this randomly-guessed number is the ID of a valid document. Minor, but still enough for me to notice...)

[ilaine-dcmrn.livejournal.com]

You get a reject back fast enough for a bad ID that you chould just test a lot of them. I'd presume google has checks in place to prevent brute-force, but I'm not going to lock my account by trying.

My money for likeliest avenue of the link escaping would be on attack of your or Kate's browser that stole recent history.

[dlevey.livejournal.com]

There are reasons why I won't use Gmail, Google Docs or Google Calendar - at all. This is one of them.