Browser vulnerabilities via extensions

Recent researchers from University of Wisconsin - Madison provided an experiment to show how user's identity can be stolen via browser's extensions.

Here is the original research if you want to read the whole study.

I spent an amount to time to read through all of them and give you some key points in case you don’t want to read them in details.

What is a browser extension?

A browser extension is a software module for customizing a web browser. Browsers typically allow users to install a variety of extensions, including user interface modifications, cookie management, ad blocking, and the custom scripting and styling of web pages. (Wikipedia).

Why are they dangerous?

They are dangerous because they can execute malicious scripts to perform unexpected activities, for example, steal user’s identity.

Let’s take a look at below code snippet which allows to collect every key press on a web page.

Once hackers have everything you typed, they can try to detect the real user’s identity, for instance, username and password.

How it works

Typically, there are 2 ways for browser’s extension to execute script:

• Static Code Attack

• Dynamic Code Attack

In Static Code Attacks, the malicious code is statically present in the extensions’ source code. The researchers also pointed out that these kind of attacks are almost impractical due to Static Code Analysis during Review Process.

Dynamic Code Attacks involve retrieving the malicious code from an external server and then executing it into the target webpage. Below code could demonstrate the way to inject malicious remote code to perform a phishing attack.

Usually, hackers will try to obfuscate code to prevent detection against dynamic analysis, such as remaining dormant and capturing data after a certain interval.

Dynamic code attacks primarily exploit the remote code execution privileges provided to the extension. The remote code can not be vetted using code analysis methods, and thus are harder to detect as the injected code cannot be analyzed during the review process.

What did Google Chrome do?

Realizing the problems, Google Chrome always try hard to prevent these kind of attacks. They introduced Manifest V3 (MV3) back in December 2020 bringing substantial changes in privacy, security, and performance. The MV3 disallowing extensions to modify network requests in real-time, closing a major loophole. It also prohibited the execution of remotely hosted code and the use of eval statements.

OK, now what?

Despite the changes in MV3, the researchers still manage to find a way to publish a malicious extension to Chrome web store which allow them to collect user’s identity by accessing DOM tree. Unlike iframes, which have isolated DOM trees, extensions face no restrictions once permitted to operate on a page, resulting in a broad attack surface.

Above figure shows they can extract login detail from Google and Facebook via DOM tree.

During the research to implement a POC for this theory, they proposed 3 types of attacks:

• Source Extraction Attack exploits the vulnerability where the sensitive values

  are present in the source code of the HTML.

• Value Extraction Attack involves identifying and selecting the target input field

• Element Substitution Attack is a JavaScript-based obfuscation prevents access to the information using the .value function.

In order to bypass the review process on Google Chrome web store they tried to hide the extension’s malicious aspects by disguising it as a GPT-based assistant offering ChatGPT-like functions on websites.

Root causes?

They showed some root causes for this vulnerability.

• Improper Application of Security Principles: Once an extension is allowed to run on a page, it has unrestricted access to all elements.

• Trade-off Between Usability and Security: websites trust browsers to protect the data, however, browsers use to accept trade-off from extensions to have better usability.

• Websites’ Bad Practices

• Flaws in Online Review Process of Extensions

Solutions?

In order to mitigate the risks from these kind of attacks, researchers proposes following solutions:

Bolt On

They provide a JavaScript package that the developers can use to protect sensitive input fields. Specifically, we introduce a new HTMLInputElement type, SecureInput that leverages WeakMaps to store the sensitive information as private data. Developers can simply import the secure-input library and designate any input they wish to secure as follows

Built In

The browser itself should have mechanism to alert users whenever any JavaScript function accesses any password fields.

In order to access the sensitive data, the malicious script needs to select the element, thus the browser could intercept this access flow, and alert users when the access originates from JavaScript or browser extension.