Automating Extension Risk Assessment and Permissions

Browser extensions are a classic shadow IT concern. Assessing the reputation and security of a browser extension is crucial before installing it on a company computer, as extensions often have wide-ranging permissions that could be abused for data theft or other malicious activities.

In an open environment style company, extensions generate significant shadow IT risk that needs to be managed and addressed.

Let’s shed some light on the security challenges extensions present, and how you can use Torq to automate assessing the risk an extension may pose.

I decided to get into the crabs of a certain extension that helps to capture screen full pages. When browsing the extension’s official page, I went to its privacy page, and there I noticed a header saying: 

The developer has disclosed that it will not collect or use your data.

Oh yeah? Let’s go deeper into the privacy policy!

And there I found these two clauses:

When you access our Service, we may automatically collect non-personal data from you, such as web pages viewed, browser type, operating system, referring service, search information, device type, page views, usage and browsing habits on the Service and similar data.

and:

It is possible at times when collecting non-personal data through automatic means that we may unintentionally collect or receive personal data that is mixed in with the non-personal data

From this point, I checked more data properties that could help me decide if this should be removed or stay. Along with reviewing the privacy policy and extension’s web page, I checked a few additional parameters:

Installation method

How the extension was installed – NORMAL or SIDELOAD

• NORMAL – Extension installed directly by the user from the browser’s official extension store.
• SIDELOAD – Extension installed from a source outside of the browser’s official extension store.
• DEVELOPMENT – Extension that is being loaded directly into the browser for testing or development purposes, rather than being installed from a web store or other official distribution channel.

This particular extension was installed in a SIDELOAD fashion, which can pose a greater risk because it may not have undergone as stringent of a security review as it would have if it was in an official store.

Permissions

I also examined the extension’s permissions – what it allows an extension to do. The list of permissions included some dangerous ones:

• <all_urls> – Allows the extension to access all web pages. This is a very broad permission and is one of the most severe in terms of potential privacy and security risks.
• tabs – Gives the extension access to various properties of the browser’s tabs. This can include reading the URL, title, and other attributes of tabs and closing, moving, or creating new tabs.
• unlimitedStorage: Permits the extension to store more data than typically allowed in the browser’s local storage.
• system.display – Allows the extension to interact with the display properties of the system. This could include things like:

• Querying display metadata: Fetching information about connected displays, like their resolution, orientation, etc.
• Manipulating display settings: Changing settings such as screen resolution or orientation.
• Controlling display layout: Positioning screens in multi-display setups.
• scripting – Depends on what scripts are executed (someone mentioned supply-chain risk)

Vulnerability Scans

Using the free extension scanning tool CRXcavator can shed more light on extensions that may be considered in the risk assessment. Decision making data could be added through its API, such as:

• Vulnerabilities scan: Are there any vulnerable applicative components? Are there CISA KEV vulnerabilities?
• Risk Over Time: The extension’s overall risk, is it escalated?
• CSP (content security policy): More advanced insights
• Networking: Could be correlated with <all_urls>

Whois

Use Whois to find the extension’s website URL. This could help you understand more about an extension, like where the extension’s coming from, its domain’s age, and more. Whois revealed the particular extension’s domain age is 59 days.

Risk assessment time!

Given the insights I was able to gather, I can now assess the risk and make a decision.

1. Privacy policy shows Uncompromised information of the ability to collect PII. This has tremendous consequences on compliance and privacy settings and policy.
2. Considering permissions like <all_urls>, scripting, tabs – These generate risks affecting data privacy, compliance, supply-chain (scripting?), data-leak etc…
3. Considering the installation method – NORMAL installation type would at least have lowered the risk, which is not the case here, as this one was installed in SIDELOAD fashion – outside of the browser’s official extension store, which means, it wasn’t reviewed by Google.
4. Whois – domain age is very low – 59 – not always necessarily, but it could raise a concern that something fishy is going on.
5. Considering there are a few high vulnerabilities (with high EPSS).

After examining the findings above, I assume that the prevailing conclusion would be to remove the extension. However, in any environment there are many variables that can cause decision-makers to leave the extension installed.

How to Automate Extension Risk Assessment

All this work has to be done manually, right? That may be feasible if you have only a few extensions to investigate. Most organizations, however, have 20 times that many extensions. So I decided to use Torq to create workflows to automate the extension risk assessment.

Here’s how I did it:

1. Focus only on risky permissions. Extensions have dozens of permissions types. I used Torq’s Gen AI integration to assign a risk score (1 to 5) for each permission, considering their capabilities. Focusing on the most prominent permissions reduced the number of issues to address.
2. Let AI summarize the privacy policy with a prompt focusing on personal information, additional data processors, and what is essential to keep compliance governed.
3. Use WHOIS to grab the domain’s age and its activity status.
4. Extract the extension’s CVEs and use the power of automation to enrich and attach CISA KEV, EPSS, and CVSS metrics for better vulnerability management.
5. Correlate CVEs with your device vulnerabilities inventory to detect whether they are vulnerable.
6. Aggregate all insights into one case for the verdict:
   1. If the risk is tolerable, reach out to the employee to understand whether the extension is used and needed for work purposes.
   2. If the risk isn’t tolerable, reach out to the employee to inform them of the extension removal. Execute the MDM command to remove immediately.
   3. Exclude the extension from use.

Conclusion

The decision to remove or keep an extension may change under different circumstances and based on differing data. However, an extension that violates privacy compliance and provokes severe vulnerabilities shouldn’t be ignored.

As security pros, it’s our job to educate and raise awareness about extensions and the potential risk they pose, while also providing insight based on investigation and analysis. From there, organizations can make informed decisions whether they’ll allow a certain extension.