Can everybody hear me okay?
Firstly, apologies, it seems my own EDR was compromised on the plane and somebody managed to infect me with a little thing that's making my voice go a bit bad.
But massive honor to be here, thank you very much.
Just a show of hands, how many people are currently working in cyber security?
Okay, quite a few.
How many people in offensive cyber security?
Cool.
How many people doing North Korean style criminal cyber security?
And the reason I ask that is that we live in such a fascinating time.
Never in my time did I think that we would have the world's biggest bank heist happen last week where North Korea stole 1.4 billion from a crypto exchange and they're going to get away with it.
And for me that's fascinating because my journey as a security researcher has kind of changed a lot over the last 20 years.
I like to think of myself more now as a safety engineer than anything else in that I look at the stuff that I'm building, I'm getting into production, I'm working with other people, and it's moved from just code to making it robust and secure.
And that got me very, very excited about the idea and the history of the term safety.
So the word safety itself is actually quite an old word.
I went to the British Library, unfortunately I couldn't search the library's archives because they were hit by a ransomware attack.
So I had to physically go into a library and remember how to pull out books.
But I looked up the history of the word and it started to appear in the languages around the 15th century and medieval times.
And from around the 16th century it was kind of mostly used for people trying to keep themselves safe from harm.
But actually if you look at a lot what we have around us, we have safety everywhere.
We just take a lot of it for granted.
So for example with children's toys, if you want to design and manufacture and sell a children's toy today, no matter where you are in the world, there are certain standards and requirements needed in order to sell that toy.
In the UK you've got EN72.1, and basically it means the toy shouldn't harm the person doing it, playing with it, using it.
And you kind of see that in a lot of the stuff that we use on a daily basis.
This morning when I got breakfast there was a machine making toast, a fairly dangerous machine.
It didn't kill me when I used it.
When I go in a lift it doesn't kill me.
The problem is that in cyber security and indeed the tech industry itself, we've kind of forgotten a lot of that language.
We've forgotten a lot of the history that's happened before us.
And that got me into thinking, if we could go back to look at all the other industries that come before us, how well did they do when it came to safety and security?
So for this talk I decided I'm going to look at all the various industrial revolutions and I thought, could we pull out an interesting piece of information that we could get from that industry in that period to see what we were doing today?
And the first one was the first industrial revolution, which was steam and textiles.
Now what was interesting about this is that this was kind of the biggest shift in the history of humankind.
It was a change from agriculture into using machines.
So a big chunk of that was having these big monstrous things doing stuff that we would have normally used human beings for.
The second one is probably the one that had the most disruption and that was the electricity and mass production.
It was the rise of oil, gas, internal combustion engine.
We now were doing stuff that made humans super powerful.
You're probably starting to see similarities to where we're going to be in a minute.
The second industrial revolution was really important because we were now 10x-ing human beings like never before.
Then there was a cool period.
And this is the period I think a lot of us can relate to.
It was the third industrial revolution and that was computers and automation.
This was the rise of the transistor, computers, the birth of the internet, really doing cool things.
And then from now, and this is where it gets a little bit confusing, is the 2010s till present.
So this is the cyber physical, the internet of things.
And throughout that history, we've got clear examples of where stuff went wrong and how we kind of fixed it.
And then we come into a new period.
And I'm terming this the fifth element period, right?
Because we're now looking at the rise of artificial intelligence.
And this for me scares me a little bit because for the last 28 years, my world has been everything to do around bugs, around offensive campaigns, exploitation, finding bugs, selling bugs, stopping people from selling bugs and so on.
And I felt like, are we really learning a lesson?
So a bit of a background.
I started my career not in computer security.
There were no computers in my school when I started school.
So I started art and art history.
And I spent a lot of time doing fashion and fashion design and fashion photography.
So as such, I lend to that period to look for some of the inspiration that I've got for the industry we're in today.
And the first one is a painting from Philippe Jacques de Luthenberg of 1801.
And he documented the rise of the first industrial revolution and the impact that it had on people.
And in this painting, you can see the traditional agriculture with the horse and cart.
And in the background, the furnaces burning as people adopting more of them.
And this picture caused a lot of concern when it came out because people were worried that these furnaces were taking over.
There was no control in these new industries that were coming along.
And then if we move to a later period, 1888, Jean-Eugène Brulant depicted a fairly common scene in 1888 of that of the apprentice and the master.
Now, if you look at this picture, it looks fairly harmless.
But the reality is this picture was from a period of time when child death in factories was a very common occurrence.
It was a picture depicting of horrific accidents of people losing their limbs because machinery was there and there was no security around them.
And it was images like these that actually caused a big change in how we looked at this machinery.
Then finally, the last one, this is a picture of the Triangle Shirt Race factory in New York of 1911.
As you can see here, if you look at apply modern health and safety today, most people would probably run away screaming.
But you had open furnaces and people building stuff.
And actually, after that incident, where there was 140 people died, New York and America finally decided that we need to have more strong controls around such industries.
Now, my own history also looked at the third incident.
Like I said, I've been working as a documentary photographer for a long time.
And in 2006, I decided to go to Pripyat in Ukraine for three days to document the anniversary of the Chernobyl incident.
For those who weren't aware, Chernobyl, the reactor had an issue.
They decided to not tell anybody about the issue for a while, and lots of bad things happened.
And I spent three days in the inclusion zone, and these images I filed for a number of publications.
And what was fascinating about that accident was that I heard firsthand from people there was that when the reactor blew, they weren't immediately told that it had happened.
It was kept secret.
They did see the fireworks happening, their description, and they walked up to the windows and looked out the window, and they felt a weird tickling feature on their face.
That was the radiation from the reactor going through.
People's lives carried on, and then after a couple of days, they finally realized they had to tell people, and it moved from there.
And then finally, in 1984, you have the Bhopal incident here in India.
Again, a massive chemical incident, not many security controls.
We finally all learned from this.
And what this kind of came out is throughout the last couple of industrial revolutions, we've been very, very good at knowing something bad is happening and reacting to it, until we get to cyber.
It seems with cybersecurity and cyber itself, we aren't very good at one, looking at history, and two, we're also really bad at building things that are safe and secure.
And for me, that's always been a problem I've struggled with, is that why are we not able to build stuff in a secure, safe way?
Especially now, given how many of us rely on the internet, and the World Wide Web, and so on.
And it took me on a journey.
I think a big part of it is that our industry itself prides itself on safety third.
We're an industry that loves talking about offensive operations.
We give threat actors who cause damage and destruction to so many cute little names and mascots.
We call them cozy bear.
We call them fluffy pancake, whatever.
We glorify criminals in a way.
And almost in a way, we're glorifying the fact that these bugs that they're exploiting are something that should be applauded.
And I think that, for me, brings us into a transformation ambivalence.
What I mean by that is that we're almost at a crossroads when it comes to computer security at the moment.
Now, my world has been bugs for a very long time.
And I was always fascinated by the journey that you have with a bug.
So in the 90s, when we were finding vulnerabilities, we didn't have the experience or the maturity to understand what that bug could do.
And probably in the early days of the World Wide Web and the Internet, that bug was pretty harmless, right?
But my dad's a structural engineer and he builds oil mines and stuff.
And he always gave me this one thing.
He goes, you guys call yourselves computer engineers, but the reality is you're terrible at building stuff.
And let me give you an analogy.
When I go to an oil mine or a petro processing plant and have to build a lift, the process of building a lift is incredibly intense, right?
It is a steel box.
Sorry, that pushes people up normally floors, pulls them down floors at an amazing rate.
And it has the chance to really hurt people.
And I thought, okay, so I'm sure there's lots of deaths across the world from lifts.
Actually, in the US, last year, there were 27 deaths related to lifts.
You think, okay, that's not bad.
Interestingly, it works out to about 0 to 15% per ride that you might die if you go on a lift.
But what was really interesting about that 27 number is that 14 of those people died were workers.
They weren't applying health and safety.
And it got me thinking about the lift analogy.
How do you build a lift?
Well, Lift Design 101, for those of you who are not familiar.
First up, you have a big discussion.
We want to build a box that sends people up or down.
Great.
You then design the specifications, you have standards that you apply.
There's certain regulations around welding, and what kind of steel is used and the type of steel rope.
You then have money, you need money to be able to build a lift.
You then have the engineering.
And a part of that is lots of testing, stringent, stringent testing.
Before people can go into that lift, they test it like mad.
And then it gets deployed worldwide.
What that means is people don't die when they get in lifts.
I'm afraid we can't say the same thing when it comes to computer security.
Because we almost like to ship to production and then worry about the security element, at least in the experience of three decades.
And then we go, it's fine, we'll fix it later on.
Or, as we've found with web applications, we have all these web application vulnerabilities.
I know, we'll build a web application firewall.
The WAF will fix the vulnerabilities that we have.
We haven't ever got rid of the WAF, because that crutch is still there.
And indeed today, we have bugs like this.
Rule number one of presenting is never make something that people read on the slides.
But I'm sure you can see here, this must be a very old bug, right?
Hands up in the room, who are the bug bounty hunters?
Okay, if you saw this kind of bug, you get excited.
This was a bug found in the last four weeks by a major VPN provider.
This is the state of the software that we've got at the moment.
And it's a kind of a big concern.
But I want to take a step back.
So looking at the history of the bugs, you can't talk about bugs without looking... sorry, without transistors.
And my path with semiconductors and transistors has been fascinating the last couple of years.
And we need to talk about ENIAC.
So that was basically the first ever computer, and it made use of light bulbs to basically produce ones or zeros.
And there were two fundamental problems with this.
One, it was horribly inefficient.
And two, it produced a lot of heat.
Now, you might be seeing where I'm going with this.
One of the things they didn't consider was that when you produce lots of heat with a large amount of machinery, you get bugs.
The term bug that we use today came from relay number 70 in panel F.
It was a moth that had been attracted to the ENIAC bug, and it basically caused a short.
And this is a great piece of history.
It's the first actual case of a bug being found, right?
And then from there on, we went into a whole beautiful world of understanding transistors.
This is one of the first transistors.
And how you could go to and take them and build amazing things.
This was the third industrial revolution.
And eventually, you start putting them on to smaller, smaller amounts.
And then from there, you started to grow.
And we started an industry that grew so much.
And it is today.
If you look at the M2 Ultra, which I'm currently using, a phenomenal piece of hardware.
But what it has done is create a massive global capability that many people want to get involved in.
And indeed, if we look at what the semiconductor world is going through at the moment with geopolitics, there is a large amount of concern about who has access to the control, who's got access to the chips, and who can gain access to the data that they're building.
And that all stems down to bugs.
So a couple of years ago, I did a keynote at Black Hat.
And the one thing I talked about was, are we actually building a defendable internet?
And I went on a very long study, because it came from a talk that Halvar Flake gave at Black Hat Asia in 2016, where he felt that we weren't actually building one.
I was like, you know what, Halvar, you're wrong.
I do actually think we're building a good, secure internet.
And I thought, I'm going to prove him wrong.
And that talk kind of failed in a way, because no matter what I looked at, I kept on seeing areas where we as an industry weren't actually learning from the past.
We've become obsessed, especially in computer security, with popping calc.exe.
So I help run Black Hat.
Every year we get thousands of submissions.
There's a big chunk of that, there's an offensive element to it.
And I do love a good vulnerability and exploit chain and complex exploit chain as everybody else.
But I also love to see good defensive things.
And what we're seeing, especially as a trend at both Black Hat and other conferences I help with, is that defensive talks are really, really slim on the ground.
Now, I always wondered, is that because defense is naturally harder?
Or is it that we are so interested in popping calc.exe that naturally we sway to finding bugs?
And for those who aren't aware of who Halvar is, a phenomenally talented reverse engineer, Bindif is kind of his contribution to the world.
And he was quite right in saying that actually, collectively, we as an industry could do a hell of a lot more to make the internet secure if we all started to work together.
And I think that's one of the key things that I took away from that research at the time is that, you know, you look at all of you in the room here, you do have this capability of genuinely changing stuff.
We just haven't got there yet.
Because we love to blame Dave in accounting.
It is very odd at the moment that you cannot still click on stuff in a secure way without having something break.
We're supposed to click on stuff.
It's a clicky thing.
Click on a link.
Click on an executable.
Why is it that that could be backdoored, made malicious with a variety of different things?
It is still quite odd that we're still blaming people for clicking on stuff via horrible phishing.
And indeed, phishing is the number one vector that people are still using .
If we look at the North Korea hack last week, it turns out that potentially it was another phishing -based hack, which for 1.4 billion, that's a hell of a bug bounty.
So my early days with bug stuff is that we found a lot of bugs.
We did the normal thing of writing exploits.
We shared them amongst friends.
And then we created one of the first exploit-sharing sites called Hack.cosa.
So this was 1997, around that period.
And we gave away bugs.
This shows how terrible we were at business, because nowadays bugs cost a lot of money.
You never give them away.
But we would generally give them away.
And it could be anything from Solaris to AIX and so on.
I also had, and this is my confession, I used to write exploits in Perl.
And don't judge me, don't at me, it was a different period.
At least it wasn't PHP.
But you know, it showed that we were trying to explore what we could do.
But also we didn't understand the impact of that bug.
So for example, this was the Apache chunked encoding exploit.
A lot of the time back then, people were using Apache web servers.
This was a great bug, because it gave you a reverse shell.
Luckily, it wasn't abused that much, touch wood.
And you know, it gave me a good insight into that world.
But the key thing is, is that it's had that same relationship about understanding where bugs happened.
So for example, in a debug session and so on.
And I started to look, okay, surely there's been no incidents in the world where a computer software bug has caused a lot of damage, right?
That's not the case.
The Arianna rocket, this was a fascinating bug.
1996, rocket was going up really good.
The engineers had built it properly.
Shortly after liftoff, the rocket decided to turn 90 degrees and hurtle back into the ground into a fiery , massive blaze of flame.
It turns out they were using two interesting things.
One, they decided to use a 64-bit integer for the velocity details.
Great, well done.
But somewhere down the code, there was a conversion that pushed it into 16 bits.
As the rocket got higher, more values, values which would have worked with 64 bits, didn't work into 16 bits.
What naturally happened, we had a buffer overflow.
Boom time.
So bugs had a massive impact, and they still do.
I asked on Blue Sky the other day for some of the craziest bugs that people have ever seen, and Sparkalops gave me this one, which I think is brilliant.
This is a trucker safety program, that if they are under duress or getting hijacked or something, they could click the button saying, duress alert, please send help.
Unfortunately, the queue that they used had a very small buffer, and they said the send queue is nearly full, we will retry soon.
Which isn't ideal if you're being hijacked, right?
But that comes into the next point.
Those simple bugs that we now find, are now worth life-changing money.
So this is the latest price list that we can get from Zerodium.
Desktop bugs, up to half a million.
Servers, half a million.
Virtualization software, a million.
What's not shown here is the individual cases for mobiles.
So I know at the start, there was a talk about people doing iOS and Android hacking.
For me at the moment, that's the most lucrative space.
A full zero-click payload, you're looking at many millions, for a bug that impacts potentially hundreds of millions of people.
That's kind of scary for me, because we're definitely rewarding these bugs without fixing them.
And in turn, we've managed to fund and create a global surveillance industry, as Andrzej said.
We're now at the case where we have geopolitics playing across the entire world.
The dynamic of world order has changed.
We have people saying that Putin is not a bad person, which is something I never thought I'd hear in my lifetime.
And indeed, we've got various governments using bugs to spy on people.
Now, in 1776, Caesar talked about how he could never find a bearer to take messages that didn't lighten the message as he walked along.
And what he meant by that was surveillance has always been in the mindset of those leading and ruling countries and empires.
It's just we sort of got a little bit better.
The problem was, is that everybody wanted to be like Caesar at the time.
They wanted to read each other's messages.
Now, that kind of changed a little bit with the Iron Curtain, in that they decided to make everybody a spy, where everybody could do mega, mega surveillance, not necessarily using a bug, but enable the government spying at a scale never seen before.
Now, obviously, if we look at the nature of spying and how these bugs have kind of helped that, is that you've gone from human, so humanit, to interception, telephone calls , computers, mobile phones, and finally, the internet and geolocation.
Each of those stages have been manipulated by some degree.
Now, indeed, today, telephone calls, doing interception of wiretaps, has been made easier with the introduction of WhatsApp and Signal and other VoIP-based capabilities that use proper encryption.
We could have got better with protecting people on the privacy front, except when it comes to the digital realm.
That's where we're still in a bit of a problem at the moment.
And what it's meant is that technology has allowed anybody to spy on anyone.
And for me, that sits kind of wrong.
Kenneth Gears, who's a really good friend, termed it really well for me.
It's the golden age of espionage in terms of stealing information.
And I think that, for me, is the biggest problem that we have at the moment, in that these bugs that we are introducing, these bugs that we're finding, are not being fixed in such a quick way.
Andrew Lovely talks about it as data is the new rule.
I've actually given up the fact that most of my data is now available on the internet.
Not through means of my own, I just, it's been breached so many times, I just don't know why I bother anymore.
But the reality is, we have to start doing stuff.
So, how do we start changing this panopticon?
This is the panopticon from Jeremy Bentham, 1773.
He was asked to design the ultimate prison, where basically you had a center, a console guard, and all the prison cells were open.
I never thought this would be an actual functional spec for a lot of things that people are building, but it seems that, again, we're not learning history that's come before us.
So, we did try and change some of this stuff.
In 1998, Jeff, Rainforest Puppy, came out with a bug that I'm sure many of you have still used today, SQL injection.
It was a fascinating story, it was the birth, for me, of the web app hacking type stuff.
And that bug was interesting because a lot of the people at the time were like, so what?
What's the problem?
What's the worst that could happen?
Well, we still have SQL injection today, 25, 26 years later.
And for me, that's kind of where the early web really got exciting.
So, like I said, early web, we were basically finding bugs, reporting them, hopefully getting fixed.
Nobody really cared because the web was too small back then.
And then, in 2001, everything kind of changed.
Mark sent out the mailing list email to the web app sec mailing list with the start of OWASP.
And that was a couple of months before Bill Gates did his trustworthy computing memo.
And this was really important because at the time, it was like, okay, you're building these web applications, how do we make them secure?
And what Mark and a few of us anybody heard of OWASP before?
Nope.
Cool.
Tiny organization.
Hasn't really had an impact.
We decided we were going to try and change the status quo of bugs and web app vulnerabilities.
And Mark and I wrote the OWASP testing project, which was started in 2002-ish.
So, it was kind of one of the first web app hacking books.
We're like, hey, these are web applications, these new things.
Some of them are running CGI scripts.
Here's how you test them to make sure there's no bugs.
I've said this before.
I initially thought that OWASP would cease to exist in around about 2005.
Right?
Because we would have fixed the bugs.
But the reality is, if we look now, even today, Fin6, cybercrime group, they are still leveraging a lot of bugs.
And this was interesting.
So, I thought, okay, I want to take a period.
I want to take that.
OWASP testing guide is old.
OWASP is 24 years old now.
Can I look at information and pull it out?
So, I said, okay, let's take all the NIST data that we've got, all the vulnerabilities back to time, and let's build up a massive dictionary of the stuff that I think is a web application-based one.
And let's see, have we actually solved the problem?
So, average score or CVS score of web app vulnerabilities from 2000 to 2024 has sort of decreased a little bit.
Positive, okay?
Number of vulnerabilities per year on the website, okay, 2023 kind of pushed up a little bit.
Same with normal vulnerabilities.
Okay, maybe that's not working.
And I got thinking, why are we finding more bugs?
Is it because the tools are getting better?
And indeed they are.
187 of Alcantara's AFL fuzzer actually introduced this quick start guide for everybody who's ever used that fuzzer knows that it's very, very hard to use.
So, okay, naturally people are getting better at finding bugs.
But then I thought, okay, let's look at the CVS buckets, right?
How are people doing it?
And you've sort of seen, you know, the most critical bugs stay the same.
We've seen more and more CNAs come on the scale, which I think is great.
So, more and more bugs are being reported.
But then we're also starting to have problems with Kev.
So, Cessna is known, Kev's known exploitable vulnerabilities dataset.
It's phenomenal because it shows how these bugs are being exploited in the wild.
And I said, okay, what's the most amount of, most dangerous amount of CWEs in?
There's CWE 787, out of bounds, so memory related stuff.
There's 94, which is your traditional injection.
And the rest seem to be okay.
But let's look at the web app ones.
Have we actually done better?
So, cross-site scripting, crap, no.
Okay, all right, let's ignore cross-site scripting, that's still a bad problem.
Good news, XML externity injection has gone down, so that's really positive for the Java people out there.
SQL ejection, we just can't seem to kill this bug class off, right?
This is still a massive problem.
Path traversal, even though a large VPN provider does have a vulnerability still, it's still up there.
And then I started to look at, like, how many of the percentage of web vulnerabilities versus all vulnerabilities exist?
And we've seen a massive spike in 2025.
Bear in mind, we're only two months into the year.
So, we're starting to see resurgence of web app vulnerabilities again, which is a big concern.
Now, the dataset I'll be releasing at some point, it's quite interesting to see where we're going.
For example, a lot of the times, other is kind of hidden, and it normally means the vendor's not replying.
And, you know, it goes through.
And that introduces people to, I don't know if everybody's a familiar with it, with the most dangerous software weaknesses.
And this is a great thing from MITRE, because I think this is really useful, because it understands where we're kind of going wrong.
There's a lot of bugs in here that truly should not exist anymore.
SQL injection, use after free, there's a lot of good things that we can do.
But frankly, I'm told there's time.
So, I'm going to pass up on the last bit.
I think one of the key things I would love for all of you to get along here is you have the power to help eradicate a vast amount of bugs that we have currently.
You generally have the power to make these bugs non-existent, to stop people getting exploited by them.
And I really hope that you enjoy the rest of the con.
Ask lots of questions, keep on hacking, and thank you very much.