Democratizing Chrome Extension Security
As our portal to the internet, browsers represent what is likely the largest common attack surface across consumers and businesses alike. While browser security has progressed dramatically and modern browsers, such as Chrome, provide critical security features like automated updates and built-in protection against malicious content; the powerful capabilities of browser extensions can introduce critical risks that are often unclear to users.
Just like Google, Duo has deep interest in a secure and trustworthy browser and extension ecosystem. While the Chrome browser provides perhaps the most secure browsing experience available, it is often difficult for people and organizations to know which third-party extensions are compatible with their risk profile.
These extensions are often overlooked when it comes to assessing the security of user endpoints, even though they have increasing access to personal and corporate data with the widespread usage of Software-as-a-Service (SaaS) tools for presentations, taxes or email clients. To provide users and IT teams with actionable intelligence about Chrome extensions, Duo Labs is excited to announce the public beta of CRXcavator (rhymes with “excavator”), a free service that analyzes Chrome extensions and produces comprehensive security reports.
We’ll discuss the analysis and enterprise management features later in this post. But first, a history lesson.
Remember When 'You've Got Mail!' Was Exciting?
Gather round, children, and let me tell you a tale of the dark period that came to be known as the first Browser War. The year was 1997. Internet Explorer and Netscape Navigator were rapidly releasing new versions in an effort to one-up the features of the other. On one fateful October day, Microsoft published Internet Explorer 4.0. The browser world was never the same again. IE 4.0 provided a means for third-party developers to add entries to the right-click menu. Browsers previously didn’t provide any mechanism for users to customize their browser.
From this point, the range of functionality provided by toolbars, plugins and extensions exploded. Ever since these heady days of the young consumer internet, there have been several models for browser customization — from heavy-handed interfaces like Internet Explorer’s ActiveX and the Netscape Plugin API, to the menagerie of toolbars that we dreaded seeing on relatives’ computers.
Google Chrome is currently the world’s most widely used browser, with more than 60 percent of users using Chrome. From the beginning, Chrome has focused on developing a secure browsing experience and has led the way on numerous improvements within the browser ecosystem. We’ve written before about some of Chrome’s security features, such as the push to drop Flash.
As with all browsers that support third-party extensibility through extensions, applying a universal security experience can be challenging. Extensions have access to powerful functionality within the context of a browser, and as a result, there have been instances when this functionality has been abused by malicious actors. Not only do outright malicious extensions exist, but legitimate, benign extensions with vulnerable Javascript can be attacked by malicious content on a page unintentionally loaded by the user. The site the user is visiting may itself be legitimate, but could still end up serving as a conduit for an attack by an ad network that’s been duped into serving malicious content.
Additionally, like many other types of software available today, extension developers often use third-party libraries to construct extensions. These third-party libraries are regularly updated to address security vulnerabilities, but it is up to extension developers to ensure that these updates are included in extensions. If out-of-date libraries with known security vulnerabilities persist in extensions, it is possible that these vulnerabilities could be exploited by malicious code on sites that are visited.
The Chrome extension permission model asks the user to approve permissions, and people will often grant permissions to extensions without much consideration. Since the opportunity to grant permissions required by the extension first occurs during the install workflow, the prudent enterprise security team would want to evaluate every extension before allowing the user to finish the install flow. Note, however, that this cautious hypothetical security team would also need to have nearly infinite capabilities to be able to perform a thorough investigation of every extension.
Even if a security team has approved an extension, its functionality can change over time, often without notice. One scenario where this applies is if a malicious third party were to gain control of the extension, perhaps by buying it from the developer or compromising the developer’s account. The third party could add malicious code and push the new version out to existing users without triggering another security review. Manually reviewing every update to extensions allowed in an organization's domain is not feasible for most security teams.
What if a more realistic security team, when presented with a request to install a Chrome extension — abbreviated CRX, for “ChRome eXtension” — wanted to use automation to dig into this CRX?
Powerful, machine-driven digging, almost like a backhoe.
Or an excavator.
For CRXes.
A CRXcavator, if you will.
Neat Name, but What Does It Do?
The set of permissions an extension requests gives a good indicator of how concerned a reviewer might need to be, so CRXcavator is built on understanding the implications of the various permissions that are available for an extension to request. We have categorized and assigned an objective numerical risk score to each permission to help a security team have a metric to use when triaging extension analysis.
However, as we’ve discussed above, permissions alone are insufficient for fully understanding the security properties of an extension. CRXcavator addresses this by evaluating extensions from several other angles, including:
Building a list of sites that the extension’s code likely makes external requests to, which could potentially upload user data or download additional malicious code
Analyzing third-party Javascript libraries for vulnerabilities using RetireJS
Analyzing the Content Security Policy (CSP) of an extension to identify which domains an extension can communicate with. Domains that the CSP allows are checked against threat intelligence sources such as VirusTotal, ThreatExchange and SSL Labs
Listing externally included JavaScript files and letting the user view their source code from within the report
Scanning for potentially dangerous functions and possible “entry points” — points in the code where a potential bad actor could input data
Including extension metadata, such as number of users and links to its privacy policy and support page, if the developer provides them
Identifying related extensions, as determined by the Chrome Web Store, to help analysts find alternatives to suggest to a user if a requested extension seems shady or too risky
With all these perspectives included, a CRXcavator report equips a security operations analyst to make a well-informed decision about whether to allow or block an extension.
Here at Duo, however, we’re never satisfied with measuring just one thing at a time. So we scanned all of the extensions in the Chrome Web Store.
You Do Know That ‘All’ Is a Lot of Extensions, Right?
Yes! And there are a lot of them! There are over 180,000 items in the Chrome Web Store, including extensions, themes and Chrome apps — stand-alone web applications downloadable from the Web Store (Google explains apps vs. extensions in further depth). We ended up discovering and processing 120,463 extensions and apps. To ensure we had the resources to run complex analyses, CRXcavator is built upon high-speed, embarrassingly parallel functions on a Function as a Service platform. AWS Lambda allows us to process and frequently re-process the entire public Chrome Web Store. These Lambda functions feed into a database that is not only up-to-date, but also deeply historic, and more so by the hour.
By analyzing the properties of the extensions we scan, we start to gain insight into what the Web Store ecosystem actually looks like, from perspectives of permission overreach, incomplete or broken CSPs and developer behavior, such as configuring optional metadata.
The State of the Web Store
Google has taken great strides towards making the Web Store more secure. They recently announced that they are giving users control over host permissions while also improving their extension review process. Google recently discussed improvements to their process for extension review, which definitely raises the bar for a malicious extension author. CRXcavator fills the gap between what Google deems safe enough for distribution via the Web Store, and what users or businesses deem safe for their own use based on their own individual risk preferences.
Duo scanned 120,463 Chrome extensions and apps in January 2019 and found that many developers are not consistently ensuring the security of their third-party libraries, reducing their access to user data to the minimum needed for the extension to function, or providing information about the privacy implications of their extensions.
Specifically, Duo found that 38,289 extensions (31.8 percent) use third-party libraries that contain publicly known vulnerabilities. Another area where we hope to see extensions (including apps) improve for administrators is ensuring that privacy policies and support sites are available and easily accessible. Currently, 102,029 extensions (84.7 percent) do not have a privacy policy listed, and 93,080 (77.3 percent) do not have a support site listed. These are easy fixes that will drastically improve the security and transparency for administrators evaluating extensions for their organizations.
Of the 95k extensions in the Web Store that support Content Security Policies at the time of our analysis, we found that 74,403 (78.3 percent) do not have a CSP defined and, beyond that, 94,059 extensions (99 percent) do not have default-src or connect-src in the CSP defined. These are the parts of the CSP that give developers the ability to restrict which external resources the extensions can access and where the extensions can send the data they collect.
CRXcavator scans the full Chrome Web Store on an ongoing basis, making it easier than ever for analysts to review and stay updated on the extensions their organization has allowed or are considering allowing. Duo is proud to collaborate with Google as a Chrome Enterprise customer ourselves, helping to bridge the gap of transparency and security for administrators in the same boat.
To the Enterprise and Beyond!
We’re excited about all the extension analyzation capabilities included in CRXcavator, but let’s not forget why we started down this road in the first place. We needed to be able to support an enterprise-scale default-deny/explicit-allow extension policy, and thus CRXcavator has an extensive suite of ready-to-go enterprise features. Users of the platform can create accounts and link themselves to a group. Enterprises can use these groups to manage their Chrome extension allowlist, set threat intelligence keys and more. Once an organization has imported their allowed extensions, administrators can navigate to the Dashboard page to view their highest risk and most-recently updated extensions.
Not only can CRXcavator help organizations manage their allowlist, but it can also help them gain visibility into what extensions are currently used throughout their fleet. With the helper CRXcavator Gatherer Chrome extension deployed, endpoints will send data about what specific extensions and versions are being used and tie it back to the user signed into the browser. This allows organizations to know exactly what extensions are being used, who is using them and how much risk is brought to the organization by their users’ extensions. As a Chrome extension itself, CRXcavator Gatherer works on any OS that allows Chrome to install extensions, such as macOS, Windows and ChromeOS.
CRXcavator’s extension analysis capabilities, combined with enforcement controls in G Suite, empower organizations to more easily achieve parity for Chromebooks in terms of application allow-listing practices, as compared to other desktop operating systems.
A drawback to denying extensions by default and using an allowlist is the amount of time spent responding to requests and analyzing extensions. One workflow that is likely familiar to many organizations asks users to email requests to a support queue with a valid business justification. To streamline this process, we developed another feature into CRXcavator Gatherer: User Extension Requesting. When a user visits the install screen for an extension that is not already whitelisted in their domain, a notification will appear telling them that the extension requires approval and they can “click here” to request it.
They will then be brought to a page where they can enter their business justification and request approval. Requests are sent to a group in CRXcavator and can be reviewed by adminstrators in the tool. To provide flexible integration with ticket queues and chat platforms, CRXcavator can also post requests to a webhook of the administrator’s choice.
Automation is the name of the game when it comes to modern security tooling, which is why we made CRXcavator 100 percent API first. Everything in the web frontend is based on a corresponding API that’s exposed to all users.
Getting to the CRX of the Matter
CRXcavator can help users, enterprises and developers improve their Chrome extension security hygiene. We’re excited to finally show this tool to the world, and we want to hear from you if it changes how you approach browser extension security. It is currently a public beta release, so there are probably some bugs that sneaked past our awesome private beta testers. Contact us at support@crxcavator.io with any bug reports and ideas, and, just as importantly, success stories.
CRXcavator Infographic
For more information on CRXcavator, check out our infographic: