Ask HN: Google Doc email virus? | Hacker News Reader

Ask HN: Google Doc email virus?

481 pointseof209 comments

We just received multiple "google doc shares" that seemed sketchy and were not sent by the claimed sender.

They came from different companies that have no connection to each other, I assume others are seeing them too right about now. Anyone know whats up?

View on HN

I reported this attack vector to Google back in 2012. They awarded a modest bounty, and then a few months later I heard this:

> "We're deploying some abuse detection and reactive measures to deal with impostors that might try to abuse this sort of attack. Given this, we do not intend to perform validation that the URL matches the branding information."

That last part was in reference to one of my proposed mitigations, which they chose not to implement.

Here's the discussion on the IETF OAuth WG mailing list from that same time period: https://www.ietf.org/mail-archive/web/oauth/current/msg07625...

This is the most valuable comment here.

Unicode domain names, Google OAuth phishing...changing my passwords every 30 days is looking less and less important.

It's sad we can't seem to provide good, usable secure software.

The problem, it seems, is that we are increasing the complexity of the "Secure Software" in an attempt to thwart the most sophisticated attacks.

However, as many people are already thinking, Complexity reduces Security and Stability. Therefore, it seems that the more we try to fight the "hackers", the more likely we will add some insecurity which they can exploit.

Complexity doesn't reduce security.

Complexity can both improve and reduce security depending on specifics, and thus generalizes to "no correlation" demonstrating that generalizations are often misleading.

Your claim that it generalises to "no correlation" is not supported by your assumptions.

Uh, begging pardon, but what are my assumptions again?

> changing my passwords every 30 days is looking less and less important.

Sidenote: I don't think that was ever a good idea, unless you think you were likely to type your password into phishing sites in the last month.

Sadly, PCI compliance requirements believe otherwise :(

The PCI requirement is to change passwords every 90 days.

And is patently silly, forcing the requirement to decrypt rarely used private keys every 90 days.

The requirement should depend on password and hash strength, not some arbitrary decision.

PCI does not recommend employing password entropy checkers either.

90 day password can be weak while passing all the requirements.

Everywhere I've worked appears to have their own way of circumventing the security of PCI requirements. On a military base I worked everyone used an easily recognizable pattern on the keyboard. Another place was something like [employer][symbol][123 or 321]. All too often people use the same pattern that the IT team uses when they reset your password. So if the IT team typically sets your password to WhyCombin@tor1, then everyone's going to cycle through 1-10.

Making people reset their password every 90 days probably causes more problems than it solves and incentivizes more easily guessable passwords.

PCI in general is patently silly.

Passwords for authentication was just always a flawed idea, typing them into the DOM and sending them over the wire even more so.

I agree. However I have yet to see a better alternative. Are there any out there?

Basic auth doesn't use the DOM.

Did they ever solve the privacy issues with browser client certificates?

TLS 1.3 may solve some things. It depends what you lean by "the privacy issues"...

I'm not an expert or even particularly up to date, but I heard that other websites could see the client certificates installed. So a third party website might recognise the client certificate and know things about the user.

Absolutely! My favorite is usually referred to as passwordless authentication, and generally means that when a user gives you their email address/SMS/etc, you send a login link to their device.

Here's an article: https://medium.com/@ninjudd/passwords-are-obsolete-9ed56d483...

Most people today authenticate their email account by typing their password into the DOM and sending it over the wire. It puts a ton of pressure on email providers to be secure. I consider my email password the absolute most important piece of information I have.

So although I do agree with you (and have created sites in the past that do passwordless login), the general password problem doesn't really get solved with this approach.

I am not saying that any of this is practical for 99.99% of email users. In fact, I would venture to say the opposite - my suggestions are practical for less than 10 in 100,000 users. With that caveat, there are a variety of ways to make email more secure.

Every Unix system has a mail daemon as a core function. If you've ever seen "This incident will be reported." because your user is not in the sudoers group, the incident gets reported via the local mail system. Mail servers today (outside of Microsoft's Exchange servers) are still overwhelmingly Unix-like systems. A mail user just needs a Unix host, a username and ssh + mutt/pine to access their mail in this way. Then an attacker needs to identify the unix host, the username and the ssh credentials. The first two bits are likely to be trivial - the Unix host is probably published in DNS MX records, and the username is probably the local part of the email address. The last part does not necessarily need to be a password. Good security practices will have it be an ssh keypair. ssh keypairs are provably computationally secure (until quantum computing comes along) and ssh private keys often also have passphrases. Other measures - like U2F security keys - can also be required as part of ssh authentication.

So this is probably the gold standard when it comes to security for an email inbox. Is there any way we can make this more usable so that a GUI mail client can be used? One answer is to run the mail client on the Unix host and use ssh X forwarding to display it on the client machine. Another answer is to run a POP or IMAP server on the Unix host, force TLS and use normal plaintext passwords over the TLS tunnel.

Both the ssh and the IMAPS solutions require some way to authenticate the server side of the connection. The ssh mechanism typically defaults to trust on first use, but since one is publishing DNS records anyways, a SSHFP (ssh fingerprint) record seems like a good additional step. The IMAPS solution requires re-authentication of the certificate for each session. I am not sure what the current state of the art is for this for IMAPS servers. I personally believe that the CA model used for HTTPS is severely flawed.

All of this to say that for the truly dedicated user of a certain minimum (but high!) level of technical sophistication, passwordless login everywhere is possible (ssh keys; or having the email client securely store the password for use with IMAPS).

How about two-provider authentication? (2PA?) Send codes/links to two confirmed but independent accounts (email + Twitter, or Facebook + SMS) and require those to be entered.

Probably not anymore secure--and a nightmare to manage. But look to consensus algorithms for authentication ideas.

Phone is a (slightly) harder target, but Twitter + email is equivalent to just email.

I really like that approach, but it's just shifting where a password is required, not eliminating it.

A technical alternative, yes, something like SRP. A usable alternative that is actually universally supported, well, no not really.

> changing my passwords every 30 days is looking less and less important.

Using some non-English Unicode text as password will make the password really strong. I sometimes include Malayalam text for passwords as it's my native language.

Or made up Malayalam words such as Melcow!

cs91PvMVtET37V%eKEMut0LI^kQYp3e&jSuCGl!9Lp

Lastpass.

All I see are asterisks, weird.

Oh. I just grabbed what would have been my next random 42 character password, hoping that would be sufficient to prove the point that (almost) ridiculously long one time use passwords is the way to go.

Bravo. Masterclass username for this comment. I'm dying.

(For those who may have missed it in this HN crowd, let me momentarily invoke a veil of joke-explainer and offer this http://knowyourmeme.com/memes/hunter2 of the joke.)

Haha, I've been around for a while but that one I missed. Awesome.

HackerNews: Where the subtlety of a comment's humor is inversely proportional to the size of the cognitive DDOS it initiates.

Appropriate username indeed!

Then oauth based attacks like this come along and your password (however strong it may be) and two-factor auth are bypassed completely... It's interesting Apple can scale personally vetting apps for the app store but Google apparently can't be bothered to do the same for apps that could actually ruin businesses and lives with the data they could scoop up

It is not quite a virus, it works more akin to a trojan and exploits people not thinking about what they're clicking.

In 10s, why would Google docs ask for an oAuth prompt with big permissions?

People click through security dialogs, it is a known fact.

Funny that you'd ask that, as when developing Google Script automation scripts, Google Docs asks for exactly that.

(Of course, this is a different situation and all, and there is a lot of sense in your comment that mine doesn't at all invalidate.)

We can, just need to take responsability serious like in other fields.

Software bugs should be no less than product defects, with possible fines in place.

When you change your Google password, all OAuth tokens are revoked. The next time you use an OAuth connected App you will have to authorize it again, hopefully not making the same mistake twice.

This was particularly effective because the app was registered as "Google Docs" - to not even filter names of your own products out seems ripe picking for imposter apps.

I've seen this point and agree with it, but I really have to wonder: if the app was just called "Documents" or "My Docs" and had a professional-looking icon, would a significant number of people really have given it a second look anyway?

It was "Google Docs"

I understand that - my question is whether the name is actually a factor that contributed to the spread. As AfroThundr said above, people just want to get to their content and want the dialog to go away. A known contact sends you a document - you're going to trust that and want to see the document. Unless it said the app name was "I'm going to hack your bank account" they'll probably click it (and even then, some would go for it anyway.)

The message was "Google Docs would like to 'Read, send, delete, and mange your email'".

People are way more likely to accept that than if the dialog had been "hhhhhhhhhhh@mailinator.com would like to 'Read, send, delete, and mange your email'".

Trends are moving away from displaying full URLs as well, and while it may look cleaner, I never asked for information to be hidden from me.

I'm fairly certain a large number of users would still click allow without a second glance, much like hitting "allow macros" in an office document. They just want the annoying dialog to go away.

Nah... they can just say "Free unsubscribe service" or "Free <whatever>". And people will click like crazy. And you can make actually make VC fundable business using that technique.

Was it actually called "Google Docs", or was it a homograph?

https://en.wikipedia.org/wiki/IDN_homograph_attack

To be clear, I'm not criticizing Google. Just presenting an interesting piece of information that shows the approach they've taken on this type of phishing attack in the past.

Phishing is a hard problem, and any technical solution will only go so far. The main criticism I have with many OAuth authorization dialogs, not just Google's, is that they often don't show enough information for technical users to vet the authenticity of the app. It's like if a web browser didn't show the address bar.

Mailinator here:

Yes, we sent the inbox to a blackhole but keep in mind, Mailinator does not and can not actually "Send" any email.

It's a receive-only service. As always, any email "from" @mailinator.com has had it's reply-to forged (which is pretty trivial).

Also - even before we blackholed the email, it's unlikely any email in that inbox (i.e. hhhh..) was read. Each box has a 50 email limit (FIFO) which was immediately overwhelmed. You couldn't click fast enough between seeing the inbox list and clicking an email.

Mailinator is simply a "receiver" in all of this but we have no indication our servers were otherwise involved.

Those can be easily harvested from there

> it's unlikely any email in that inbox (i.e. hhhh..) was read.

Any way you can tell for sure?

Do you have any logs that could be used to graph the spread of this? E.g. if you were able to find the earliest email to that mailbox you should be able to tell when it started, and with who.

Half the people reading this post probably have gone there by now and read what's there.

> Each box has a 50 email limit (FIFO) which was immediately overwhelmed.

That makes me think the malicious author didn't expect this to spread as wide as it did.

It's my guess that Mailinator is extremely irrelevant to their plan.

They planned to propagate via BCC but they needed a "To:" address - preferably one that didn't bounce.

So they hit the "h" key awhile, then added @mailinator.com

Why didn't they just send the email to the recipient? What does the BCC add in this context?

BCC recipients can't see (or contact) each other to mitigate the spread. If you look at the source code, it BCCs 99 contacts from the infected account per message.

Would it have made a difference if they made the "To:" a non-existent address? Would a bounce also prevent delivery to BCC recipients?

Technically, they have to defeat greylisting and server validity checks anyway to get mails accepted to most modern mail servers.

This is probably some kid. cutpastemonkey the code from here:

http://stackoverflow.com/questions/37321100/how-to-login-wit...

Probably sat in his bedroom right now waiting for the feds going 'wow that escalated quickly'.

I don't see a TXT record for _dmarc.mailinator.com. If you created a DMARC reject policy all the major webmail providers would block messages "from" mailinator.com

DMARC basically doesn't work, many mailservers don't look at it and those that do frequently ignore the policy -- even setting a REJECT policy typically results in mail being passed through like nothing happened.

When I received a copy of the email 9 hours ago, I tried loading that h^16 mailinator inbox a few times. It was showing as empty except every few minutes a response to the virus email would come in. I saw "stop phishing" and "suck it!" and a couple of others. The virus email itself wasn't showing there.

EDIT: According to a Google representative on the reddit thread, this application is now blocked. If your account was affected, you no longer need to do anything.

If you fell for this, changing your password is not the right solution - you want to log into your google account and remove permissions from the application.

https://myaccount.google.com/permissions?pli=1 should show a list of apps connected to your account.

Also, if you fell for this, you sent a bunch of emails to people like the one you received, so maybe tell them not to click.

what application? i tried this and dont see anything in there that looks like it could be it

"Google Docs" with the real icon and everything.

Not seeing that weirdly. Could it be "google chrome"?

Apparently Google has already shut this down. Likely they revoked the access from all accounts as well.

Link?

https://www.reddit.com/r/google/comments/692cr4/new_google_d...

I've seen 2 client ids used and yes Google Docs and Google Chrome, not sure if google closed them both/all down. Here's a video on what to do/look for:

http://youtu.be/fjEenkk9Ntk?hd=1

Removed picasa, im guessin that's just Google Photos tho. so idk

It will be called "google docs" because for some reason that's allowed.

Source code of the worm: https://hastebin.com/gubegaqusi.xml

Pretty much what you'd expect.

Edit: This isn't the full source code. There was another PHP file visible on their website that unfortunately isn't visible anymore.

Heh, they're using Google Analytics to track its spread. That's a nice touch.

It's possible to send any data we want to their Analytics tracker... perhaps we send them some spam?

Where is ilovevitaly when you need him?!

"No fair! You got your privacy invasion in my privacy invasion!"

That made my day.

Sending everything to this mailinator address which oddly seems to be empty:

https://www.mailinator.com/inbox2.jsp?public_to=hhhhhhhhhhhh....

Maybe Mailinator has purged the box and is rejecting mail from it. Good on them.

Mailinator purged it early on yeah.

Man, I wonder how wider this would have spread if they spent a teensy bit more time to make e.g. the To address less suspicious.

On a brief skim, it doesn't seem to do much besides spread itself. Am I missing something, or was it just for lulz? Or maybe a grey hat trying to prove a point?

That's all this code does, but The author then has a backdoor to all the victim's email through the oauth app.

Except that Google can kill those auths.

It's really a question of how malicious the author was- if they set it up to download everything attached to the account as soon as it connected, it could still cause a lot of damage.

Even worst: The hacker could have taken a list of lets say the top 1000 banking (or any type of online service) websites accross the globe. The moment the hacker get access to your gmail account, he initiatite a password recovery request on each of those 1000 websites, get the password reset link from the email, reset the password, delete the email. he could now have access to any other online account you have that had its recovery email set to your gmail account.

Safe to assume that google could track such activity for affected accounts and notify if that was widespread?

(or is that somehow against the 'only our anonymized ad display program can scan your email' privacy policy?)

The most recent statement from google said that "no other data was accessed" so interpret that as you will

It redirects to a couple different PHP pages as well, so there could have been more malicious code there

What context was that code expected to be executed in?

Here's a video I made on what you or they need to do: http://youtu.be/fjEenkk9Ntk?hd=1

> If your account was affected, you no longer need to do anything.

How do you figure? An unknown actor presumably had full access to your email inbox for a non-zero amount of time and the proper remediation is "nothing"? If I was concerned this had affected me I would right now be changing my passwords to ____everything____.

What attack vector does changing your password help with? Are you concerned they could have recovered the account password via the Oauth scope?

Changing your password is the fastest way to ensure all authed sessions on any device is logged out. Google offers a "log out of any sessions" button somewhere in account settings, but most other services don't.

If your email account is compromised, any service that do password resets via email confirmation, are potentially compromised by whoever has access to your email via OAuth.

I'm pretty sure that changing your password does NOT revoke your oauth scopes, which was the attack vector here.

The greater issue is the passwords of other accounts, which could now be 'recovered' as the attacker has your access to your email

Yes, I agree, although revoking the scope should remove the access (and I assume Google did that for everyone already).

After looking at the source code, it looks like all it does is send a copy of itself to somebody in your inbox, and nothing else.

We dont really have any proof that this is the only code that got executed. Whoever owned the OAuth account had direct access to your information from google's servers, he wouldnt need to go through you as a client to get it.

Well change the passwords to everything except the google account that was compromised. I don't think you can recover the password of a google account through its own gmail inbox.

Although I guess if you had a circular recovery chain of this google account depending on a different email that depended on this google account, the attacker could use your email to recover the other email then use the other email to recover this google account. So it might be wise to change the passwords to everything.

It's a pretty nasty one, since it uses their standard OAuth flow with an app "Google Docs" to have users grant full access to their email and contacts.

1. I can't believe Google doesn't have basic filters to disallow developers from registering an app named "Google Docs"

2. Perhaps there should be some more validation/limits associated with allowing apps on the platform that can gain full access to email. A secure email account is the One True Source of authentication in the digital world. Google should make it way harder for people to get tricked into granting full access to their inbox.

Is it actually Google or is there some unicode trickery going on?

Doesn't look like a unicode trick on the app-strings I'm getting

Is there a database of homoglyphs for common fonts that one could use to write a visual string matching algorithm?

http://www.unicode.org/Public/security/8.0.0/confusables.txt

https://github.com/codebox/homoglyph

http://homoglyphs.net/

From what I can tell, it's actually Google, but then they redirect you to a malicious URL after auth/approval

Seems like it's allowed in the oauth form: https://pbs.twimg.com/media/C-7NlIzXUAErblp.jpg:large

> A secure email account is the One True Source of authentication in the digital world.

The gmail account you use to talk with people shouldn't be the same one you use to send password resets to.

It's fine to allow CRM apps or whatever to have OAuth access to your regular gmail account, you just shouldn't give read-write access to the one you use for your retirement account or whatever. (Read-only access is much less dangerous, because even if someone can trigger a password reset email they can't delete it afterwards.)

> The gmail account you use to talk with people shouldn't be the same one you use to send password resets to.

The vast majority of services don't support setting a separate password reset email, so that would be a showstopper for most people. You'd end up just having another email account you have to check all the time (since non-reset email would also go to this account), and could still easily get bitten by this sort of spam/phishing.

> You'd end up just having another email account you have to check all the time

You'd need an extra tab open in your browser that you'd need to check multiple times per day. But most automated messages don't require a response within fifteen minutes or whatever, so there isn't much extra cognitive overhead. And for most people you probably also don't need that email address authed on your phone.

You don't seem to understand. Services send emails to users for a reason. Those users typically want to actually be able to read those emails. That means they need to actually check it regularly, and probably want it available on their phones as well. The email address used here is also the email address the service uses for password reset emails. If you redirect these services to a secondary email that you don't auth on your devices, then you're also greatly reducing the utility of these services.

The cognitive overhead is not my objection (and I agree it wouldn't be much). The problem is that most people's personal email isn't primarily about correspondence anymore; it's about interacting with the various services where you have accounts or subscriptions. So your special password-reset email is also the place where you receive your social media notifications (because your social media account doesn't let you set a separate email for notifications and password resets). So now your password-reset email account is just as vulnerable to phishing because it's _not_ just your password-reset email, and there's no way to make it so.

I think they do, I got an app shut down because it was named too similar to one of their products, this was just a week ago or so.

Manual review if it is reported? Because if it was manually reviewed before first use this never would have gotten through.

> 1. I can't believe Google doesn't have basic filters to disallow developers from registering an app named "Google Docs"

Believe! I think this is just one of the many cases where after the fact everyone is like "oh wow, how didn't they think about it". But that doesn't say you would have thought about this before reading this.

They reportedly knew about this since 2012: https://news.ycombinator.com/item?id=14260298

Links of interest:

https://www.google.com/appsstatus#hl=en&v=issue&sid=4&iid=c7...

https://www.reddit.com/r/google/comments/692cr4/new_google_d...

https://www.theverge.com/2017/5/3/15534768/google-docs-phish...

From the reddit link it looks like Google has fixed it:

> Googler here -- I'm escalating to the correct engineering and product teams now.

> Edit: This is now resolved. Less than a half-hour after escalation, wow! =)

> Final edit: problem is resolved. I clicked the link and got an "oauth client disabled" message. Not pretty, but at least you won't get phished.

"Fixed" in the sense that this app is now blocked. Is there anything to stop an other worm like this, with a different name?

I'm sure they'll do a post-mortem and come up with additional protections, they just take longer than the immediate fix.

I love how simple this worm is. They haven't exploited any security holes (other that looking like Docs), it literally just asks for full access to your email address.

Yeah, I read articles calling it sophisticated. This is a super simple and straight forward worm. Disguise yourself as a known app and ask for more permission than you should. IDN exploits [0] and attachment faking [1] are more sophisticated if anything.

[0] https://www.wordfence.com/blog/2017/04/chrome-firefox-unicod...

[1] http://fortune.com/2017/01/18/google-gmail-scam-phishing/

It's sophisticated because of it's simplicity and effectiveness.

Technical simplicity, but sophisticated social engineering. Guess what the weakest link is between apps? It sure isnt the tech.

Its sophisticated in the sense that it makes you trust them and willingly share your information with them. It doesn't rely on some brute force method or some complicated hacking method, it simply rely on a modern workflow that people are used to go through without thinking twice about it. It is simple and incredibly efficient.

Its a malicious OAuth client (multiple clients?) that calls itself "Google Docs" and fooled user into giving access to read emails, while pretending to show as if it was needed by GDocs itself to access a Document, enabling launch of among other things password resets on other websites.

the root problem seems to be that the identity of OAuth Servers is not authenticated/clearly shown, i.e. a malicious app can claim that its name is Google Docs even though it is not endorsed by Google.

IMPORTANT NOTE: If you are running any website that has "Reset my password" it might be used by attacker, since even though the attacker does not have access to password, the attacker had access to email inbox. Thus the email password reset flow will allow attacker to compromise other websites that rely on Gmail account for password resets.

https://twitter.com/zachlatta/status/859843151757955072?ref_...

https://www.dropbox.com/s/l024nggmcizub40/Screenshot%202017-...

Wow, Hired.com appears to have emailed all of their users about this. Must be spreadinq quickly. Note that they advise compromised users to change their password - which other comments indicate does not solve the issue.

Below is the Hired notification.

---

Important: Email Phishing Alert

Hi <first name>,

It has come to our attention that some of our users may have been hit with a Google Docs phishing scam. It appears that this scam has been spreading throughout the internet today, and is not isolated to Hired or our customers and candidates. If you want more information, you can read about it here[1] or here[2].

If you receive a Hired email that says that someone from Hired has shared a Google Doc with you, please validate with the sender before clicking the link or doing anything else.

If you think your account may have been compromised, be sure to change your password immediately.

We apologize for this interruption to your day. Please let us know if you have any questions.

Thanks, The Hired team

[1] https://www.theverge.com/2017/5/3/15534768/google-docs-phish...

[2] https://gizmodo.com/a-huge-and-dangerously-convincing-google...

Looks like this is fairly widespread.

This is what the attack actually looks like: https://twitter.com/zachlatta/status/859843151757955072

It managed to hit regional mainstream media here (like 10 minutes ago).

I guess that probably just means someone working there got it though.

Source code of the worm: https://pastebin.com/raw/EKdKamFq

Edit: How I got this:

Someone on reddit went to their site when it wasn't down, and downloaded the files linked in the page's HTML. I just posted it here.

This isn't the full source code. There was another PHP file visible on their website that unfortunately isn't visible anymore.

Where'd you get this?

Sending everything to this mailinator address which oddly seems to be empty:

https://www.mailinator.com/inbox2.jsp?public_to=hhhhhhhhhhhh...

Maybe Mailinator has purged the box and is rejecting mail from it. Good on them.

Please correct me if I'm wrong, but I don't think anything was being sent to that mailinator address.

From looking at both that source code and emails received by my users, the mailinator address seems to be only in the message header "to" field, which, AFAIK, doesn't do anything other than display in the mail client.

The actual recipient's address is in the envelope recipient field.

I don't understand what the purpose of that mailinator address was.

It sends an email to that mailinator address, with all of the contacts BCC'd. mailinator shut it down very quickly but emails definitely went to that address.

They even used Google analytics! UA-98290545-1

I like how the code has Javadoc comments, in case other developers need to maintain the worm or use its public API.

That's gotta be a copy-paste job. If someone was actually cheeky enough to comment their malware they would've left jokes, puns, etc.

Indeed, those comments come from a Google Analytics quick start: https://github.com/chriskwan/gmailytics/blob/master/quicksta...

Copy/pasted from this Stack Overflow answer: http://stackoverflow.com/a/37342136/300887

Considering how easy it would be to filter this out, why has Google allowed it to continue spreading within their own email network? Obviously they have no control over what goes on outside of Gmail/G Suite, but inside their own network, they should be able to setup a basic filter to stop anything TO: hhhhhhh@mailinator or whatever it is. I received this email (but did not click the link) in my Gmail account from another Gmail user, so it never left the Google network. From the reports here it looks like it is still spreading even though Google disabled the app.

With all of Google's machine learning expertise, how is it that this got past all of their SPAM detectors? It took me 2 seconds to hover over the link and see it was a crazy link that ended up at a domain called google.pro. Really? One of the world's largest and most advanced email systems couldn't figure that out?

It was shut down within 30 minutes.

No it was more like hours from when I reported it and when the app was finally blocked.

Reddit post: https://www.reddit.com/r/google/comments/692cr4/new_google_d... (you can view complete timestamps by hovering.)

We wrote a guide for google suite admins on how to lock down their domain. Oauth and phishing are major threats and google could do much more here https://medium.com/@longtermsec/more-tips-for-securing-your-...

I work for a fortune 500 (wont disclose) but we just shut off email for our entire organization due to this...

SANS writeup: https://isc.sans.edu/diary/22372

Articles:

https://motherboard.vice.com/en_us/article/massive-gmail-goo...

https://www.theverge.com/2017/5/3/15534768/google-docs-phish...

https://blog.malwarebytes.com/cybercrime/2017/05/google-docs...

Hi, I'm Google Docs. Would you please grant me access to your Google account so that I can read, send, delete and manage your mail, as well as manage your contacts?

Oh noes, it looks like humanity got hit with a super-sophisticated cyber attack the second time in a day!

Hi Google Docs. I'm not sure I need any help managing my email at the moment, but maybe we can just be friends?

Our support team is getting spammed a lot from our customers. We're in the education space, and it's spreading pretty quick.

On initial inspection the URL looks harmless, but it's got some malicious params in there, mainly

  redirect_uri=https%3A%2F%2Fgoogledocs.g-docs.win%2Fg.php

It appears to request read/send access to your email, and then spam all your contacts

I received one with this address as well.

Reported as a service disruption on the status dashboard:

> We're investigating reports of an issue with Google Drive. We will provide more information shortly.

https://www.google.com/appsstatus#hl=en&v=issue&sid=4&iid=c7...

Things like this are bound to happen when you have centralized systems controlling everything with full control of the information (no zero-knowledge storage like email/document/communication encryption). You're essentially trusting one third party provider with everything in your life/business/organization.

Yes, it's phishing. More discussion: https://www.reddit.com/r/google/comments/692cr4/new_google_d...

Same here. Several emails so far from different seemingly random companies and individuals with clearly malicious Google Docs requests w/ a suspicious param in the oauth request in the link:

"&redirect_uri=3Dhttps%3A%2F%2Fgoogledocs.docscloud.info%2Fg.php&customparam=3Dcustomparam"

Seeing an alternate redirect redirect_uri= =3Dhttps%3A%2F%2Fgoogledocs.g-docs.win%2Fg.php

When can we expect a public statement regarding the phishing scam and the fallout? We all know it used our accounts to forward itself to everyone in our contact lists, but what about our emails? Have those also been forwarded/harvested? We need to know this to know how to react.

Just received one as well. Source is Hired.com - according to them:

https://cl.ly/1i0b0v110s0J

---

Hi Sergio,

If you receive a Hired email that says that someone from Hired has shared a Google Doc with you, please validate with the sender before clicking the link or doing anything else.

If you think your account may have been compromised, be sure to change your password immediately.

We apologize for this interruption to your day. Please let us know if you have any questions.

Thanks, The Hired team

Here's an interesting case that I encountered (~1:20pm maybe):

1) I clicked on the link on my phone's email app. It looked super believable since it was coming from a person I was expecting a Google Doc invite from. I allowed access to "Google Docs" and then the page hit a 502 gateway error.

2) I tried it again on my computer by logging in, and this time, when the page was loading (after I allowed access), I saw the website was not legitimate (based on the url) SO I immediately closed the tab.

Here's the interesting part: None of my contacts got a "Google Docs" invite from me - meaning I didn't "send" any mail. Any idea how I can see if the person behind this has my emails too via API requests?

Go to your Google account's security settings and see which apps have access. Revoke access from any app that is not needed or has the display name "Google Docs".

To see the list of apps connected to your Google Account: https://myaccount.google.com/permissions

Eagerly awaiting the response from Cloudflare detailing their response, since all of the domains associated with this so far appear to have been hosted with them, or at least fronted by their service.

I got one from "DocuSign": https://twitter.com/choxi/status/844949531896655872

The link went to a page that looked like Google Docs and asked for my Google login, but I noticed the domain was wrong so I didn't sign in. I tried the link again today and it looks like Chrome does flag it as a phishing site now.

Google is on it https://techcrunch.com/2017/05/03/heres-googles-official-sta...

My brother called me about 15 minutes ago to tell me this hit his student e-mail as well.

I'd be curious at the postmortem how quickly this thing spread.

Feels like "I love you" all over again.

Link for the lazy https://en.wikipedia.org/wiki/ILOVEYOU

As we saw one should not let users decide who can get access to their email account. Users are easily fooled. Google should review all applications wanting such access manually.

Though this is unrelated to the topic I think it would be good if Google reviewed apps permissions in Google Play too because users are bad at this.

G Suite admins: you can check for compromise by going to Reports > Token in the admin panel. A compromise looks like this: https://i.imgur.com/Dm0NNTn.png

The very same thing happened at my university. The sender is hhhhhhhhhhhhhhhh@mailinator.com

Um. The TO address is hhhhhh@mailinator.com. Not the sender.

G Suite customers have been asking for the ability to whitelist OAuth clients/scopes for their domains for years, for this exact reason. So far, Google hasn't really given a shit.

I guess that might finally change now.

There is also a Docusign phish email going around. I received a couple of them yesterday from mail2world, though signed by [company name].onmicrosoft.com for that user's business email address. They purported to be from people I knew.

I just received one of these as well. They seem to get their targets by compromising a single user and then by monitoring the people who are viewing the same Google Docs as the infected victim had in the past.

This happened to me. An unknown person from my organization shared a Google doc. I didn't open it, and replied by saying 'what is this about?'. He said he didn't send any gdocs :|

It sounds so simple, but the msn messenger era taught me to always follow up on a shared file for this reason (address book worms were a minor scourge in my circles at the time).

Did he click on a link telling him someone had shared a google doc with him?

The only tricky thing is not seeing these weird permissions. Google may block naming an app "Google Docs" but someone could always trick it with "Google Docs." or whatever

The bad thing about centralized internet is it makes some mail servers much juicer targets than the decentralized mail servers of old.

I decided gmail wasn't for me when I read they harvested your emails for ads. 1GB in 2004 sounded so enticing too!

If you are technically savvy and have access to a static IP, I highly recommend setting up postfix/dovecot and registering a domain. It's fairly straight forward for technical people. You can have it setup, soup to nuts in an hour or two. There's online docs everywhere.

It's probably not going to be as secure as a gmail, but it's a much smaller target. Most internet providers will give you a static for an extra $5 or so.

And then nobody ever receives your mail because the big mail servers don't trust you.

Yeah exactly - last time I went through the trouble of setting up my own e-mail I decided it just wasn't worth it between PTR records, dmarc, and SPF. It's possible, sure, but takes away all of the old-fashioned enjoyment of quickly setting up a Linux box with postfix and on your way you were.

I don't have that problem and my mail PTR doesn't reverse to my mail domain, it reverses to my ISP. Maybe because I have a really old domain.

Next up, prepare for the inbox onslaught of every CASB provider hawking their wares and telling you all about the googpocalypse and how they are uniquely prepared to solve it!

Just checked the malicious link again.

It looks like Google removed (at least one of) their access tokens

Checked the URL containing:

  googledocs.g-docs.win%2Fg.php

Any clues what this was trying to do? I suppose we have to wait for Google to publicise what went on once OAuth had been granted.

My guess spreading + password resets + searching for files that can be downloaded/later used for crypto blackmail?

I think we are going to see some of the worst large scale ransom attempts shortly. They also timed it perfectly afternoon on hump day when everyone in USA is just getting ready for / back from lunch.

so what should i tell my mom to avoid her Gmail being hacked in future same way? (it wasn't hacked since they had only English language audience this time)

don't click on unknown links which take you to Google login page and never approve access to your data in any dialog?

This is burning through our office right now. emailing all clients! diablo!

Is there mitigation against deploying exactly this attack another way?

Yeah @SwiftOnSecurity warned about this, lots of people/orgs affected

I got a few, then it died. Perhaps Google now recognizes this as spam.

Anyone know how far spread this is? it just Hit our school emails

Very. Convincing and nicely coded to spread.

Thankfully, the attack method means Google just has to shut off the app in their systems (which they appear to have done).

Looks really wide. It hit our org too. Though in our case, we don't use Google accounts internally, and hence it isn't a threat to us.

And it looks like Google is responding. The link in the emails no longer works, as the OAuth credentials have been revoked. I assume Google will be removing all the applicable app permission grants themselves.

there was a warning may 4 about a massive google doc phising scam check on.digg.com/2py2k5g

warning may 4 of massive google docs phising scam check on.digg.com/2py2k5g

I received it too

edit: accidentally double posted

double edit: 1. replied in above comment. 2. dunno. first time using HN, accidentally submitted twice when I was on comment posting cooldown I guess.

1. where did you get this 2. why did you post the link in 3 separate comments

Same here

Yes, it's all over.

until copycats start

Yes, same here.

My teacher said not to open this email.

amazing how large this is, our company just a massive wave of those. all from "internal" addresses.

We have an entire generation that's been trained by big tech companies to instantly click agree, share, like, etc., buttons. This is only going to get worse.

Reply on news.ycombinator.com