Clearly this was not the intention of any of the companies affected. Indeed, the ICO is an independent authority set up in the UK to uphold information rights in the public interest, promoting openness by public bodies and data privacy for individuals. This ‘cryptojacking’ assault was a direct result of a third party provider (TextHelp) used in the ICO’s website being compromised, without the knowledge of website owners nor the third party provider. This incident was initially flagged by security expert Scott Helme after a tip-off from another security expert, Ian Trump.
How the attack unfolded
This particular approach is very appealing to attackers who are able to compromise users at scale by attacking dependencies being loaded dynamically. Even if you believe third party providers to be reliable, they can still be unknowingly compromised, effectively allowing attackers to use them as a vehicle for malicious injections.
What can be done?
One possible approach, as pointed out by Scott Helme, is to add Subresource integrity (SRI) attributes to the script elements loading the external scripts. He even suggests complementing this by employing Content Security Policy (CSP)’s to enforce the use of SRI tags.
Whitelist-based CSP is really hard to carry out and skilled attackers will probably find a way around since it does not prevent the injection of code from external sources that are in the whitelisted domains, for example. Regarding CSP, as a word of caution, any header-based web security control can be disarmed by a browser extension.
Mitigation using real-time monitoring of the webpage
Security teams can then be alerted about what was injected and, in some cases, even remove the malware injection on the spot until a permanent solution is found, limiting the number of affected users. This approach is extremely useful because not only does it identify what was injected, but where. It is then possible to figure out how the injection was inserted in the first place and to take the appropriate measures to fix the situation permanently. This method is quicker than others as it also detects 0-day threats.
The maliciously modified script is not being served anymore from browsealoud.com, but it was possible to replicate the attack by forcing the infected file (instead of the current one) into the ICO’s website. At the same time, an Embedded Agent was manually injected into the ICO’s website to monitor the webpage DOM. The goal here was to grab the output of the malicious script landing on the ICO’s webpage DOM and demonstrate how to mitigate the attack successfully. The results are available here.
Solutions that monitor the webpage in real-time are an efficient alternative when CSP and SRI are falling short. They are able to search for DOM modifications, JS poisoning attacks, JS event-hijacking and XSS and report back to the backend, allowing the web application to react immediately.
With the growing popularity (and value) of cryptocurrencies, the focus of these attacks is now cryptojacking and attackers are looking to steal computer’s cycles as a way to get cash. CBS’s Showtime and The Pirate Bay attacks are other examples.
This latest incident involving TextHelp merely serves to demonstrate how appealing this approach is for attackers — especially if they are able to compromise third party dependencies and therefore target many websites with a single blow. We will undoubtedly see more of these attacks in the future as Cryptojacking continues to make headlines.
The attacker could also completely modify the DOM and trick the user into giving away their credentials or perform actions that are not in their best interest. Would the ICO and other organizations be able and ready to tackle a similar threat, thereby protecting their users and maintaining their reputation?
This article was co-written by Paulo Silva.