OAuth Identity Attack — Are your Extensions Affected?
A malicious variant of Cyberhaven’s browser extension (v24.10.4) was uploaded to the Chrome Store on Christmas Day. According to Cyberhaven, this compromised version can allow “sensitive information, including authenticated sessions and cookies , to be exfiltrated to the attacker’s domain”. The extension remained available for download on the Chrome Store for over 30 hours before the issue was identified and removed. Cyberhaven manages data loss for enterprises via its browser extension, with at least 400,000 users on its platform based on Chrome Store.
This attack was part of a widespread campaign targeting Chrome extension developers. Just one week before the Cyberhaven breach, SquareX’s researchers disclosed the very same attack on social media, including a video revealing the phishing email and bogus app used to trick developers into giving attackers access to their Chrome Store account. This breach is likely part of a large-scale phishing campaign targeted at popular extension providers, including security vendors. Thus, we urge enterprises and individuals alike to be especially cautious when installing or updating any Chrome extensions published after December 2024.
This article will detail the attack mechanism for this particular exploit, examine several variants to the attack from the past and discuss some best practices enterprises can use to safeguard against supply chain attacks.
Cyberhaven OAuth Attack Mechanism — What Happened?
In short, the breach occurred when a Cyberhaven employee unknowingly provided the attacker with access to the company’s Chrome Store account. This allowed the attacker to upload a malicious version of the extension to Cyberhaven’s official account. Aimed at security-trained professionals from reputable cyber companies, this attack was highly sophisticated, employing several clever tactics to deceive the user. Here’s a step-by-step breakdown of how the breach unfolded:
Step 1 — Email Address Collection
First, the attacker had to gather a list of targets. Lucky for them, Chrome Store publicly displays contact information of the extension’s developer. This allows them to easily create a hit list of cybersecurity extensions with a given number of downloads and ratings. Moreover, as these contact details are typically used for bug reporting, emails are often automatically routed to developers who may lack the security awareness to detect sophisticated attacks.
Step 2 — Phishing Email
The attacker then sends an email to the hit list, impersonating the Chrome Store. The email contains an urgent message claiming that the developer’s extension is “at risk of being removed from the Chrome Web Store” due to a violation of the store’s policy. There is then an urgent call to action for the user to accept these policies to continue publishing on Chrome Store.
This email looks very similar to any SaaS policy update notification, and details the relevant extension name, ID and policy violation. Thus, this email may not raise suspicion among employees unfamiliar with the attack.
Step 3 — Gaining Access to Extension via OAuth
Once the employee clicks on the “Go To Policy” button, they are redirected to a Google OAuth page for a “Privacy Policy Extension”. If one clicks on the name, a developer info pop-up will actually indicate that the creator is [email protected] and that choosing an account will redirect them to https://app.checkpolicy.site. These are all clear signs that should raise suspicion. Unfortunately, most employees are unlikely to click into the developer info box in the first place, especially as they are under the belief that the email came from a trusted source.
Note: Even if the employee did run a quick check on the URL, no popular threat feeds would have flagged this site as malicious due to its novelness. This is a classic example of a zero day attack.
Step 4 — Uploading a Malicious Extension Update
Once the attacker gains access to the developer’s Chrome Store account, they have the necessary permissions to edit, update and publish any extensions associated with the account. This is an extremely effective way to distribute malware as it allows attackers to leverage a trusted brand and disguise the attack as a regular software update. In this case, the malware contained cookie session stealers that allowed the attacker to exfiltrate data from multiple SaaS applications used by Cyberhaven end users.
A Blast from the Past — Attack Variations
This is not the first time an attack exploiting extension developers occurred. Many of these extensions have up to millions of users that have no reason to doubt patches pushed by their software vendors, creating a hugely asymmetric and attractive opportunity for attackers. Similar OAuth-based attacks have been used to hijack employee emails by mimicking a GoogleDocs file sharing notification.
Other attackers have also used a similar methodology to steal cloud data from file storage sites like GoogleDrive and OneDrive. These attacks, classed as consent phishing, host their applications on legitimate providers like Microsoft to deceive users into allowing permissions for the app to read and access confidential company data. Once granted, these permissions are extremely challenging to track and reverse, especially if it involves shadow SaaS applications that the security team are not even aware of.
Preventing Extension OAuth Based Attacks — Best Practices
The first step to mitigating supply chain vulnerabilities is to recognize that supply chain risks are a shared responsibility between vendors and customers. Enterprises often depend on the vendor to mitigate security risks from an expanded attack surface when adopting new software. Sophisticated attacks like these can happen to anyone, including those at the forefront of security technology. Unfortunately, all it takes is for one unknowing employee to fall prey to an attacker’s trickery and as we have seen, these attacks are only getting more difficult to spot.
Thus, where humans are unreliable, it is critical to use the right technologies to safeguard against these attacks. Due to the complexity of the OAuth exploit, only a browser native solution will have the full context on user interaction and extension permissions required to stop the attack in its tracks. Re-emphasizing the theme of shared responsibility, below are the ways in which SquareX’s Browser Detection and Response (BDR) could have prevented the attack both at the vendor and customer level.
For the Vendor
The Policy Privacy Extension involved in this attack is an example of a shadow SaaS app. It is not uncommon for employees to breeze through SSO and OAuth authorization screens without truly understanding the permissions they are granting these third party apps. SquareX’s BDR can block or warn the use of unauthorized apps that request risky OAuth permissions — in this case the ability to edit, update and publish extensions on the developer’s Chrome Store account. This way, employees can still experience the user experience and productivity benefits of applications leveraging OAuth, as long as it does not involve risky permissions that could lead to security breaches.
For the Customer
Ideally, software vendors should have the right browser security tools in place to prevent their extensions from being compromised. However, it is critical for end customers to also have the right solutions in place to detect any abnormalities from their vendor’s extensions should they fall prey to an attack. SquareX’s BDR is able to monitor all active extensions across the organization, automatically blocking any suspicious extensions. This includes extensions that are already whitelisted by the organization, but may have a malicious update containing a new, risky extension. Similarly, extensions with a sudden surge in negative reviews, are sideloaded or unpopular can also be blocked. This approach not only prevents installation of risky extensions in the first place, but can also identify initially extensions that turn malicious due to intent or compromise.
Introducing the BDR
SquareX’s Browser Detection and Response solution extends beyond managing browser extensions and identities. SquareX’s industry-first BDR solution detects, mitigates and threat-hunt client-side web attacks targeting employees in real time. The solution comes in the form of a lightweight browser extension that can be deployed to existing browsers via a simple group policy.
We believe that there are three key components required when it comes to securing the browser:
- Web Threat Detection & Mitigation including identity attacks, malicious sites & scripts, malicious browser extensions and malicious files
- Browser DLP including genAI DLP, clipboard DLP, file DLP and insider attacks
- Private App Access to provide secure access to web applications and private apps via the browser, including for BYOD/unmanaged devices
How could SquareX’s BDR have blocked this attack?
For the Vendor — Cyberhaven
In this scenario, Cyberhaven could have prevented their employee from granting Privacy Policy Extension the OAuth authorization to update Cyberhaven’s extension on Chrome store with three simple steps:
- Import or create a list of authorized SaaS applications on SquareX’s platform
- Create a policy that blocks OAuth for any applications outside the authorized list
- Apply policy to all employees or select user groups (e.g. developers) as required
The video below contains a live demonstration of the OAuth extension attack, as well as how SquareX’s BDR can be used to block the attack.
https://medium.com/media/41d847da520dc1aa5706a8eeea11212f/href
For the Customers
Assuming extension vendors are compromised, end customers can protect themselves by implementing the following policy:
- Block extensions containing risky permissions
Additionally, other example policies that could be added to safeguard against other suspicious extensions include:
- Block sideloaded extensions
- Block extensions with over 30% negative reviews on Chrome store
- Block unpopular extensions with less than 100,000 users
- Block extensions containing “ChatGPT” in the title or description
A wider range of extension based policies, including video demos, can be viewed on our website.
OAuth Identity Attack — Are your Extensions Affected? was originally published in SquareX Labs on Medium, where people are continuing the conversation by highlighting and responding to this story.
The post OAuth Identity Attack — Are your Extensions Affected? appeared first on Security Boulevard.
SquareX
Source: Security Boulevard
Source Link: https://securityboulevard.com/2024/12/oauth-identity-attack-are-your-extensions-affected/