Security Tools Podcast

Troy Hunt: The Modern State of Insecurity (Part Two)

Episode Summary

Troy Hunt, creator of “Have I been pwned”, gives a virtual keynote that explores how security threats are evolving - and what we need to be especially conscious of in the modern era. In this keynote, you’ll learn: - Real world examples of both current and emerging threats - How threats are evolving and where to put your focus - How to stem the flow of data breaches and protect against malicious activity and much more!

Episode Notes

Troy Hunt, creator of “Have I been pwned”, gives a virtual keynote that explores how security threats are evolving - and what we need to be especially conscious of in the modern era.

In this keynote, you’ll learn:

and much more!


Cindy Ng: Troy Hunt is a world-renowned web security expert known for public education and outreach on security topics. And we recently invited Troy to give a keynote on the modern state of insecurity.

Troy Hunt: Then moving on another one I think is really fascinating today is to look at the supply chain, the modern supply chain. And what we're really talking about here is what are the different bits and pieces that go into modern-day applications? And what risks do those bits and pieces then introduce into the ecosystem?

There's some interesting stats, which helps set the scene for why we have a problem today. And the first that I want to start with, the average size of webpage, just over 700 kilobytes in 2010. But over time, websites have started to get a lot bigger. You fast forward a couple of years later and they're literally 50% larger, growing very, very fast. Go through another couple of years, now we're up to approaching 2 megabytes. Get through to 2016 and we're at 2.3 megabytes. Every webpage is 2.3 megabytes.

And when you have a bit of a browse around the web, maybe just open up the Chrome DevTools and have a look at the number of requests that come through. Go through on the application part of the DevTools, have a look at the images. And have a look at how big they are. And how much JavaScript, and how many other requests there are. And you realize not just how large pages are, but how the composition is made up from things from many, many different locations. So, we've had this period of six years where we've tripled the average size of a webpage. And of course, ironically, during that period we've become far more dependent on mobile devices as well. Which very frequently have less bandwidth or more expensive bandwidth, particularly if you're in Australia.

So, we've sort of had this period where things have grown massively in an era where we really would have hoped that maybe they'd actually be a little bit more efficient. The reason I stopped at 2016 is because the 2.3-megabyte number is significant. And the reason it's significant is because that's the size of Doom. So, remember Doom, like the original Doom, like the 1993 Doom, where if you're a similar age to me or thereabouts, you probably blew a bunch of your childhood. When you should've been doing homework, just going through fragging stuff with BFG.

So, Doom was 2.3 megabytes. That's the original size of it. And just as a reminder of the glory of Doom, remember what it was like. You just wander around these very shoddy looking graphics, but it was a first-person shoot-em-up. There were monsters, and aliens, and levels, and all sorts of things. Sounds. All of that went into two floppy disks and that's your 2.3 megabytes. So, it's amazing to think today when you go to a website, you're looking at the entire size of Doom, bundled into that one page, loaded on the browser.

Now, that then leads us into where that all goes. So, let's consider a modern website. The U.S. Courts website. And I actually think it's pretty cool looking government website. Most government websites don’t look this cool. But, of course, to make a website look cool, there's a bunch of stuff that's got to go into it.

So, if we break this down by content type, predictably images are large. You've got 1.1 megabytes worth of images, so almost half the content there is just images. The one that I found particularly fascinating though when I started breaking this apart is the script. Because you've got about 3/4 of a megabyte worth of JavaScript. Now keep in mind as well, JavaScript can be very well optimized. I mean, we should be minimizing it. It should be quite efficient. So, where does 726 kilobytes worth of script go?

Well, one of the things we're seeing with modern websites is that they're being comprised of multiple different external services. And in the case of the U.S. Courts website, one of those web services is BrowseAloud.

And BrowseAloud is interesting. So, this is an accessibility service made by a company called Texthelp. And the value proposition of BrowseAloud is that if you're running a website, and accessibility is important to you...and just to be clear about what we mean by that, if someone is visually impaired, if they may be English is second language, if they need help reading the page, then accessibility is important. And accessibility is particularly important to governments because they very often have regulatory requirements to ensure that their content is accessible to everyone.

So, the value proposition of a service like BrowseAloud is that there's this external thing that you can just embed on this site. And the people building the site can use all their expertise to sort of actually build the content, and the taxonomy, and whatever else of the site. They just focus on building the site and then they pull in the external services. A little bit like we're pulling an external library. So, these days there's a lot of libraries that go into most web applications. We don't go and build all the nuts and bolts of everything. We just throw probably way too much jQuery out there. Or other themes that we pull from other places.

Now, in the case of BrowseAloud, it begs the question, what would happen if someone could change that ba.js file? And really where we're leading here, is that if you can control the JavaScript that runs on a website, what would you do? If you're a bad dude, what could you do, if you could modify that file? And the simple answer is is that once you're running JavaScript in the browser and you have control over that JavaScript, there is a lot you can do. You can pull in external content, you can modify the DOM. You can exfiltrate anything that can be accessed via client script.

So, for example, all the cookies, you can access all the cookies so as long as the cookies aren't flagged as HTTP only. And guess what? A lot of them which should be, still are. So, you have a huge amount of control when you can run arbitrary JavaScript on someone else's website. Now, here's what went wrong with the BrowseAloud situation. So, you've got all of these websites using this exact script tag, thousands of them, many of them government websites.

And earlier this year, Scott Helme, he discovered that the ICO, the Information Commissioner's Office in the UK, so basically the data regulator in the UK, was loading this particular JavaScript file. And at the top of this file, was some script which shouldn't be there. And if you look down at about the third line and you see Coinhive, you start to see where all of this has gone wrong.

Now, let's talk about Coinhive briefly. So, everyone's aware that there is cryptocurrency and there is crypto currency mining. The value proposition of Coinhive...and you can go to in your browser. Nothing bad is going to happen. You can always close it. But bear with me, I'll explain. So, the value proposition of is you know how people don't like ads. You know because you get a website, and there's tracking, and they're obnoxious, and all the rest of it. Coinhive believe that because they don't like ads, but you might still want to monetize your content, what you can do is you get rid of the ads, and you just run a crypto miner on people's browser. And what could go wrong? And in fairness, if there's no tracking and you're just chewing up a few CPU cycles, then maybe that is a better thing, but it just feels dirty. Doesn't it?

You know, like if you ever go to a website and there's a Coinhive crypto miner on there, and they usually mine Monero, and you see your CPU spiking because it's trying to chew up cycles to put money in someone else's pocket, you're going to feel pretty dirty about it. So, there is a valid value proposition for Coinhive. But unfortunately, when you're a malicious party, and there's a piece of script that you can put on someone else's website, and you can profit from it, well then obviously, Coinhive is going to be quite attractive to you as well.

So, what we saw was this Coinhive script being embedded into the BrowseAloud JavaScript file, then the BrowseAloud JavaScript file being embedded into thousands of other websites around the world. So, U.S. Courts was one. U.S. House of Representatives was another. I mentioned the Information Commissioner's Office, the NHS in Scotland, the National Health Service, so all of these government websites.

Now, when Scott found this, one of the things that both of us found very fascinating about it is that there are really good, freely accessible browser security controls out there that will stop this from happening. So, for example, there are content security policies.

And content security policies are awesome because they're just a response killer, and every single browser supports them. And a CSP lets you say, ''I would like this browser to be able to load scripts from these domains and images from those domains.'' And that's it. And then if any script tries to be loaded from a location such as, which I would assume you're not going to whitelist, it gets blocked. So, this is awesome. This stops these sorts of attacks absolutely dead.

The adoption of content security policies is all the sites not using it. And that's about 97%. So, it's about a 3% adoption rate of content security policies. And the reason why I wanted to flag this is because this is something which is freely accessible. It's not something you go out and spend big bucks on a vendor with. When I was in London at the Infosecurity EU Conference, loads of vendors there selling loads of products and many of them are very good products, but also a lot of money. And I'm going, ''Why aren't people using the free things?'' Because the free things can actually fix this. And I think it probably boils down to education more than anything else.

Now, interestingly, if we go back and look at that U.S. Courts website, here's how they solved the problem. So, they basically just commented it all out, and arguably this does actually solve the problem. Because if you comment out the script, and someone modifies it, well, now it's not a problem anymore. But now you've got an accessibility problem. I actually had people after I've been talking about this, say, ''Oh, you should never trust third-party scripts. You should just write all this yourself.'' This is an entire accessibility framework with things like text to speech. You're not going to go out and write all that yourself. You're actually got to go and build content.

Instead, we'd really, really like to see people actually using the security controls to be able to make the most of services like this, but do so in a way that protects them if anything goes wrong. Now, it's interesting to look now at sites that are still embedding BrowseAloud but are doing so with no CSP. And in case anyone's wondering, no Subresource Integrity as well. So, things like major retailers, there are still us government sites, there are still UK government sites. And when I last looked at this, I found a UK transportation service as well. Exactly the same problem.

And one of the things that that sort of makes me lament is that even after we have these issues where we've just had an adversary run arbitrary script and everyone's browser, and let's face it, just Coinhive is dodging a bullet. Because that is a really benign thing in the scope of what you could have done if you could have run whatever script you wanted in everyone's browser. But even after all that these services are still just doing the same thing. So, I don't think we're learning very well from previous incidents. ...