How to protect your website from cryptojacking attacks


via TNW

In the past month more than 4000 websites, including government websites in the US and UK, such as the UK’s Information Commissioner’s Office (ICO), were reported to be serving the CoinHive crypto miner to its users. CoinHive crypto miner is a JavaScript script that can be installed on any website and was designed to mine cryptocurrency at the expense of its users’ CPU power.

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

The ICO website, along with all the other affected websites, were loading a file from a third party website which is where the problem started. By loading JavaScript directly from a third party like this, these websites were basically inviting injection-style attacks. This isn’t too different from the alleged attack against jQuery’s CDN that RiskIQ claims was serving an exploit kit to every user of every website loading jQuery’s directly from their CDN.

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.

Whilst this is a good suggestion it doesn’t work very well if the dependency script needs to be updated regularly — which seems to be the case here. CSP is helpful for restricting external JavaScript (JS) from being loaded in a website, but is not meant to assure the integrity of scripts that it expects to load.

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

If there is no infallible way of stopping unintended code or markup from being injected into a website, then the next best thing would be to know about it and be able to react in real-time. By monitoring the Webpage DOM and JavaScript environment for any injection, the website is capable of reporting back to a webhook on the backend, allowing it to detect any changes made to itself, including 0-day threats and not just known injections.

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.

Conclusion

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.

As a final cautionary note we must emphasize that, in this case, the attackers only cared about using the end-users’ CPU to mine crypto. What could have happened if their motivations and intent were different? The ability to execute arbitrary JavaScript in the webpage would also allow the attacker to collect any sensitive information that the user accesses, such as credit card details or banking information, for example.

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?

3 Likes

Being in the industry, one of the best solutions for protecting web sites is a layer 7 firewall. We can’t all produce perfect code, especially in tight schedules that these ICO’s seem to have, where the site has to be available in an unrealistic timeframe.

A good layer 7 firewall like the Big-IP F5 ASM or even the Azure Application Gateway service can mitigate the most common attack vectors. It’s not a perfect solution, but the harder you make it for the attackers, the more likely they are to go attack someone else that doesn’t have it.

Can’t protect end users though from phishing or other types of attacks, but even if a company were to implement their site in Azure and make use of the Azure Security Centre functions with AI and ML, anomalies can be detected fairly quickly such as a majority of traffic originating from a single source for multiple users (ie: man in the middle type attack), with rules to autoblock.

The AlienVault Cloud SIEM is also a good alternative for those not in Azure.

I’m amazed that the majority of sites that have a big red target painted on them, are not using such technology that financial institutions have been using for years.

Maybe if an ICO has a “Question Time”, educated participants could ask:

What Layer 7 Firewall are you using?
What Security Incident Event Management services are you using?
What Risk Management procedures have you implemented?

Stay Fishy

3 Likes

Depending on how critical the site is, a couple white-hatters on staff is a must. Weekly application vulnerability tests and daily changelog auditing.

2 Likes

Is it possible to defend your site from cryptojacking attacks? I think it is unlikely, unless you have IT specialists who defend your site, and those must be very good. The easiest way is to turn to companies that deal with site security. Such companies exist. Usually, these companies also offer website creation or SEO promotion services, to make it easier for you to find. I know a site that promotes other sites https://www.internettrafficservice.com. Maybe they can help you with something.


💰 YEN · DCTV ·️ Bitcoin Lambo · 10 Days of Bitcoin ·️ CEO's Brainpan 🧠