13 February 2018

Minimising the Effects of the Browsealoud Cryptocurrency Mining Attack

 

Sunday afternoon (11/02/2018) saw a popular web accessibility tool, Browsealoud, compromised by as-yet-unknown hackers, leading to the injection of foreign code into the service provided to many popular government websites. This code was designed not to steal and acquire personal data, but instead to hijack your PC or mobile phone processor to act on behalf of the hackers to mine for crypto-currencies. The exploited code was then unknowingly injected into the web browsers of those visiting sites using these tools. Further details and a more in-depth explanation can be found on Scott Helme’s blog.

Browsealoud acted with relative speed when disclosure of the exploit was revealed to them by security researchers. However, in the intervening time, thousands of websites were affected, leading to potentially tens of thousands of computers (PC and Mac) and mobile phones executing code that was supplied to them by nefarious means.

At Storm ID we take a very strict line on the security of the websites we build and manage, building security and telemetry into products to guard against, as well as mitigate, the effects of attacks such as this. In the case of a new attack vector, we ensure that we are gathering the sort of telemetry that allows us to understand the “What, Where, Why” of the attack, as well as quickly identifying ways to stop and protect against further damage from it.

In this case, on Sunday a number of sites under our remit were affected/ Due to the processes we have in place and the observations of our teams we were able to respond promptly to come to the aid of our clients. Don’t believe us? Here is a timeline:

11 Feb 2018 ~ 11:00
Browsealoud initialisation is compromised, with new code added to it that installs and executes a crypto-miner in affected browsers.

11 Feb 2018 14:00
Confirmation of the compromise
spreads on social media via UK security consultant Scott Helme.

11 Feb 2018 15:41
Article
in popular tech news site The Register reports the widespread effect of the exploit, with over 4000 sites affected so far.

11 Feb 2018 16:00
Various official UK government websites start going offline, replacing content with maintenance pages.

11 Feb 2018 ~16:00
TextHelp, the company behind the Browsealoud plugin takes its web and scripting services offline entirely.

11 Feb 2018 17:00
Storm ID begins investigation of the issue within our client sites, some sites benefitted from strict policies around content execution (CSP) and were completely unaffected. However, numerous 3rd party externally hosted plugins were more seriously affected and needed quicker, remedial action.

11 Feb 2018 17:30
Storm ID removes the affected Browsealoud scripts from client sites.

11 Feb 2018 18:00
Storm ID continues to monitor real-time telemetry from client sites watching for unexpected behaviour and additional foreign script dependencies, with requests to the 3rd party crypto-mining script reduced significantly, only those browsers still caching the script were showing up in telemetry.

11 Feb 2018 20:00
Traffic to our affected client sites remains within expected parameters. Most importantly, all sites are up and available for visitors, while other high-profile sites remain offline.

browsealoud app insights

Our WebOps team then relaxed and enjoyed the rest of their Sunday evening.

First thing on Monday morning updates were made to some sites to further mitigate a future incident. Where a Content Security Policy (CSP) was not directly mitigating the risk of background worker code injection, or the site’s infrastructure made a complex CSP require a longer-term introduction, we implemented a basic fix of adding the worker-src ‘none’ policy. This policy (where supported) will prevent any ServiceWorker, SharedWorker or Worker process starting within the browser from the site. See https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/worker-src.

Next we compiled some stats from our web telemetry about the incident, both to service any clients asking about the compromised scripts and to service you, the public with information about our response to the incident.

From the data samples and visualisations below, we can determine the following:

browsealoud metrics

  • The compromised script was first detected between 09:00 and 10:00 on 11th Feb 2018, this is earlier than TextHelp’s statement claiming the script was compromised at after 11:00
  • Then between the hours of 11:00 and 15:00, as traffic to the site increased the number of browsers requesting the crypto-miner through the compromised Browsealoud script jumps dramatically
  • Sometime between 15:00 and 17:00, according to TextHelp, they removed the compromised script and in fact disabled their entire service offering, resulting in a decrease in infection rate
  • At 16:30, our teams responded and removed Browsealoud scripts from affected sites, preventing any browser errors and allowing the services offered by our clients to continue.

Interestingly, we were still receiving a very small number of additional detections even after the removal of the Browsealoud code, there are a few possible reasons for this:

  1. Site visitors with web sessions that spanned the time the exploit was active that continued within the same browser session (i.e. didn’t close their browser) would have had the crypto-mining process still running in the background.
  2. Visitors that hit the website during the exploit would have downloaded and cached the modified Browsealoud Javascript locally in their browser, potentially with html caching happening on both the client and the server. A number of popular CMS frameworks will heavily cache content pages to reduce database load.

The metrics from the 13th Feb show the dramatic fall and subsequent end of detection following cache refreshes since the outbreak.

browsealoud app insights coinhive reduction day 2

Analysing the telemetry

Using the telemetry we have gathered we are able to add some forensic analysis to the types of users affected, for example:

The breakdown of affected devices by device type

browsealoud hack breakdown by device type

Breakdown by browser version

browsealoud browser breakdown

It’s interesting to note that the majority of these browsers support some form of background worker process (worker, service worker, shared worker) in their Javascript engine, with a larger portion using newer hardware from the last 18 months or so. This means that the capabilities of these devices and performance of CPUs will have had an affect on the hackers’ relative success to mine currency.

Geographic breakdown

As reported, the exploit targeted a service that is used by a large number of UK government and government-related websites, so the majority of detections were from site visitors based in the UK. However, it was not solely the UK that saw their browsers “crypto-jacked”.

Of the top 20 countries with visitors affected by the site, 70% of those were from the United Kingdom. There was a roughly even spread across Scotland, England, Wales, and Northern Ireland.

In conclusion

We can take away a number of things from this incident. First, that telemetry is king. Regardless of whether your site suffered from the incident or fully mitigated it, your telemetry will prove both the robustness of your processes and where they are lacking. In our case, we have Application Insights to thank.

Another big takeaway is that the power of Javascript running in your browser should not be underestimated. This can be of huge benefit to application developers and users alike, but as developers and stakeholders of these websites, we need to take responsibility to ensure the greatest levels of protection and reassurance possible for our end users. This means taking full advantage of security mechanisms like Content Security Policy (CSP), HTTPS and Script Resource Integrity (SRI).

Finally, we need to stop blindly trusting any code or script from a 3rd party external source if:

  • they do not outwardly and publicly endeavour to uphold security mechanisms
  • they are not able and willing to supply appropriate documentation and architectural notes to support the requirements of their scripts, such as what additional resources (script or other) they will be injecting into your website
  • they are not transparent and humble about any data, script or other breach that involves their products.

We will leave you with a quote from Troy Hunt’s blog (@troyhunt)

“Frankly, I think we all got off a bit lightly from today’s event. This was a very rudimentary and opportunistic attack. It was also highly visible and happened at one of the quietest periods of the week. Imagine for a moment if that really clever thought piece from last month about harvesting credit cards had have come to reality instead. Do read that – it’s enormously thought provoking – and it’s hard not to conclude that we totally dodged the proverbial bullet today. Question is, will it be enough to drive change in the way sites are creating dependencies on external scripts?

If you have any further concerns surrounding Sunday’s attack, please don’t hesitate to get in touch.

Search

Categories

Archives

Subscribe to Email Updates

Subscribe
 

We are a digital transformation consultancy. We help our clients succeed.

View Services