Access Management , Anti-Phishing, DMARC , Digital Identity

Phishing Defense: Block OAuth Token Attacks

But OAuth Attack Defense Remains Tricky, Warns FireEye's Douglas Bienstock
Phishing Defense: Block OAuth Token Attacks
Sample of an OAuth phishing campaign spotted in 2017 by Cisco Talos.

Hacking played an unprecedented role in shaping the daily news cycle during the 2016 U.S. presidential election. Emails obtained by Russian-backed hackers from webmail inboxes, released in batches by WikiLeaks, dogged politicians and dominated the news as voters took to the polls.

See Also: Delivering Globally Consistent App Performance to the Hybrid Workforce

Despite the apparent impact of this data-dumping campaign, the tactics used to "hack" into victims' accounts were remarkably pedestrian. Attackers used phishing attacks to dupe victims into divulging login credentials to accounts for which they had not enabled two-factor authentication.

But security experts say attackers also employed another tactic for this campaign: collecting OAuth tokens. Unfortunately, this tactic appears to be difficult to defend against (see Attackers Unleash OAuth Worm via 'Google Docs' App).

OAuth is a protocol by which third-party applications can access a cloud-based account. The third-party application doesn't see a user's login credentials, but instead gets passed a token that gives it limited access to an account.

An example of a bogus application targeting OAuth tokens (Source: FireEye's Mandiant M-Trends 2017)

For example, granting OAuth access to a third-party application could enable it to view contacts, messages and calendar information in Gmail or Office 365. But OAuth doesn't only grant the ability to view information. In some cases, it can also allow an attacker to send emails from someone's account, which for an attacker could serve as an invaluable capability for facilitating further attacks.

For an OAuth compromise to work, an attacker only has to get a victim to click once to authorize third-party access. Once granted, the account access can persist unless revoked. That remains the case even if someone changes their password or enables two-factor authentication. Unfortunately for defenders, it can be very difficult to detect if a user has granted OAuth consent, for example, by scanning network traffic, because such authorization typically occurs over HTTPS.

Defending against regular phishing attacks is tough. Even well-educated, security-savvy users may not spot a spear-phishing attack that asks them to download an application or enter their username and password. But OAuth-related attacks can be even tricker to spot, says Douglas Bienstock, a senior consultant with FireEye.

OAuth Attack: One Click and You're Pwned

Here's how an OAuth phishing attack works: A hacker opens a developer account on a legitimate cloud platform and creates a malicious application. Using a well-known application development platform can lend the attacker's efforts an air of legitimacy, as opposed to hosting an app on a suspicious-looking domain.

Phishing email tied to the Fancy Bear hacking group (Source: Trend Micro)

As part of that process, the hacker creates a "scope" for the type of data the malicious application wants, such as email or a contacts list. An attacker also usually includes offline access into the scope, which will facilitate ongoing access to a user's data regardless of whether the user is logged into the web application.

The Fancy Bear phishing email used a fake but legitimate-looking application to attempt to trick victims into giving it OAuth access, thus giving the attackers access to their Google email account. (Source: Trend Micro)

"That means that they can access the user's data at any time," Bienstock says. "[Attackers] don't want to rely on the user to do anything."

The attacker then sends a link to a victim. This consent link leads to a page hosted on another site, such as Office 365, Bienstock says. Purposefully, the attacker configures the system to share little information about the app that's requesting access.

In the case of an attack using the Office 365 platform, the victim sees the name of the application - which is determined by the attacker - and what information it wants to access. For the attack to be successful, the only action a user has to take is to click "accept," Bienstock says.

"Once you click accept, that's it," Bienstock says. "And from that point on, the attacker has access to whatever data they requested."

Services Improve Their Controls

Big web services players haven't been sitting on the sidelines. Google and Microsoft have been coming up with ways to prevent users from falling for OAuth phishing attacks, but the scenario "is definitely not as easy as looking for traditional phishing," Bienstock says.

"Once you click accept, that's it. And from that point on, the attacker has access to whatever data they requested."
—Douglas Bienstock, FireEye

One improvement they're making is to make it easier for users to find the controls to revoke applications. It's easy for users to forget what application they've granted permissions to and remember to revoke them when the application is no longer needed.

"Not too long ago [the control] was definitely buried on both sites," Bienstock says.

Some providers have also made it easier for system administrators to investigate which apps are connecting to which accounts. With Office 365, Bienstock says any time users consent to give a new app access to their account, a notification gets sent to a unified audit log.

Beyond Office 365, Azure and Exchange also offer tools that allow administrators to review which applications have been granted OAuth access, FireEye's Bienstock says. The same goes for Google, which has improved its auditing tools. Administrators can also ramp up settings, for example, configuring a cloud environment to reject block all applications from connecting to their environment, even if a user consents.

Administrators: Start Logging

As that suggests, there are specific steps that security teams can take to help arrest the malicious use of OAuth. But such steps don't happen automatically.

David Stubley, who heads Edinburgh, Scotland-based security testing firm and consultancy 7 Elements, says that Office 365 logging must be explicitly enabled by administrators, which too many firms discover only after their users have been attacked and the organization suffers a breach.

Furthermore, Microsoft only stores logs for 90 days, meaning that security teams need to be regularly reviewing and downloading them for analysis.

"So start collecting logs, and keep hold of them," he tells Information Security Media Group. "Proactive monitoring of the logs is hugely valuable as well in identifying an attack at an earlier stage."

PwnAuth

Security teams should also be proactive about assessing their organization's vulnerability to OAuth attacks. To help, Bienstock developed a testing tool called PwnAuth. "Our goal with this tool was to give penetration testers and also organizations an easy-to-use platform where they could basically assess themselves," he says.

A screenshot showing the import of an application into PwnAuth (Source: FireEye)

PwnAuth lets users create and manage OAuth phishing campaigns, as well as test the ability to detect and respond to those campaigns. It takes time and a fair bit of skill to even develop a test application that can be used for an OAuth phish, Bienstock says.

PwnAuth simplifies the backend management. It has a user interface to manage access tokens and query APIs to collect data. PwnAuth is free to download on Github.

"It really lowers the bar for organizations of any size to be able to test themselves," he says.

FireEye has also created a PowerShell script for Office 365 that enumerates all of the applications running within their tenet. Bienstock says that will help administrators identify ones that are suspicious.

Executive Editor Mathew Schwartz also contributed to this article.


About the Author

Jeremy Kirk

Jeremy Kirk

Executive Editor, Security and Technology, ISMG

Kirk was executive editor for security and technology for Information Security Media Group. Reporting from Sydney, Australia, he created "The Ransomware Files" podcast, which tells the harrowing stories of IT pros who have fought back against ransomware.




Around the Network

Our website uses cookies. Cookies enable us to provide the best experience possible and help us understand how visitors use our website. By browsing bankinfosecurity.asia, you agree to our use of cookies.