Security Experts:

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.

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.

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

view counter