Earlier today, the latest OAuth-based attack went viral. The attack starts with a simple email inviting the target to collaborate on a Google Doc from a known contact:
Once the target clicks the “Open in Docs” link, he or she is redirected to a Google OAuth 2.0 page to authorize the “Google Docs” application. This is a fake application that is spoofing Google Docs.
The application requests access to the target’s email and contacts, which provides an avenue to organically — and virally — expand.
Reviewing the application details, the app developer name appears as “firstname.lastname@example.org”:
After the user clicks to allow the fake Google Docs application to have permissions to their email and contacts, the attacker can use this information to spread virally.
For further technical details, see the Cisco TALOS post.
Background on OAuth Attacks
OAuth is an industry standard protocol introduced as a secure way for web applications and services to connect without requiring users to share their account credentials with those apps, universally adopted by almost all web-based applications and platforms – including consumer as well as enterprise applications such as Google Apps, Office 365, Salesforce, LinkedIn and many others.
As more businesses adopt cloud platforms, the employees authorize apps using their corporate credentials, giving these apps programmatic (API) access to their corporate data, introducing millions of back doors into corporate environments.
Research by Cisco Cloudlock indicates that the number of OAuth-connected cloud applications has exploded from 5,500 three years ago to more than 276,000 applications this year. The same research indicates organizations having an average of 1,050 unique OAuth-enabled applications in their environment. Over one in four of the applications are considered high-risk due to the extremely high level of permissions users grant to the application, often including full access to the files within their cloud environment and the ability to modify, delete, and externalize files.
Security implications of the massive explosion of connected applications and their associated risk postures are exacerbated by the fact that organizations don’t really understand the actual countermeasures very well yet.
- Misconception #1: Changing passwords will address the issue. Once an OAuth-based app is granted permissions, changing account passwords will have no effect. The OAuth token must be revoked.
- Misconception #2: Enabling multi-factor authentication will mitigate the risk. Authenticated users grant permissions to applications via OAuth. The applications themselves are not required to have a second factor once the user has granted permissions.
- Misconception #3: OAuth-based attacks are Google only. Many other platforms (such as Microsoft Azure AD) are also susceptible to the same techniques.
What Can Be Done?
Individual users of cloud applications
Individuals should go into their Google accounts’ security settings and revoke permissions to apps they do not recognize or trust. They should also never grant permissions to applications that request excessive access.
Organizations who have adopted cloud applications
Organizations need to develop a high-level strategy as well as a specific Application Use Policy to decide how they will whitelist or ban applications, and share this vision with their end users. Automating workflows, identifying, whitelisting, banning and revoking apps in near real time has become more important than ever.
OAuth-based attacks bypass all standard security layers including NGFWs, SWGs, SSOs, Multi-Factor Authentication, and more. Organizations must:
- Gain Visibility. Organizations need to understand their OAuth connected application risk. This requires knowing which users have connected applications via OAuth, the permissions those apps have been granted, and how risky each application is.
- Gain Control. Organizations must take control of their OAuth application ecosystem. The exact process may vary by organization, from revoking all unsanctioned applications, to focusing risky applications and those with excessive permissions, to allowing all applications but being ready to respond quickly and globally across the organization in the event of a virally-spreading malicious app.
Cisco Cloudlock has been defending against malicious and excessively privileged OAuth-connected applications for years. Cisco Cloudlock provides intelligence to assess application risk, including the access scope of the application, a risk level score, and the Community Trust Rating (CTR), a crowdsourced security risk rating of third-party applications based on anonymized user data (how many users have trusted versus banned the application).
For further information on how Cisco Cloudlock can help with OAuth-based attacks, watch our video here.
Update on May 12, 2017:
Update on June 27, 2017:
We’ve just released our OAuth Risk Assessment tool that demonstrates how easy it is for a 3rd party application to get access to your data. Check it out here to understand where OAuth risk lies. Contact email@example.com to have one of our CyberLab experts walk through this with you.