Since at least 2011 [1] [2], information security researchers have attempted to raise awareness about the ease with which attackers could create seemingly legitimate apps and then trick users into granting them access to email and cloud service accounts. The Google OAuth worm that spread in May 2017 exploited this lack of validation, which affected more than one million G Suite users [3]. In the wake of this campaign, Google introduced validations around the choice of name for new OAuth clients.
While Google responded quickly to that specific attack, as of May 2017 it was still possible for malicious developers to submit any name for new OAuth clients — including scripts, third-party apps and extensions. Proofpoint SaaS threat researchers determined that it was possible to bypass those validations, serving a google OAuth client with a name of its choice from script.google[.]com.
Analysis
The original 2011 description of this technique anticipated a broad spectrum of app-based attacks that have arisen in the years since: “A malicious client developer registers his client application with a name that appears to represent a legitimate organization which resource owners are likely to trust” [1].
While the mitigations put in place after the May outbreak addressed that specific campaign, they did not address the root of the technique, which was based on the fact that Google allowed users to serve their own content with at URL at “script.google.com,” itself at least in part a factor of the openness of the OAuth clients space. Many app users -- organizations and individuals alike -- are not aware that, unlike mobile marketplaces (Play, App Store, etc.) which have evolved in terms of security to deploy different measures and processes to inspect applications submitted to them before allowing anyone to use them, the OAuth clients space has historically had no checks on the potential actions by developers. As a result, any developer can build any application, ask for any permissions they consider necessary, and send that application to anyone else -- and in the process serving it with a URL at script.google.com
The May 2017 OAuth worm campaign [3] alerted the broader public to the potential risks of these apps. The original attack included an identifiable URL, which led some solutions to try to mitigate the attack by blocking the return URL. However, this approach did not eliminate the exploit itself, as future versions could easily resist these countermeasures by not including a return URL, or by using a URL that is indistinguishable from any valid Google script URL. Instead, analyzing the app in order to defend against future attacks required factoring additional features such as the permissions, the app creator, the recipient (or victim), app name, context and others into the decision. For example, 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. This attribute, along with other parameters, gave the app the highest risk score Proofpoint SaaS Protection can possibly assign.
Following the OAuth worm outbreak, Proofpoint SaaS security researchers built on this analysis and discovered a vulnerability within Google Apps that allows an attacker to carry a similar attack 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 (Fig. 1).
Figure 1: G Suite application attack using technique reported by Proofpoint researchers
After Proofpoint researchers reported this issue to Google, Google took action to fix it the following day, and have since worked to make potential victims more aware of the risks from these apps. A July 19, 2017, update added a new ‘unverified app’ screen for new web applications and Apps Scripts that require verification, replacing the previous ‘error’ page that developers of unverified web apps receive today. This update will be followed in the coming months by expanding the verification process to existing apps. In a statement accompanying the update, a Google representative said, "We value researchers' work to help keep Google users safe. We've fixed the name spoofing vulnerability Proofpoint reported to us, and we recently announced new Google-wide phishing protections which apply to Apps Script as well."
Recommendations
The widespread adoption of SaaS applications has made this an attractive and as yet little-exploited vector for threat actors. Application threats will evolve rapidly as attackers look for new ways to use cloud-based applications and services to target individuals and organizations. To protect yourself and your organization against these kinds of attacks, we recommend that for every app you or your users want to install:
- Verify the authenticity of the app’s developer including whitelisting apps for your enterprise.
- Understand what the app is doing before you install it.
- If you installed a suspect, unverified app, revoke permission via https://myaccount.google.com/permissions?pli=1
There is also a new generation of solutions for defending SaaS applications and users from these rapidly evolving threats. Organizations should consider making these next-generation SaaS defense solutions part of the information security infrastructure in time to prepare for the next cycle of innovation by threat actors.
References
[1] October 4th, 2011, “Phishing with Client Application Name Spoofing”, https://www.ietf.org/mail-archive/web/oauth/current/msg07625.html
[2] September 8, 2014, “An Example of Poor Security Communication in the Google Auth Flow”, http://blog.andrewcantino.com/blog/2014/09/08/example-of-poor-security-communication-in-google-auth-flow/
[3] May 3rd, 2017, “Massive Google Docs phishing attack swept the internet today”, https://thenextweb.com/security/2017/05/03/massive-google-docs-phishing-attack-currently-sweeping-internet/#.tnw_gnbSrbKK