- Nov 5, 2011
- 5,855
How to protect your website from cryptojacking attacks
thenextweb.com: How to protect your website from cryptojacking attacks
by Pedro Fortuna - 2018/03/10
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 CDNthat 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 areavailable 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?
This article was co-written by Paulo Silva.
thenextweb.com: How to protect your website from cryptojacking attacks
by Pedro Fortuna - 2018/03/10
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 CDNthat 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 areavailable 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?
This article was co-written by Paulo Silva.
