Browser Security: The Worst Code Injections and How They Work

In a new report titled Malicious Injections: The Tip of the Spear for Browser Threats, researchers with security firm RiskIQ predict that browser-based attacks will be a significant portion of the threat landscape for years to come, and will continue to cause major problems.

What do these attacks all have in common? Malicious injects targeting locally installed browsers. “Internet browsers are proving an invaluable attack vector for criminals,” the report concludes.

The point of injecting malicious scripts is to have the local browser dutifully execute code on the user’s machine. Attackers aim either to inject a piece of script into a web page directly or to inject a remote script (resources) into the page.

The report documents the top six techniques that they use to achieve either direct and remote injects:

Sponsorships Available

Sponsorships Available

Sponsorships Available

Tacking it On

This is the most common method of adding malicious code to a page and can be done by injecting a malicious script in a <script> tag on the page or injecting a malicious script tag for a remote script resource.

Third-party Supply Chains

Attackers can breach a third-party script to access all the sites on which it runs, all at once. This far-reaching access can help to spread the attack across many fronts simultaneously.

Top/Bottom

A common technique for injecting scripts is positional, through “top” or “bottom” injection. Attackers gain access to the static JavaScript resources on a server by some method and then inject their malicious script at the very end or beginning of the script in the file. And this approach is not chosen out of laziness.

The concept here is that if you do not interfere with the script ’s execution scope and stay in the global scope, even so-called “secure” traditional browsers will play along and execute the malicious script once it is included on a page.

This technique, which was used in last year’s large-scale compromise of customer data at British Airways, is extremely simple; RiskIQ says is the most common technique they observe in the wild. Because of its simplicity, there are many options for attackers to automate this style of attack allowing them to scale up their operations.

Executable Scope

This technique is more advanced. The attackers’ code inspects and analyzes JavaScript libraries to then inject the malicious code in a JavaScript library. This means it will always be executed, regardless of how the library itself is used.

One example in the report shows an injection that simply adds a new remote script to load in. However, how it was injected is intriguing. The attackers injected the code just before the default initialization portion of this JavaScript library. There are more variants of this technique, but they all do the same thing: find a default executed code path and inject the malicious script there.

Function Inlining

This technique is similar to executable scope except, rather than using libraries, it picks JavaScript functions in the page that are executed as part of the global scope when the page loads.

In another example in the report, the attackers used the inlining technique to load their malicious script along with the regular Google Analytics code.

RFC Edge Cases

Playing off how browsers deal with dynamically generated elements like images can help attackers.

Assume the attackers create an image element. It won’t be actually appended to the page DOM in any way, which means it’s not technically part of the website. This is because browsers do not preload script files if an element is created, only binary objects, i.e. non-executable ‘type’.

As a result, the browser security feature won’t interpret an image as malicious, only scripts. That means the browser will still load the image, regardless of whether it is part of the page.

The problem here is that images can still be used to perform attacks. The attacker’s scheme needs nothing more than a beacon to the image location so they can see their (potential) victims pass by. This very technique was used for a SMB credential harvesting attack which just needed an image to be available. The RiskIQ report documents the code written in Chrome that was used to signal via image location that the image was present and could enable their attack.

Source: RiskIQ

The injection techniques covered in the report are six of the many ways that most browsers can be tricked into executing malicious code or allow tokens to be established that can then be used in an attack.

All of this, I should add, is not your problem anymore if you’re using a secure cloud browser such as Silo. Because in that case, remote browser isolation ensures that all content is processed in an isolated cloud container, and all web code is kept off your local machine.

Larry Loeb has been online since uucp "bang" addressing (where the world existed relative to !decvax) and served as editor of the Macintosh Exchange on BIX and the VARBusiness Exchange. He wrote for BYTE magazine, was a senior editor for the launch of WebWeek, and authored books on the Secure Electronic Transaction Internet protocol and "Hack Proofing XML" (his latest). Larry currently writes about cybersecurity for Security Now.