Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Vulnerabilities / Threats

3/22/2021
06:40 PM
Connect Directly
Twitter
LinkedIn
RSS
E-Mail
100%
0%

Researchers Discover Two Dozen Malicious Chrome Extensions

Extensions are being used to serve up unwanted adds, steal data, and divert users to malicious sites, Cato Networks says.

Researchers at Cato Networks have discovered two dozen malicious Google Chrome browser extensions and 40 associated malicious domains that are being used to introduce adware on victim systems, steal credentials, or quietly redirect victims to malware distribution sites.

The security vendor discovered the extensions on networks belonging to hundreds of its customers and found that they were not being flagged as malicious by endpoint protection tools and threat intelligence systems.

Related Content:

Malicious Code Injected via Google Chrome Extension Highlights App Risks

Special Report: Building an Effective Cybersecurity Incident Response Team

New From The Edge: 3 Classes of Account Fraud That Can Cost Your Company Big Time

Etay Maor, senior director of security strategy at Cato Networks, says such extensions can pose risks for enterprise organizations. "Security researchers have found extensions performing malicious activity that ranged from stealing usernames and passwords to stealing financial data," he says. The theft of personal and corporate data is a real threat for organizations, and there have already been multiple instances of extensions doing so, he notes.

While malicious extensions are an issue with all browsers, it's especially significant with Chrome because of how widely used the browser is, Maor says. It's hard to say what proportion of the overall Chrome extensions currently available are malicious. It's important to note that just a relatively small number of malicious extensions are needed to infect millions of Internet users, he says.

One case in point was Awake Security's discovery last June of over 100 malicious Google Chrome extensions that were being used as part of a massive global campaign to steal credentials, take screenshots, and carry out other malicious activity. Awake Security estimated that there were at least 32 million downloads of the malicious extensions. In February 2020, Google removed some 500 problematic Chrome extensions from its official Chrome Web Store after being tipped off to the problem by security researchers. Some 1.7 million users were believed affected in that incident.

In a soon-to-be-released report, Cato says it analyzed five days of network data collected from customer networks to see if it could identify evidence of extensions communicating with command-and-control servers. The company basically correlated Chrome browser extension behavior with network traffic to preliminarily classify extensions as benign or malicious. The exercise resulted in Cato identifying 97 out of 551 unique extensions on customer networks as being potentially problematic. Researchers from the company then manually inspected each extension to see if they could definitively classify them as malicious or benign. That process in turn ended up identifying 87 extensions as being definitely malicious. Out of that number, 24 had not been previously identified as being malicious.

Multiple Methods
Google, like other browser makers, has implemented multiple measures to vet the security of extensions uploaded to its Chrome store. According to Cato, the process of uploading an extension to Google's official store can take weeks and involves both automated and manual reviews of the extension code and activity. Chrome's standard security settings also block installations of extensions sourced from outside of Chrome Web Store. Even so, Cato's research showed threat actors employing at least four different approaches to introduce malicious extensions into users' browsers.

One common way is to sneak it in via extension installation files from unofficial stores. "Some developers prefer not to go through the Google’s set of installation restrictions and offer their extensions for download from unofficial stores," Maor says. While not all extensions on unofficial sites are malicious, it's still a risk to get Chrome extensions from anywhere but Google's official Chrome Web Store. Attackers have found ways to bypass Chrome's blocking of unofficial extensions by using iframes, a mechanism for embedding documents and other content inside a webpage, he says.

In other instances, an attacker may sneak malicious code into a Chrome browser extension update. Maor points to several ways this can happen. A developer, for instance, might sell code to a third party that later injects malicious code into it. Or a developer might initially release a benign browser that performs as advertised but then gets updated with malicious properties once it gets popular. Developers could also get scammed into giving up control of their account to an attacker. "In almost every instance, the app initially is not harmful but rather updated later with malicious code, as it is easier to bypass security checks that occur at the Google store that way," Maor says.

Adversaries have also been known to purchase rights to a legitimate Chrome extension and then modify it later with malicious code or to use a malicious extension to download additional malicious extensions.

Jai Vijayan is a seasoned technology reporter with over 20 years of experience in IT trade journalism. He was most recently a Senior Editor at Computerworld, where he covered information security and data privacy issues for the publication. Over the course of his 20-year ... View Full Bio
 

Recommended Reading:

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
News
Inside the Ransomware Campaigns Targeting Exchange Servers
Kelly Sheridan, Staff Editor, Dark Reading,  4/2/2021
Commentary
Beyond MITRE ATT&CK: The Case for a New Cyber Kill Chain
Rik Turner, Principal Analyst, Infrastructure Solutions, Omdia,  3/30/2021
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
2021 Top Enterprise IT Trends
We've identified the key trends that are poised to impact the IT landscape in 2021. Find out why they're important and how they will affect you today!
Flash Poll
How Enterprises are Developing Secure Applications
How Enterprises are Developing Secure Applications
Recent breaches of third-party apps are driving many organizations to think harder about the security of their off-the-shelf software as they continue to move left in secure software development practices.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2015-20001
PUBLISHED: 2021-04-11
In the standard library in Rust before 1.2.0, BinaryHeap is not panic-safe. The binary heap is left in an inconsistent state when the comparison of generic elements inside sift_up or sift_down_range panics. This bug leads to a drop of zeroed memory as an arbitrary type, which can result in a memory ...
CVE-2020-36317
PUBLISHED: 2021-04-11
In the standard library in Rust before 1.49.0, String::retain() function has a panic safety problem. It allows creation of a non-UTF-8 Rust string when the provided closure panics. This bug could result in a memory safety violation when other string APIs assume that UTF-8 encoding is used on the sam...
CVE-2020-36318
PUBLISHED: 2021-04-11
In the standard library in Rust before 1.49.0, VecDeque::make_contiguous has a bug that pops the same element more than once under certain condition. This bug could result in a use-after-free or double free.
CVE-2021-28875
PUBLISHED: 2021-04-11
In the standard library in Rust before 1.50.0, read_to_end() does not validate the return value from Read in an unsafe context. This bug could lead to a buffer overflow.
CVE-2021-28876
PUBLISHED: 2021-04-11
In the standard library in Rust before 1.52.0, the Zip implementation has a panic safety issue. It calls __iterator_get_unchecked() more than once for the same index when the underlying iterator panics (in certain conditions). This bug could lead to a memory safety violation due to an unmet safety r...