Google Docs Phishing Scam a Game Changer

Experts expect copycats that take advantage of passive authentication from third-party applications using standards such as OAuth.

The Google Doc phishing scam that conned over a million users this week illustrates how attackers cleverly respond to wider spread end-user awareness about how phishing attacks work.

The attack didn't ask users to enter credentials. Instead, it exhibited very few traditional phishing scam behaviors and couldn't have been detected by endpoint protections. Some researchers are calling this attack a "game changer" that could be just the start of a new wave of attacks that take advantage of third-party authentication connections rampant in the cloud services-based economy.

The attack tricked victims into clicking a link that gave attackers access to their Google Drive through OAuth authentication connections commonly used by third-party applications. The attackers did so by sending victims lure messages claiming to contain links to a shared Google Doc.

Instead of a legit document, the link actually initiates a process to give a phony app masquerading as "Google Docs" access to the user's Google account. If the user is already logged into Google, the connection routes that app into an OAuth permissions page asking the user to "Allow" access to the user's legitimate Google Drive.

"You aren't giving your Google credentials directly to the attacker. Rather, OAuth gives the attacker permissions to act on behalf of your account. You're on the real Google permissions page. OAuth is a legitimate way to give third-party applications access to your account. The application name is 'Google Docs,' which is fake but convincing," says Jordan Wright, R&D engineer for Duo Security. "So unless you know that Google Docs won't ask for your permissions, there is little you could use to determine that this was fake."

Wright says that the attack exhibits worm-like behavior, using previous victims as the supposed sender of new scam messages to lull victims into a sense of security.

The lure emails appear to come from Google Drive from a previous victim, making it difficult to detect as a fakeout, says Travis Smith, senior security researcher at Tripwire.

"Not only does this have a casual appearance of being legitimate, by being part of the official marketplace the link in the email went back directly to legitimate Google servers," says Smith. "For those that are trained to validate the link before clicking on it, this passes two of the common techniques the majority of internet users are trained to not click on every link they come across: 'Does it come from someone you trust and validate the link is going to a trusted source?'"

The only big tip-off is that many of the messages seem to have an suspicious account, [email protected], cc'd on the message, says John Bambenek, threat research manager at Fidelis Cybersecurity. He says the attack shows the glaring problem with OAuth, namely that it allows passive authentication.

"We talk about passwords and password security, but we don't really think a lot about these third-party apps we give access to," he says. "On Facebook and Twitter you fill out those dumb quizzes that give full access to everything in your Facebook account, but they're not thinking about handing that data to third parties. This is a case with the same dynamic."

It's a tricky situation for enterprise security professionals seeking to safeguard their users because there is no quick fix here, says Ravi Balupari in a recent analysis for Netskope.

"There has been no use of any malicious file for infecting, propagating, or data exfiltration. In this particular attack, all these phases have now transformed into using Google Gmail application and all the network traffic looks legitimate proving traditional network security devices incapable of protection," Balupari says. "There is absolutely no role of endpoint security products to detect and protect against such an attack."

Netskope's analysis found that a number of enterprise users across various industries ended up falling prey to this attack. Google worked to quickly block the attack, but there was a window of opportunity in that time between compromise and mitigation where emails, contacts, attachments and whatever else on a Google account could have been purloined, he warns.

"If an enterprise has identified that their users have granted access to the app in this attack, we recommend they conduct a full audit of the activities that were performed in Google Gmail after the permissions were granted to the app," Balupari writes.

New Rules

The larger lesson to be learned here is that as phishing awareness campaigns grow more successful, attackers aren't going to take their ball and go home. Instead, they're changing the rules of the game.

"This is somewhat of a game changer in the sense that there is little to point to as malicious," says Mounir Hahad, senior director of Cyphort Labs. "Any app out there can use Google’s API for authentication. For Google to respond to this kind of phishing attack is like a game of whack-a-mole. The widespread attacks will be relatively easy to identify and to respond to, but the more targeted ones will fly under the radar for a while."

Security professionals should consider this a proof-of-concept for OAuth phishing in the future.

According to researchers at Cisco, it is only a matter of time before copycat attacks against a wide range of cloud-based storage provider users starts cropping up. That's troubling considering current user behavior. According to the Dell End-User Security Survey, more than one in three employees will frequently open emails from unknown senders at work, and 56% of employees use public cloud services such as Google Drive, Dropbox, iCloud, and others for sharing or backing up their work.

While enterprises figure out how to deal with these threats technically, it is important to get users thinking critically not only about where they enter their credentials but also to whom - and to what - they assign permissions.

"This campaign is an example of how an attacker doesn’t need to ask you for your username and password to gain access to your account. When looking at something asking you for permissions, don't approve out of habit, take a look and think why you would need to give something those permissions," Wright says.

For example, a discerning user would know that Google Docs doesn't ask a user to provide access to Google Docs.

"It already has it, essentially, as that's the nature of signing up for the service," says Nathan Wenzler, chief security strategist at AsTech, a security consultancy. "A quick moment to check before clicking on the link may reveal that it's not going where you expect or where it advertises itself to go."

Additionally, enterprise IT needs to think about ways to mitigate these kinds of attacks in the future, including better segmentation and internal access controls to data, experts say.

Ericka Chickowski specializes in coverage of information technology and business innovation. She has focused on information security for the better part of a decade and regularly writes about the security industry as a contributor to Dark Reading. View Full Bio

PGP/GPG has been available now for years -- since the 90s. the problem of authentication in a digial net will not be solved until PGP/GPG is adopted as a General Practice. 2FA doesn't do it. ( read hack stories on ss7 this week ) . biometrics don't help -- the digital representation of your fingerprint can be stolen just like a copy of your SSN. but you can't change your fingerprint ( unless you wear a latex "forgery" fingerprint ) like you can your password

at least adopt PGP/GPG. these can be incorporated into (e.g.) Outlook, Thunderbird, Echelon, Claws. once configured ( IT Job ) -- it's easy to use ---- ALL THE TIME

to do it isn't trivial: you have to learn how to verify identifications ( "keys" in PGP/GPG ). alas, that is what this problem is all about.

as far as the o/s goes -- avoid using an o/s that is easily compromised. you know what i'm talking about

The endpoint under attack is the user. And users need an update that helps them protect against these types of attacks. If users think that knowing the sender means they can trust the email... they need an update (specific, relevant training), because that's just not true (e.g. have you never received an email from a trusted friend asking you to wire money because they were robbed while traveling abroad and now they're stuck?). Likewise, if you think you can trust the url you see in the address bar because it starts with https and has a green lock next to it, you need an update (e.g. Phishing with Unicode Domains).

Security awareness training doesn't cut it. It's too slow to create a "patch". Better offerings allow peers to report phish they detected, that their peers may have missed, but who clicked first? That software is even slower pushing new training to users (how often do you go through the security awareness training?). And all of that can only happen after the compromise has occurred (perhaps to you), been detected, analyzed, remediated, packaged, pushed, and applied(more training). And these are people we're talking about, so even if it's been pushed, they may not apply the new information pushed to them.

And that's the real problem... training does nothing the protect you if you don't apply it. Coupled with the recognition that secure web/email gateways don't cut it either ("There is absolutely no role of endpoint security products to detect and protect against such an attack"), and it's pretty clear that the only fix is to patch users and enforce the application their updated knowledge in the real world.

The users are the endpoint, and the security software has to run on them.

Most enterprises are using threat intel services, but many are still figuring out how to use the data they're collecting. In this Dark Reading survey we give you a look at what they're doing today - and where they hope to go.

A vulnerability in DB Manager version 3.0.1.0 and previous and PerformA version 3.0.0.0 and previous allows an authorized user with access to a privileged account on a BD Kiestra system (Kiestra TLA, Kiestra WCA, and InoqulA+ specimen processor) to issue SQL commands, which may result in data corrup...

A vulnerability in ReadA version 1.1.0.2 and previous allows an authorized user with access to a privileged account on a BD Kiestra system (Kiestra TLA, Kiestra WCA, and InoqulA+ specimen processor) to issue SQL commands, which may result in loss or corruption of data.

Stored cross-site scripting (XSS) vulnerability in the &quot;Site Name&quot; field found in the &quot;site&quot; tab under configurations in ClipperCMS 1.3.3 allows remote attackers to inject arbitrary web script or HTML via a crafted site name to the manager/processors/save_settings.processor.php f...

In Apache Batik 1.x before 1.10, when deserializing subclass of `AbstractDocument`, the class takes a string from the inputStream as the class name which then use it to call the no-arg constructor of the class. Fix was to check the class type before calling newInstance in deserialization.

Some Huawei smart phones with the versions before Berlin-L21HNC185B381; the versions before Prague-AL00AC00B223; the versions before Prague-AL00BC00B223; the versions before Prague-AL00CC00B223; the versions before Prague-L31C432B208; the versions before Prague-TL00AC01B223; the versions before Prag...