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.
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.
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.
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, 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.
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, 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, 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.
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.