“Sign In With Google” Phishing Attack: What Happened & What You Should Do

google permi

A cunning attack that lasted only 1 hour exposed roughly 1 million users and businesses to extremely serious risk of identity theft, stolen money, enormous business liability and more — all made possible by user trust in a commonly-used feature in one of the web’s most well-known brands: Sign in with Google.

 

How did it happen? How was it fixed? What does it mean for users? And what do you need to do? Read on for definitive answers.

Sign In With Google: Great User Experience, Easy to Implement

You’ve seen them before: the ubiquitous “Sign In With Google” buttons inviting you to easily sign into a web application using your Google account.

From a user’s perspective, it’s quick, simple, reliable, and free of the hassle of having to ever remember a username and password unique to the application or service you want to log into. All you have to have is a Google account.

It’s also a plus for developers and administrators. They want to provide these benefits to users, as long as it’s relatively easy. And because incorporating Google Sign-In requires only a few extra steps, the user benefits often outweigh the costs.

Security professionals, however, know there are always risks. And those risks were exposed for all to see on May 3, 2017.

How Sign In With Google Works

Web applications allow you to sign in using your Google account in a very straightforward manner. First, the app shows a login screen with a prominent Sign In With Google button. After pressing the button, you must enter your Google account email address and password. Google then shows a screen listing the permissions that the app is requesting and asking for access. Press the Allow button, and the app signs you in.

Clever But Evil Hackers Exploit a Weakness

Sign In With Google may be simple, but it was not secure.

On the screen listing the permissions requested by the app, the name of the app is also shown. But we all know the truth: most users will click Allow without reading the permissions, much less the app name. So…if hackers could make the name appear as if it were a common, credible application, they could probably get users to grant permissions. And so they did.

Image credit: @zachlatta https://twitter.com/zachlatta/status/859843151757955072

The hackers started with a phishing campaign, sending emails to thousands of users. Individuals with Google accounts as well as business users in companies using G Suite are familiar with apps such as Google Docs and Google Sheets. The phishing emails looked almost perfect. The subject line named a person, probably someone the user would know, who “shared a document on Google Docs with you.” The only content of the email was a sentence saying that person “has invited you to view the following document” followed by a familiar-looking blue button saying “Open in Docs.”

Pressing that button took the user to a screen that not only looks like Google, it is Google. Specifically, it’s accounts.google.com, the login portal for Google accounts. The user was presented with a list of their Google accounts, from which they would select an account to access the shared document.

Next, Google presented the user with a screen showing the permissions the app was requesting, as well as the name of the app: “Google Docs.” The app name certainly looked legitimate. Only by clicking on it could the user see that the developer was someone with a gmail account, and the URL of the app was https://googledocs.g-docs.win — clearly not google.com. For someone being careful, this URL would scream “fake” and alarm bells would go off. But most users aren’t careful, and accepted the permission requests.

Permissions Are The Key

The “Google Docs” application requested 2 permissions:

  • Read, send, delete, and manage your email
  • Manage your contacts

These permissions may seem underwhelming, because they mention things users normally do. But on closer inspection, the permissions are very dangerous.

The first part of the first permission would allow the app to read all email messages. Let that sink in for a moment. Imagine the app downloading the user’s entire email database — everything ever sent or received. There’s a staggering amount of confidential information in there. The hacker could use that for identity theft, even using the ability to read new emails when he or she requested password resets to take over the user’s accounts. An obvious next step would be to drain financial accounts of funds.

Other permissions just add to the misery. The malicious Google Docs app creator could dump all the user’s contacts, send compromising emails (some of which would virally spread Google Docs invitations), even intentionally delete materials unless a ransom was paid.

Businesses Using G Suite Face Even More Risk

And for businesses using G Suite, the stakes were even higher. The hacker would get not just personal information, but also business information: customer lists, deal terms, product roadmaps — anything of value would be easily accessible.

And that is just the direct loss. Imagine the legal liability a business would face from violating NDAs and contract agreements with customers, vendors, partners, employees and contractors.

Google’s Actions Largely Sealed This Hole

Google said that the vulnerability was exposed for only about one hour, and affected “fewer than 0.1% of Gmail users.” But with about 1 billion users worldwide, that translates to about 1 million affected users. The day of the attack, Google removed fake pages and applications, and pushed user-protection updates through Safe Browsing, Gmail, Google Cloud Platform, and other counter-abuse systems.

Eight days after the attack, Google implemented policies that make it much tougher for this to happen again. Google began requiring that all app names be unique and not copy other app names. They added steps to the app publishing process to better detect and block spoofed or misleading applications.

Some apps are now subject to manual review, where app developers must justify their requests for permissions to access user data. Users trying to access some apps that request permissions with too much exposure will trigger a screen saying “This app isn’t verified” to make it clear that the app has not yet been cleared by Google.

this app isnt verified

More Is Required To Solve The Risk Problem

Google’s actions make it much more difficult for this particular attack to happen again.

But permissions remain one of the most well-hidden yet dangerous risk factors facing every organization.

There are many, many web applications, as well as Chrome extensions, that request dangerous permissions. Since we know users are not cautious, there is an almost 100% chance that within your organization, users have installed apps and extensions that grant dangerous permissions to access their — and your — data.

It is critical that you examine these permissions to identify apps, extensions, services and the like that are requesting too much, and exposing your organization to serious risk.

There is a solution: Alpin will show you all these apps and all the permissions they have been granted. Alpin categorizes them based on degree of danger, allowing you to browse from most dangerous to least dangerous, or to search out specific risks.

Try Alpin today, for free. In less than 60 seconds, you will see the entire landscape of permissions, so you can immediately cut off avenues of attack.

Benjamin Soulier