Linkedin Tag

Back to blog

The BrowseAloud Supply-Chain Attack: A Case Study in Cryptojacking

Monday, June 10th, 2024

Updated June 17th, 2024
Carlo D'Agnolo's profile picture

Carlo D'Agnolo

In February 2018, over 4,000 websites, including high-profile government bodies like the UK's Information Commissioner’s Office (ICO), fell victim to the BrowseAloud attack. This was not just another cybersecurity breach; it was a potent reminder of the hidden dangers of third-party scripts in our increasingly interconnected digital ecosystems.

What Happened in the BrowseAloud Attack?

A seemingly benign third-party service called BrowseAloud, which helps websites enhance accessibility by converting text to speech, was compromised. Malicious actors injected the CoinHive cryptocurrency mining script into BrowseAloud’s codebase. This script was then unwittingly executed by the browsers of thousands of visitors across various websites, using their devices to mine cryptocurrency without consent.

Cryptocurrency mining involves the process of solving complex mathematical problems to validate transactions on the blockchain, a task that traditionally requires substantial computational resources. However, with the advent of scripts like CoinHive, this process was brought into the browsers of unsuspecting users. Here's how it works:

  1. JavaScript Execution: CoinHive and similar scripts are written in JavaScript, which can be executed within any standard web browser. This makes it incredibly easy to deploy on a wide scale. Probably the most important aspect of web supply chain attacks and what c/side secures.
  2. Non-consensual Use of Resources: Unlike typical mining that requires explicit consent and dedicated hardware, browser-based mining uses the CPU resources of any visitor to an infected site. The script runs as long as the webpage is open, making it less noticeable but potentially harmful to user devices due to increased power consumption and wear.
  3. Profitability for Attackers: Each hijacked device contributes a small amount of mining power. However, when scaled across thousands of devices, this can generate significant cryptocurrency for attackers.

The Impact Of This Attack

This attack affected more than 4,000 websites, including government and educational sites, exposing thousands of users to cryptojacking without their knowledge. No personal data was stolen, but the implications were significant nonetheless. Websites had to be taken down, causing service disruptions and reputational damage. The attackers exploited a common but risky practice: automatic acceptance of third-party script updates. This incident highlighted the need for rigorous monitoring and management of third-party components, which many organizations had overlooked.

This is what c/side prevents against, both in monitoring the change and the possibility of autonomously taking action in preventing the malicious code from being loaded in the browser of the user.

In other words, this would very likely not have happened if c/side was around and deployed back then. You can get started with c/side to secure yourself against any kind of 3rd-party script attack for free.

What Happened to BrowseAloud After?

After the cryptojacking attack, BrowseAloud's parent company, Texthelp, took immediate action by temporarily taking the service offline to mitigate the issue and conduct a thorough security review. The incident led to increased awareness about the security of third-party services and the need for ongoing vigilance and regular security audits.

BrowseAloud returned online with enhanced security measures and a commitment to preventing such incidents in the future. The attack also sparked a broader discussion among web service providers about the importance of securing and monitoring third-party scripts rigorously.

The Fate of CoinHive

CoinHive, on the other hand, faced a different trajectory. Initially launched as a legitimate tool to monetize website content without ads by using visitors' CPU power to mine cryptocurrency, CoinHive quickly became associated with unauthorized cryptojacking. The negative connotation and the misuse of the script in various malicious attacks led to significant scrutiny.

The viability of the service was further challenged by the decline in the value of Monero and the increasing difficulty in mining it profitably. Consequently, CoinHive announced its shutdown in March 2019, citing economic inviability as the primary reason for its closure.

The domain CoinHive.com is now owned by industry expert Troy Hunt. It’s safe, and hosts his view on securing against similar attacks and cryptojacking in general. undefined

Similar to how we now own the Baways.com domain and have turned it into an educational website.

undefined

Using old domains previously used like these can cause other issues, as Troy Hunt recently experienced.

Now back to his recommendations on topic, his approach involves using CSP to make browsers disregard any commands from any domain that isn’t explicitly allowed. In his case, after securing the CoinHive domain, he implemented a CSP which ensures that even if malicious scripts are injected, they wouldn’t be executed because they wouldn't be coming from an allowed list of domains.

In our view, this approach is good, but not enough. In short, CSPs shouldn’t be the only security measure against 3rd-party JavaScript attacks. Our comparison page gives a great overview of the features we have implemented on top of CSPs to provide the best possible safety regarding 3rd-party script breaches.

We believe the key lies in analyzing the entire script before it reaches the user's browser. Naturally, this presents a few challenges, for which we have engineered solutions. You can read more about this view, and how we secure 3rd-party scripts here.