ICO, NHS & Thousands Of Other Websites Hijacked For Crypto Mining

Earlier this week reports came out that thousands of high-profile websites fell victim to a major hack. Websites including the ICO, NHS and countless other government websites were hijacked for crypto mining. Flaunt Digital CTO, Jamie, discusses how this happened and what businesses can do to avoid this happening to them. Subscribe to our YouTube channel for more videos like this.

See below for the full video transcription.

VIDEO TRANSCRIPTION

Hi. I’m Jamie. I’m the CTO at Flaunt Digital, and today we’re just going to be talking about an issue that’s happened that’s been covered really widely in the media, and it’s to do with the hack that’s taken place on loads of really, really prominent websites. And in fact, it’s taken place on over 4000 websites, it’s estimated at the moment.

But there’s some really, really significant entities in there, including the ICO, which is the Information Commissioner’s Office in the U.K. It’s also affected the NHS and loads and loads of government websites, so ‘.gov.uk’ sites. And the reason why it’s affected these government sites in particular is because the third party that’s been compromised is providing a resource to these government websites.

And what that does is it provides assistive technologies in terms of screen readers and helping slight visual impairments, dyslexia, etc. And obviously, these type of entities have got a lot of guidelines to meet when it comes to accessibility.

So, you can see why not only has it affected a wide number of sites, but specifically these huge, huge government websites, which is a little bit ironic because the ICO is, sort of, where you go to get your data protection data. So, you can search companies on there and find out if they’ve got a data protection license, etc. So, for those guys themselves to get compromised, and they actually had to turn the website off for a little bit. For those guys to get compromised is massive, massive news in the tech industry.

So, I’m just going to explain a little bit about what happened and how you can prevent this happening to your website. So, what happened is, there’s a third-party provider, as I mentioned, and they’re actually a company called Texthelp. And they’ve got a service called Browsealoud. And like I said, that’s an assistive technology to help people with vision impairments, dyslexia, etc., browse a website easily.

Now, what this is is a paid service. And what they do is they provide a Javascript library that a developer embeds in the website that enables these features. So what you get with a lot of these paid external services, is they’ll insist on you hotlinking the Javascript file from their website. And the reason why they do this is so they can keep a handle on who’s requesting this file, have they got a paid license. And it also helps them with tracking and seeing how many requests it’s getting and how busy the site is, etc.

So, if you were to go and self-host this file, they would lose the ability to track these things, which is obviously quite important for a paid service. This is in contrast to things like jQuery, Font Awesome, etc., which offer a free service, or they offer a partial free service. And they quite often encourage you to host the files yourself. And the reason why they want you to do that is because this is going to save them bandwidth.

So, this is a really underlying thing in the web today about trust. So, by bringing in an external resource into your websites, which is the Javascript file, you’ve got to implicitly trust the location that’s hosting that file.

Now, this company called Texthelp that offer the service called Browsealoud, a lot of developers wouldn’t have heard of it until this hack or this incident came into the press. Obviously, the people like jQuery, Font Awesome, Google, etc., that host these libraries en masse, everyone’s heard of. But Browsealoud, no one’s really heard of it.

So, these massive, massive websites are placing a lot of trust in that company by saying, “Yeah, we’ll serve your Javascript file. Yeah, put it on our website.” Because basically, what you’re saying to them is, “You can literally do whatever you want in that Javascript file on our website,” which is a lot of trust when you’re a big company like that. And there’s a lot of big government websites, like I mentioned.

In this instance, we actually got away here quite lightly because all it did was install a cryptominer into the user’s browser through Javascript. So, I’ll go into a bit more detail in a sec, but essentially, they had free reign to do whatever they wanted. So, they could have redirected you to another site, which could’ve been a phishing site. They could’ve logged your keystrokes. And if it was a site that takes your username and password or any sensitive data, they could’ve siphoned that off. There’s tons of stuff that could’ve gone wrong here.

So, really, we want to be, sort of, thanking our lucky stars that this didn’t go a lot, lot worse. Because even though it was only live for, I believe, four or five hours, the Texthelp company CTO has said. I still dread to think how much traffic that file would’ve received in that amount of time.

Yeah, so a little bit more about this compromised file. So, it was under the browsealoud.com domain name, and what it does is it provides these technologies. But as soon this browsealoud.com domain name, or this specific location that hosts this file is compromised, the attacker can put whatever he wants in there. So, like I said, we got off quite lightly because all it did was bring in a script from coinhive.com. And all that does is use your CPU through your browser to mine cryptocurrency and it deposits into the hacker’s account.

So, obviously, this is really malicious, and it’s pretty crappy that it’s happened. And it does, actually, slow your computer down quite a bit because, as you can imagine, mining crypto does use quite a lot of your CPU. But they had free reign to do anything they wanted, so we did get away with this quite lucky.

Now, there are a few slants to put on this. People might say, “Well, what’s coinhive.com doing as a website, anyway? Why doesn’t the browser just block this?” But it’s actually a legitimate service. All they’re doing is providing a cryptocurrency miner in Javascript. So, there’s a couple of legitimate uses for this. I won’t go into it, but this is obviously quite a malicious usage and, you know, if you’re installing a cryptocurrency miner on any customer’s computer or user’s computer and using it for your own benefit, it’s probably going to be quite malicious.

Although, one of the legal slants on this is that, “Hey, we won’t serve you ads, but we’ll serve you this cryptominer and we’ll recoup some money that way.” So, that’s one legitimate usage. You know, a little bit dodgy, but some sites do it, and you might see… I mean, key people that would do this would be people that are doing pirate software, for example, like The Pirate Bay might have something like this running on their site. They’re already doing something slightly illegitimate or totally illegitimate. So, those type of companies might want to use this service legitimately. So, that’s why browsers don’t just outright block this domain.

And that’s something we’re going to get onto in terms of technologies that can help you mitigate this type of attack. There are two technologies that can help you mitigate this. There’s one called SRI, which is Subresource Integrity, and there’s one called CSP, which is Content Security Policy. And what they both do, essentially, is verify the integrity of any third-party resources you’re pulling into your site. So, they do a few others things, too, but that’s, you know, the main ones we’re going to touch on here.

So, the easiest and most obvious one for this type of attack in terms of mitigating it is SRI. So, what that allows you to do is put a hash into the scripts tag. So, everyone’s copy-pasting script tags from third-party Javascripts websites. And all you do is put a hash in there, and what that does is it verifies the integrity of that file against that hash. So, if that file was ever to change from what that hash indicates the file should have in it, it won’t load into your website anymore. So, that’s an absolute bulletproof way to fix this problem. But, it does carry side effects.

So, if the third-party vendor was then to update that file, whether it wants to push a new feature, fix a bug, or anything they want to do, that will break its inclusion to your site because the file will no longer match the hash.

So, there’s a number of ways that this could be mitigated, too, as a, you know, side effect. So what other third-party vendors should do, really, is version their files…so, whether that’s putting the version number in the filename or putting it in the path name. And then, what they can do is they can keep the old version live, so your integrity check is still passed. And then, it’s up to the developer to update that script tag to match the new file if they want the new feature or if they want the bugfixes.

So, that’s one way to do it. But it turns out that, at the moment, Browsealoud don’t offer that type of integration. So, there’s no versioning of the file. So, you could’ve done SRI and fixed this problem, but if they pushed an update to the file, it would’ve broken it in your website.

The other thing you could do, like I mentioned, is CSP. So, this is a new technology, too. And when I say new, I mean, it’s been in Chrome for years, but IE and Microsoft technology is unfortunately still catching up. So, neither of these two things are properly supported in Explorer 11, which is still, obviously, quite a widely used web browser. And there’s also a couple of other web browser dependencies or web browsers that have compatibility issues here, but people on anything modern or, you know, basically Chrome, are fine.

And just to get back to what I was saying, so CSP is a header that you can send. So, you can even send this as a http header, or you can send it in the html head in a meta tag. And it can be used for loads of cool things, actually. It’s a really good idea to look into this for your website. But the thing we’re going to touch on here is whitelisting domains.

So, in this instance, what the ICO should’ve done, for example, is include browsealoud.com in their whitelist. And obviously, they wouldn’t have included coinhive.com in their whitelist. So, when this Browsealoud Javascript file’s getting included, that’s all fine. But as soon as this Javascript file then tries to pull in a coinhive.com file, it wouldn’t have worked.

So, in this instance, just to add a bit more context here, there’s actually no reason why the attacker couldn’t have put the entire cryptominer or whatever malicious thing they wanted to do directly in that browsealoud.com file. And because you’ve whitelisted that domain, the compromised file is still going to get to you without an SRI alongside this.

So, there is no silver bullet here. So, there’s a lot of tech articles written around this by some guys called Scott Helme, Troy Hunt. And it’s been covered in loads of other publications, too. And they’ve got loads of really great stuff about it. So, go check out those articles.

But one thing I just wanted to mention is there is no cut and dry solution to this. You can’t just say, “Oh, SRI, sorted,” because it depends. And Troy did touch on this quite a lot because I think he gets that it’s a bit of a risk trade-off. And, I mean, he explains it much better than I do, but essentially, it depends. In terms of this instance, an SRI would’ve sorted it or a CSP would’ve sorted it. But in a lot of other instances, you’ve got to consider what type of functionality it’s adding to the site and what type of site you’re putting it on.

So, there’s other third parties, such as Disqus, for example, that’s context-sensitive depending on if you can use SRI or CSP at all if you want to include their functionality on your website. But if you’re a big government website, you need to be taking these things really, really seriously because for this thing to happen is massive. And it did affect tons of websites and they are all really high-profile with the nature of what their service provider was doing with the assistive technologies.

So, to wrap up, basically, always consider putting a CSP in your website, and also, always using an SRI in your script tags. It’s really important that you at least consider them, whether or not you do it in the end. As long as you’ve got motive for doing it or not doing it, then that’s great. Just make sure you consider them.

And also, for the vendors, in terms of people like Browsealoud and any other vendors that offer these type of services, the script tag, if applicable, should always include the SRI, so the hash, the integrity check. This is absolutely 100% obvious for companies that offer Javascript libraries over a CDN, such as jQuery.

So, if you were to go into jQuery’s site, you’ll notice they already offer this by default. So, that means that when developers or people that are slightly less-skilled developers might go on there and just grab the script tag and put it in their site, it’s a no-brainer. They don’t even have to think about it. They’ve already got SRI on there. So, that really is something that, as a third-party vendor, you really need to consider. Otherwise, you’re going to create these problems later down the line for your users.

So, that’s it, really. So, hopefully I’ve cleared some of this up in terms of the wider problems with this issue. And it is going to be an ongoing issue because it is a trade-off and there’s no right or wrong answer. It is context-sensitive. So, it’s something that developers just need to be aware of and third-party vendors need to be aware of and definitely consider when you’re next bringing in an external dependency onto your website. You’ve got to make sure you trust these guys.

And like I said, Browsealoud, not a very well-known company. So, to place a lot of trust in them to do what they want on your website, effectively, might have been a risk too far for these websites.

So, that’s it. Hopefully I’ve given you a bit more insight into it, and I’ll see you next time. Cheers.