(No Ratings Yet)

Loading...

• Facebook
• Twitter
• LinkedIn
• Mail

May 5, 2017 Comments closed

“Google Docs” Phishing Attack Highlights Flaws with Google’s OAuth Permissions

in Hashing Out Cyber Security

One Click To Give An App Total Control Of Your Account

Earlier this week, a massive phishing campaign targeted Google users with a malicious app named “Google Docs” and attempted to trick them into giving the app legitimate access to their account through Google’s OAuth API.

The attack spread incredibly quickly – the first known phishing email was sent at 2:27pm EST and about an hour later Google had stopped the attack by revoking the malicious app’s API token. As many as a million accounts may have been compromised in that small window.

The attack is being referred to as “dynamite phishing” because of how many users it affected and it’s totally indiscriminate targets. The name also emphasizes the difference in tactics compared to “spearphishing,” an extremely narrow and tailored attack, which has been used in high-profile hacks of political figures.

Now that the dust has settled, there is no indication the attack had malicious intent – code found by researchers suggests the primary purpose was replicating and spreading itself. It is entirely possible that emails and contact lists were downloaded and are being saved for a later use, but we likely won’t know until the next attack is underway.

Harm aside, this incident has raised a lot of questions about the OAuth standard and Google’s implementation of it.

Looking at the attack, it is clear that there were multiple failings in Google’s design of their permission page, as well as bigger picture issues with one-click access to your personal data.

Why does Google allow apps to give themselves the same name as legitimate Google services?

The primary reason this attack was successful was because users were directed to a legitimate Google OAuth page asking them to give permission to “Google Docs.” Hiding the app’s author behind a hyperlink didn’t help either.

What everyday user is going to be suspicious of a Google.com page asking “Google Docs” to access your Google account?

This was possible because Google does not perform any sort of validation of the app name, icon, or URL, allowing anyone to mimic legitimate services. Any popular app or service could be easily spoofed.

Working in the world of URLs, I know how difficult it can be to prevent spoofing. But let’s start by blocking literal strings such as “Google Docs” – or anything with “Google” or any similar spellings. There is no legitimate reason third-party apps need to be using “Google” in their name – and this attack has shown just how effective this tactic is.

To add insult to injury, Motherboard has found that this exact attack was reported to Google and publicly posted as a concept more than 6 years ago.

Why does Google not identify first-party services?

Google allows you to manage the apps connected to your account through a page that lists each app, the permissions it has, and the date it was first authorized.

What they don’t show you is any clear identification of the app’s author. We know that the malicious “Google Docs” app was published by the account “eugene.pupov@gmail.com.” But that information is not shown on the permissions management page, nor is there any indicator the app is published by a third-party.

Below is a screenshot of my account, where “Google Chrome” is listed as a connected app because I have signed into my browser with my account. How do I tell if this is legitimate or another malicious app?

Why is there no way to differentiate between this first-party service provided by Google itself and other apps?

Why are Google OAuth permissions so broad?

An app that wants to connect to your Gmail account has 10 different permissions it can request. These permissions come with a varying degree of access. They can essentially get full control over your email with the permission to “read, send, delete, and manage your email.”

The most restrictive permission only gives  access to add, modify, and delete mail labels (or maybe its “manage basic mail settings” – but after 30 minutes of Googling I couldn’t figure out what that encompassed).

But what do all of 10 of the permissions have in common? They are all scoped to the entire Gmail account. My Gmail inbox goes back to 2006 – before I was 18.

I can only imagine the terrible security hygiene I had then and what sort of personal information has accumulated in emails and drafts over more than a decade of inbox history. Should I be deleting old emails? Yes, probably. But expecting every end-user to manage their inbox is never going to be a reasonable solution here.

The depth of access is the problem here. No app should be able to get total read/write access to your entire email account through one button press.

It is clear that there are major problems with Google’s handling of permissions and third-party access.

Some security professionals have been taking the outrage further and saying OAuth is the problem. But given the size of this attack, is it not impressive that Google was able to stop everything by revoking a single app’s OAuth token?

I am not convinced the issue is inherent to OAuth or similar systems. The problem is that Google seems to have done the bare minimum when it comes ensuring their OAuth ecosystem is safe, with little consideration put into reasonable permissions and clear UI.

• #Google
• #phishing