Connect with us

Hi, what are you looking for?

SecurityWeekSecurityWeek

Application Security

Google Takes Second Swing at OAuth Worm

Mitigations put in place by Google in May 2017 to help block phishing attacks such as the recent OAuth worm weren’t enough to completely mitigate the issue, as Google’s platform still allowed malicious OAuth clients to be submitted under deceiving names, Proofpoint security researchers say.

Mitigations put in place by Google in May 2017 to help block phishing attacks such as the recent OAuth worm weren’t enough to completely mitigate the issue, as Google’s platform still allowed malicious OAuth clients to be submitted under deceiving names, Proofpoint security researchers say.

The OAuth worm was possible because malicious developers could create seemingly legitimate apps and trick users into granting access to email and cloud service accounts. Lack of validation allowed an attacker to impersonate Google Docs and impacted more than one million G Suite users.

The attack, however, prompted Google to tighten OAuth rules and introduce validations around the choice of name for new apps. The company updated policies and announced enforcement on OAuth applications in an attempt to prevent similar attacks from happening.

Proofpoint now explains that while Google was able to respond to the attack fast, it didn’t address the issue properly, and malicious developers were still able “to submit any name for new OAuth clients — including scripts, third-party apps and extensions.” The security company discovered that Google’s validations could be bypassed to serve “a Google OAuth client with a name of its choice from script.google[.]com.”

The issue, Proofpoint says, was that Google resolved the vulnerability that made the May attack possible, but didn’t address the root of the technique. As a result, it was still possible for users “to serve their own content with a URL at ‘script.google.com’, itself at least in part a factor of the openness of the OAuth clients space.”

Because the OAuth clients space historically had no checks on the actions developers could perform, it allowed the creation of any application and the request of any permission considered necessary. App developers were also allowed to send their applications to anyone else and serve them with a URL at script.google.com in the process.

In addition to alerting the public on the risk these applications pose, the May 2017 attack could also be mitigated because it included an identifiable URL. This, however, didn’t eliminate the exploit itself, allowing future versions to avoid the mitigations by not including a return URL or by using a URL that can’t be distinguished from a valid Google script URL.

“[The] OAuth worm employed a rare email permission often used only by select email clients (e.g. Outlook) in combination with another permission. That specific combination was unique and not used by any other OAuth client Proofpoint has previously examined,” the security researchers say.

Advertisement. Scroll to continue reading.

Effective defense would build on the analysis of the app to determine permissions, app creator, recipient (or victim), app name, context, and other features. By performing such analysis, Proofpoint discovered another flaw within Google Apps and says that an attacker could exploit it to carry a similar attack as the OAuth worm, despite the mitigations put in place by Google.

“In this case, our researchers were able to create an app called ‘Google Docs’ or ‘Google Drive’, bypassing some of the protections Google introduced following the May 2017 attack. Using this technique, an attacker can then launch a similar phishing campaign, but this time with links that are less suspicious — and more potentially enticing — than possible in the May campaign,” Proofpoint says.

The security company reported the issue to Google, which resolved it within a day. The Internet giant released an update to alert users on new web applications and Apps Scripts that require verification. Previously, an ‘error’ page was displayed for unverified web apps. In the following months, the verification process will be expanded to existing applications as well.

A Google spokesperson confirmed to SecurityWeek that the issue was addressed in last week’s update.

Related: Google Warns Users of Potentially Risky Web Apps

Related: Google Tightens OAuth Rules to Combat Phishing

Written By

Ionut Arghire is an international correspondent for SecurityWeek.

Click to comment

Trending

Daily Briefing Newsletter

Subscribe to the SecurityWeek Email Briefing to stay informed on the latest threats, trends, and technology, along with insightful columns from industry experts.

Understand how to go beyond effectively communicating new security strategies and recommendations.

Register

Join us for an in depth exploration of the critical nature of software and vendor supply chain security issues with a focus on understanding how attacks against identity infrastructure come with major cascading effects.

Register

Expert Insights

Related Content

Application Security

Cycode, a startup that provides solutions for protecting software source code, emerged from stealth mode on Tuesday with $4.6 million in seed funding.

Identity & Access

Zero trust is not a replacement for identity and access management (IAM), but is the extension of IAM principles from people to everyone and...

CISO Strategy

Okta is blaming the recent hack of its support system on an employee who logged into a personal Google account on a company-managed laptop.

Compliance

Government agencies in the United States have made progress in the implementation of the DMARC standard in response to a Department of Homeland Security...

Email Security

Many Fortune 500, FTSE 100 and ASX 100 companies have failed to properly implement the DMARC standard, exposing their customers and partners to phishing...

Funding/M&A

The private equity firm merges the newly acquired ForgeRock with Ping Identity, combining two of the biggest names in enterprise IAM market.

Identity & Access

Hackers rarely hack in anymore. They log in using stolen, weak, default, or otherwise compromised credentials. That’s why it’s so critical to break the...