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:
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.
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.
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 CasesPlaying 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.
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.