Transcription performed by LeahTranscribes[START OF RECORDING]
JACK: I have a degree in Software Engineering, but can you remember a time in your life when there wasn’t such a thing as software engineers? I can’t. All my life it’s been a thing, but I bet my great-grandparents went their whole life without ever hearing about software engineering. So, let’s take a quick look backwards to find when software engineering popped into existence. [MUSIC] In the 1950s, NASA was doing some pretty amazing things; flying spaceships to the moon and beyond. These spaceships were loaded with lots of technology; antennas, radios, computers, cameras, software, and hardware. That’s just onboard the spaceship. You’ve seen these giant command centers they have, where Mission Control is. There are computers on everyone’s desk and giant screens in front of the room, and there are dozens of scientists and engineers in the room, yet not a single one of them was a software engineer, because the term had not been used at any point in the 1950s. In the 1960s, NASA developed the Mariner Space Program. The goal here was to send unmanned spaceships to Mercury, Mars, and Venus, to take photos of them.
In 1962, the first Mariner spaceship was launched, and it was headed for Venus. It didn’t have anyone onboard. It was controlled remotely, and onboard were just electronics, antennas, computers, jet fuel, and cameras. But only a few minutes after launching, things started to go wrong. The computer onboard that was in charge of controlling the ship was acting erratic, giving all kinds of wild commands for the ship to do. The folks at Mission Control tried to correct the computer gone wild, but they couldn’t do anything about it. Then they started to realize this rocket’s not gonna make it to Venus. It’s not even gonna make it out of the atmosphere, and it might even crash into Earth and hurt someone. So, the people at Mission Control decided there was no choice but to push the self-destruct button and blow up Mariner 1 over the Atlantic Ocean. That was the end of the Mariner 1 spacecraft, an $18.5 million-ship blown up. So, what happened?
Well, scientists and engineers spent days replaying the events and logs that they captured after launch. A piece of hardware failed, which caused an onboard computer to kick in and try to control the craft, but the way it was trying to control the craft wasn’t right. Something was wrong with that computer, so they examined the code that was put on that computer, and that’s when they saw the problem; a mission dash in the algorithm. A single missing dash. It’s not like the dash you’re thinking; it’s more like a bar that was supposed to be above the letter R, which stands for radius, and that meant it should have been a smoothed value for radius. Without this bar, it was taking the current value for R, and since this rocket was trying to recover from some bad hardware, the values for R were bouncing all over, so the output of the program was bouncing all over. It should have been taking an average reading for R, not the wildly fluctuating values. So, the computer was telling the rocket to fly all crazy and out of control.
The logic and algorithm that the scientists gave the programmer was correct, but whoever programmed that algorithm into the computer missed this little dash above the R, and because of that tiny little bug in the code, it resulted in the whole rocket being destroyed. When NASA makes a mistake like this, they try to find ways to prevent anything like this happening in the future. They realized they were implementing software on a lot of systems, but had no way to test the reliability of that software. This is when it became clear that software engineering should be a discipline, and shortly after that, it started getting developed and became a thing. This software bug didn’t just crash a spaceship, but it launched a whole new field of study and new principles for designing, developing, and testing computer software.
(INTRO): [INTRO MUSIC] These are true stories from the dark side of the internet. I’m Jack Rhysider. This is Darknet Diaries. [INTRO MUSIC ENDS]
JACK: Are you ready?
MADDIE: Yep, sounds good to me.
JACK: So, what got you start – hold on, let’s start with your name and what do you do.
MADDIE: My name is Maddie Stone and I am a security researcher focused on setting zero-days that are actively exploited in the wild at Google Project Zero.
JACK: We’re gonna get into what she does at Google, but I find that the path to get there is interesting. So, when she was a teenager, she developed an interest in computers, and after high school went to college at Johns Hopkins University in Maryland.
MADDIE: Yeah, so I actually double-majored in Computer Science and Russian Language and Literature, ‘cause I wasn’t fully committed to this whole engineering thing. I didn’t know if I would be bored during – doing that, so I was like, let’s learn a new language, and ended up really enjoying the Russian in just a very different way of using your brain in classes and everything like that, and it allowed me to study abroad too, which I’ve always loved to travel.
JACK: Whoa, this is crazy. So, you know Russian.
MADDIE: Well, I used to. I used to be good.
JACK: Yeah. But then you moved? You studied abroad; to where?
MADDIE: So, I did two months in St. Petersburg and four months in Moscow.
JACK: [MUSIC] And after graduating, got a job at the Applied Physics Lab at Johns Hopkins.
MADDIE: Which is a government research laboratory. That’s where I ended up for the first four-and-a-half years, studying – or working on reverse-engineering of firmware and hardware.
JACK: It looks like a really cool place, actually. There are about 8,000 employees at this Applied Physics Lab, and they take on research projects for the Department of Defense and NASA, so they get hands-on experience while doing advanced research.
MADDIE: So, I was also working with literal rocket scientists, if that doesn’t keep your ego in check.
JACK: While working there, she simultaneously was able to get a master’s degree in Computer Science, too.
MADDIE: I was super fascinated by the hacking portion and when you see all these things but have never actually done it, it sounds really sexy and everything like that. I had really, really loved Assembly. I had actually listed that that was my favorite language when, you know, they did a round and did profiles of folks and interviews with different companies. They ask you and they’re like, you love Assembly? I was like, yes. I became the teaching assistant for that course and then as an independent study, created all new projects.
JACK: Hm, that’s very interesting to me. I, too, have an IT degree, and I learned Java and C and C++ and Visual Basic and all these programming languages, all of which I could understand no problem. But when I took the Assembly language class, I was so lost. It was the only IT class that I actually struggled with, and that’s because it’s so different than everything else. Assembly language is very low-level. A high-level language, you can see things like variables, if statements, for loops, and functions, but with Assembly, you have commands like move, push, pop, add, subtract, real basic and rudimentary stuff. A program that is just a few lines of code in Python can become ten times longer in Assembly. But Assembly has some superpowers. It can interact with memory and the CPU in ways that other languages can’t, and it can be incredibly efficient, too. You get much better control over the computer’s resources, and you know what? You can go even deeper, too, to a even lower level and look to see what’s going on in the hardware. You could open up the case of the computer, get out some probes, and jam them into the circuit board and watch what electrical signals are moving through the circuitry. This is even more hard to read because all you see at that level is whether the voltage is high or low, but having this kind of read/write access gives you really the ultimate power over your computer.
It was this low-level stuff that fascinated Maddie. It was like doing brain surgery to teach someone something or to see how they think. A computer can’t hide its thoughts when you’re this deep into it. Another big reason she liked it was because she could break down any program into Assembly. It doesn’t matter what language a program is created in; you can run any compiled program through a disassembler and see the whole program in Assembly language. A lot of applications and programs are compiled and in a sort of byte code that’s not human-readable, and you certainly can’t see the original code that was used to create it, so you can’t tell what so many programs actually do. But at the end of the day, the computer has to know what to do, and that byte code can be converted into Assembly so you can kind of read what’s happening. So, if you get good with Assembly, you can get a much deeper understanding of how computers handle memory and processes, and you can decipher any program. It’s just really hard to read at that level. It’s kind of like reading a book, but you only get to look at one letter at a time, and the book only has ten usable letters that make up all the words. Anyway, getting better at Assembly and learning more about hardware is what she spent four years doing at the Applied Physics Lab.
MADDIE: [MUSIC] Then one day, Google calls and says hey, are you interested in interviewing with us? Which I was pretty shocked about because as a student, I tried really hard to get any – even interviews or calls with all of the big tech companies, but I was not someone of interest to them, so I was very surprised to get the call and ended up going through the interview process and getting the offer to join the Android security team as a reverse engineer.
JACK: A reverse engineer is someone who takes a program and tries to figure out what it does by sometimes converting it to Assembly language and trying to make sense of it. I mean, Google is where Android is made, so why would someone need to reverse-engineer Android when they could just look at the source code written right there in the same building?
MADDIE: I was focused on all of the malware, you know, in the Android ecosystem.
JACK: Oh, duh, that makes sense. The malware that’s targeting Android is often compiled, where you can’t see the code that’s used to make it, and Maddie’s job was to reverse-engineer and decompile some of this code and examine it for malware, and if it was malware, figure out what it’s doing and then tell the Android developers how to fix this.
MADDIE: More specifically, I started leading a team that was focused on finding any sort of malware or bad apps that were one, potentially pre-installed on different OEM or manufacturer devices, ‘cause there’s thousands of different manufacturers of Android devices, as well as looking at can we find malware for all the apps that are off of Google Play Store? So, in lots of parts of the world, there’s apps that are passed around through different stores other than Google Play or they’re peer-to-peer passed or things like that, so are there ways that we can still protect Android users from those apps as well, and figuring out what’s malware and what’s not?
JACK: Okay, so I just got curious what kind of malware we’re talking about here when it comes to Android, and I started looking some things up. [MUSIC] One really popular virus going around is GinMaster. Apparently there are millions of Android devices infected by this, and don’t forget, Android is an operating system that’s used on both phones and tablets. But this GinMaster malware, once it gets into a device, it will capture private data from the device and send that to an external server. It can also give attackers access to that device. GinMaster is clearly something you’d never want on your phone or tablet, so why does it exist on millions of devices? Well, the way it often gets onto a device is that it gets tacked onto another app, and it’s typically a bad app that a user is tricked into installing.
A common strategy is to make a lookalike app of a popular game out there. This is to trick people into thinking that they’re getting the app that they want, but it’s not the real one. Then when someone downloads it and installs it, not only do they not get the app they want, but they get infected with this GinMaster malware. So, at the end of the day, it’s actually a user who downloads and installs the virus; they just don’t know it’s a virus. When a device is infected with it, it can steal user data, take control of the device, or install more malicious stuff. So, it’s malware like this that gets sent to Maddie for analysis, and she can flag apps like that to warn Android users that this app contains malware, and specifically the way Android apps are packaged is in something called an APK file, which stands for Android package.
MADDIE: Yes, so we find an APK file, which is basically just a .zip file with all of the different components of an Android app.
JACK: Not all Android apps are written in Java, but I think it is the most common language they’re typically written in. What’s nice for Maddie is Java apps can be decompiled pretty easily, and you can see a pretty close picture to how the original program looked. So, she doesn’t need to break it down into Assembly. She can read through what it’s doing close to its original format, making it a lot easier to understand. But it’s not always this easy; sometimes hidden in the Java is additional compiled programs.
MADDIE: [MUSIC] Yes, so that’s where some of the more sophisticated malware authors would try to hide their – some of their behaviors in need of libraries within the APK file. So, these are compiled C or C++, which once it’s compiled, it’s in machine code which we can disassemble to Assembly code.
JACK: Of course, this is where Maddie shines. She can read this Assembly language to understand how the malware does what it does, then reports it to the Android team to see if there’s anything they can do to protect users from malware like this.
MADDIE: Yeah, so, the first thing is we had to put flags into the Google Play protect system, because the number one thing is you want users to be alerted, to given the option to remove it or disable the application from their device. The next step is really writing automated solutions, because especially when you’re in a malware team – and there’s always more apps or samples to look at than there are humans to analyze them, so the goal is always that it’s only ever reverse-engineered once in that terms, and that – then after you’ve reverse-engineered it once, then there’s software automated solutions that can find all the other copies that may come up out of that. So, that’s really the processes; analyze it, figure it out, flag it so users were protected, and then figure out automated solutions.
JACK: Mm-hm. So, tell me a story about maybe some interesting malware that you found or landed on your desk. You’re like alright, I’ll take a look, and whoa, this is crazy, this stuff.
MADDIE: So, one of the biggest malware families that I was not expecting and it ended up into a year-plus investigation, was what we called Chamois. It took a lot of practice to learn how to pronounce that correctly, but it was a large botnet and what was really interesting and how I got into it is that this application, which was usually written in Java, had this native library, so C or C++ compiled code in it. As I kept trying to dig into this native library, [MUSIC] it became obvious that it was heavily, heavily obfuscated as well as doing an incredible amount of anti-analysis and anti-debugging checks. So, it was very sophisticated trying to monitor like, am I being monitored and analyzed by a security engineer or am I running on a real device that I can infect? I ended up diving into – I think it took over a month or a month-and-a-half to really dive into all the aspects of that native library. Then when I started looking for other apps with similar native libraries, it became clear that it was this botnet and this family of malware that was doing some pretty sophisticated stuff. One of the funniest anecdotes to me is that I actually presented on that native library at Black Hat.
JACK: Yeah, so in 2018, Maddie came onstage at the Black Hat Security Conference and showed everyone in the audience the exact techniques that this malware was using.
MADDIE: [AT BLACK HAT] So, what are all these different techniques that we’re gonna talk about? What makes it so interesting? First we’re gonna start about some of the J&I or Java native interface manipulations, then we’re gonna go into some places where they’ve used anti-reversing techniques, in-place decryption, and finally to about forty different runtime environment checks that they use. [TO JACK] I think it was less than twenty-four – or definitely less than seventy-two hours later, we saw the malware authors changing different aspects and characteristics of this library that I had just presented on. [MUSIC] So, they only changed the characteristics and techniques I had discussed in the Black Hat presentation. So, that presentation hadn’t been streamed or anything like that, so that was very fascinating to see.
JACK: Whoa, yeah, that is interesting. This means either the malware authors or someone who knows the malware authors were at her talk, watching her, taking notes on how she’s able to detect their malware, and then rushing back to their computers to update their malware to make it harder for the Google team to detect it. See, this is the thing about Maddie; she seems to be on this mission to make it harder for malware-makers to do what they do. She gets in their heads and learns where and how they’re hiding so she can shine a big old spotlight on it and make them scatter. Her goal is to make it easier for people to find malware, and at the same time, make it harder for someone to make malware.
MADDIE: So, one day I had a new calendar invite in my inbox from Ben Hawkes, who was the long-time lead of Project Zero. We had never met before and he said hey, I just wanted to chat about this potential new role and experiment for Project Zero.
JACK: Oh wow, Project Zero was trying to steal her? That’s pretty cool. This is a very talented team within Google which focuses on finding zero-day vulnerabilities.
MADDIE: Yeah, so Google Project Zero is a team of applied security research with the mission of make zero-day hard.
JACK: But the key thing here is this team will look for bugs in any software, not just Google’s products. I think the idea here is that Google users don’t just exclusively use Google products.
MADDIE: Yeah, so if you think about it, to protect, say, Google Chrome users or Gmail users or things like that, a lot of Google users can be attacked through vectors other than just the Google products. So, whatever operating system you’re running Chrome on, for example, if that has vulnerabilities, than that could be a way to hack those users. Or back in 2014, Flash was one of the biggest ways to attack people via the web. So, doing a lot of research and vulnerability research into Flash would ultimately help protect Chrome users.
JACK: So, the team at Project Zero looks for zero-day vulnerabilities anywhere. Oh, and zero-day vulnerabilities are bugs that the software maker doesn’t yet know about, which also means the defenders don’t know about it either, and they can’t defend against this kind of bug. Now, if the Project Zero team finds a bug, they tell the vendor to fix it and then start the timer. If ninety days goes by and the vendor doesn’t fix it, Google will publish this bug publicly. Anyway, this was the team who approached Maddie.
MADDIE: So, his hybrid role would be not just – for me to not just be in vulnerability research, but sort of combine this threat intelly/malware/analyst side of it, and I would be – use the starting point of zero-days that are actively exploited in the wild. So, not just hunting zero-days that attackers could theoretically be finding, but instead having my starting point be the exploits that are actually used.
JACK: Hm, yeah, I get it. If the goal of Project Zero is to make zero-days hard to make, adding a reverse engineer to the mix really boosts the potential research that can be done. Now, instead of just looking for unknown malware out there, you can feed known malware to Maddie and she can digest that and come up with patterns to look for more malware that’s out there. It’s sort of approaching finding malware a totally different way. Combining these forces makes them more effective. So, she took the job and joined Google Project Zero.
MADDIE: [MUSIC] So, I really came into this team with not a lot of knowledge and just this basic idea from Ben that he told me take it and run with it and figure out what makes sense. So, I did not really have any Windows, IOS browser, et cetera, vulnerability research experience. My experience prior to Android had been on hardware and embedded devices, which doesn’t tend to be the biggest targets of interest for Project Zero. So, it was a lot of learning, but we started sort of off big and that I joined the team in July of 2019, and Google received information that the commercial surveillance company NSO had this Android exploit that they were using to target Android users in their delivery of Pegasus, the piece of spyware that has been all over the news lately. We actually got some marketing details about this capability. So, my first job was taking all of those details and seeing if I could figure out what the bug was so that we could patch it and break the capability.
So, I was digging through all the different Android source code, Linux kernel source code, trying to figure out what is this bug, and somehow managed to figure out exactly which bug it was, because the details we were given happened to line up, that there was only one vulnerability that potentially matched every single detail we were given. So, that was a pretty wild first bug to report and put into the Project Zero issue tracker. We reported it to Android under a seven-day deadline instead of the ninety due to a high probability that it was being actively exploited in the wild. Then wanting to show that it could be exploited, I partnered up with Jann Horn to write a proof-of-concept not just triggering the vulnerability, but actually showing a way to exploit the vulnerability and how it would be useful to get – or to use in, say, the Pegasus chain. So, that was quite the wild week.
JACK: For Maddie to identify how Pegasus software is used in Android and then to come up with a working proof-of-concept exploit all in a week, that’s amazing. That’s like finding and squashing a million-dollar bug. Seriously, there are companies out there who are willing to pay a million dollars for a bug like this, because it’s so valuable to certain people. Pegasus is the spyware used by NSO, which is a company based in Israel who sells the spyware to different countries around the world, and it’s quite expensive to buy this Pegasus software. So, when Maddie discovers how it’s used and makes it no longer usable, it must make NSO angry. Now they have to rip out their existing way of exploiting phones and find a new way to do that, which isn’t so easy. But this is Project Zero’s goal, to make it harder for exploits to be out there. If a company has a whole business model of selling malware and exploits to countries, then yeah, they’ll be impacted by this, and it’ll mean the price of Pegasus will go up, since it’s harder to find these vulnerabilities.
MADDIE: Generally it is nation state actors who are using zero-day exploits, and they’re generally using the zero-days against human rights defenders, journalists, minoritized populations, politicians. So, while every human doesn’t necessarily need to be worried about being attacked with zero-day exploits, all of us are generally impacted when they’re used. When journalists become scared or unable to write the truth that they find and that human rights defenders are being targeted so fewer people are scared to stand up and speak out, or minoritized populations are begin targeted, or critical infrastructure companies and things like that, that does ultimately impact us all.
JACK: If you want to know more about this, I did a whole episode on NSO. That’s Episode 100. You’ll hear how they sell software to countries, and then those countries turn around and use it to attack civil society. Of course, nation state actors aren’t always abusing their power; they do use their abilities to stop terrorist attacks and criminal activity, but at the end of the day, the measure of any technology is how it winds up getting used against vulnerable people, not just how it helps. So, if there are zero-day vulnerabilities out there that are being used to target innocent people, then finding those and fixing them will help civil society be more secure. It’s kind of wild to me to think that Maddie here is trying to disarm nation state actors by finding what weapons and exploits they have, and then once discovering it, getting it fixed so it can’t be used to exploit people anymore. Has there been any threatening reactions to this? Like, I can imagine NSO group being pretty upset after your first project there and being like okay, Maddie is now on our list. Do you ever get any weird stuff?
MADDIE: Well, it was actually very strange, of – in January of 2020, I was invited to the conference Blue Hat Israel. So I went, and there were actually two people who came up to me and their badges said they worked for NSO, and they said – and they asked me questions about why I chose the techniques I did, so that was a very strange interaction overall. But one of the more anxiety-producing was back in – I believe it was 2021; Google TAG, the Threat Analysis Group, discovered that North Korean hackers were targeting security researchers, including security researchers from Project Zero in the hopes of trying to steal then zero-day exploits from security researchers to use in their campaigns. So, being personally – or personally, I mean in the population of folks targeted, is a rather frightening aspect of – but it also just gave a lot of empathy for people doing the real hard work and are often targets of the nation state attackers using zero-days.
JACK: Yeah. So, some other philosophy here is like, NSA is in the business of finding zero-days and using them as weapons. Sometimes one of the nation states that you’re going up against is your own nation. Do you get cross-conflicted there, or how does that feel to you?
MADDIE: I don’t think so, because the vast majority of the time, we have no idea who is behind a bug. Also because you’re just working so quickly that people don’t usually have attribution, you know, immediately. They just – if attribution even comes out – the threat intel experts are usually three to six months behind, so there’s never sort of that conflict, because all we get is here’s an exploit sample, or here’s a patch diff and the bug was labeled in release notes. So, I’ve never really felt conflicted in that way because there’s no way to know. All you know is that people are being harmed, so that would sit even worse with me to not try and get it fixed. Yeah.
JACK: We’re gonna take a quick break here, but stay with us, because we’re gonna hear more from Maddie when we get back. Earlier this year, in 2022, Maddie saw that Apple patched a bug in their WebKit product. This is the browser engine that Apple’s Safari browser uses, and there was a pretty big vulnerability discovered in it, but the patch notes were a little vague, so Maddie started to try to learn more.
MADDIE: When I started digging into it, one of the ways that I also analyze –when it’s just a patch diff; I don’t have any other information – is for open source software such as WebKit, I will look at the history of that file and the areas that they patched, or – it’s called the git blame of – it sort of tells you when did this line appear or when was this source code line last changed. What I ended up figuring out was that this was a zombie bug and that it had actually been originally fixed back in 2013, but then the bug was reintroduced because that patch was regressed and undone in 2016. Then here we were in 2022 with the bug exploited in the wild and patched again.
JACK: Why do you think it regressed?
MADDIE: So, I did a deep blog post into this really trying to understand, and it was actually – it became sort of a team effort because all of us were really interested in trying to understand how did this happen. There was also a very interesting overlap of – my teammate Sergei Glazunov was actually the original reporter of the bug back in January 2013 and was actually reported to Chrome because at that time, Chrome was still built on top of WebKit as their browser engine. They didn’t split off until 2014, I believe. So, he was jumping in and looking at it with me, so were some of my other teammates like Mark Bran, and what it looks like overall is that they were trying to chain – sort of do a refactoring to one, make it more performant, and through that, that meant there were some really huge patch changes. Just based on the structure of security teams and reviewing, a lot of times folks aren’t really given a huge amount of resources and time to scroll through and look at line by line, like what are all these changes that are being made, and things like that.
JACK: Hm, it’s gotta be quite the embarrassing feeling to find that your code had been vulnerable for seven years and you’re just now discovering it. Makes you stop and wonder, who all knew about this? Is it possible some advanced hacking group or nation state actor had known about this and was using it to take over people’s browsers when they needed to? It’s hard to tell, and we’ll never know.
MADDIE: [MUSIC] Back in the fall of 2020, we discovered some exploit servers and just happened to discover that they were delivering us exploits on different devices and different browsers. In that case, you’re generally first just getting the first stage exploit and then some sort of fingerprinting script, maybe, or something like that. So, we were like, oh my goodness, this is giving us exploits and our devices are fully-patched. What the heck is going on?
JACK: This must have been a very exciting day, to find that there’s a server out there in the world that is able to remotely attack a device and exploit it in ways that are just not stoppable. For a security research team like this, it’s a big moment. You want to quickly try to capture as many exploits as you can from this server, and then analyze them and see exactly how they’re infecting devices so you can get them fixed.
MADDIE: So, in this case it was a watering hole attack, where a watering hole attack is if you go to a website and it is just going to try to infect anyone who goes to this website. So, that was sort of the case here, of oh, this is weird; suddenly this is very weird traffic and oh, that’s an exploit and that’s a fingerprinting script? What did we stumble upon here?
JACK: This website had active traffic and users coming to it. So, Maddie and the team at Project Zero knew that people were actively being hacked right now when they were visiting the site, and wanted to move as quick as possible to stop any more people from being infected.
MADDIE: So, that was where we all really came together and were working through weekends and long hours to first get as many of the exploits as we could, and then teaming up, tearing them apart, getting around the obfuscation, trying to figure out what exactly is the bug that is being exploited here, and getting those reported and working with the vendors to get those patches out as soon as possible.
JACK: So, they were able to squash any bugs that Google was responsible for, and then get all the other vendors who had bugs to squash them, too, which made this website no longer effective at being able to exploit updated devices that had come to visit the site. This is why I’m always telling you to patch your software. Always update your operating system and any apps you have if there’s an update available, because it makes it harder for someone to hack into your stuff. So, I mean, did you ever figure out who was doing this? Was it a nation state actor or who your thoughts were that would want to run this kind of attack?
MADDIE: So, we assume that it is a nation state actor just because the sheer volume of zero-days and the sophistication behind those zero-days, it seems rather unlikely that anyone other than a nation state actor would one, have access, and be willing to use that number. I believe that when we looked at it, it was approximately – I believe eleven zero-days that the actor had used over the course of a year. So, that definitely would make me think a nation state, but no, I do not know who was behind it. I also – I am not an expert in attribution, but I have not seen or heard any definitive answers on who the threat researchers and threat intel experts believe was behind it.
JACK: Whoa, eleven zero-days? That’s amazing. To make a zero-day vulnerability takes quite a bit of time and skill. This isn’t some simple social engineering attack or some off-the-shelf malware. Each of these eleven zero-day vulnerabilities were something that took a lot of resources to find and to turn into a usable exploit. On top of that, the way these exploits were chained together was incredibly sophisticated. So, because it takes so many resources to develop and weaponize that many bugs, then that’s why Maddie thinks it was likely some kind of nation state actor. This is beyond the capabilities of a cyber-crime group or hacktivist group.
MADDIE: If you can use a less sophisticated form of attack to get access to whatever you need, then that will always be the choice. If your device – if your targets are insecure and say you know they’ll fall for phishing, then that’s the easiest route and that’s what you’ll take. If your targets don’t keep their devices up to date unless you can use a in-day exploit, that’s what you’ll take. So, these zero-days are when one, you really don’t want to leave a trace because people don’t know what this bug and exploit will look like, and you’re targeting entities or individuals who probably have some pretty good security hygiene and posture. Those are often going to be people who know their targets, such as our human rights defenders and journalists, et cetera.
JACK: Hm, so the way I understand it, nation state actors typically have a few different objectives. It could be intelligence-gathering, like hacking into another nation and stealing information, and it could be disrupting the enemy, like deleting the servers that a terrorist organization uses. But we’ve also seen nation states participate in cyber-crime and hacktivism. North Korea has been hacking into banks and stealing money from them, and China has been hacking into US companies to steal their intellectual property. But we’ve also seen China hack into the Gmail accounts of human rights activists to try to stop them or figure out what they’re up to. We’ve seen the UAE hack into human rights activists’ phones to track them and arrest them. Of course, Russia is meddling with elections and even sabotaging the Olympics in some weird ways.
So, there’s a big spectrum of what governments are doing out there in the mean streets of cyberspace. I don’t know about you, but to me, trying to figure out this space, it gets blurry fast. What’s good? What’s evil? Some things are clear, but others not so much. Like, when a country hacks into and spies on another ally country? Why? Because they don’t trust their ally? Because they want more information than what their ally is willing to give them? What happens when they do find out that their ally had some nefarious plan? Do the ends justify the means? It gets tricky, and I imagine the weight of who you may be helping and who you may be hurting must weigh on Maddie as she does her work.
MADDIE: Of course. I don’t think anyone who’s in this industry or business can’t help but think about the philosophy of it. So, for me, it feels pretty easy and I hope I’m on the good side of – I want people to have safe and secure access to the internet, whether it’s just their data, their device, and everything like that. So, the case and the part of that, safe and secure that I am currently able to hopefully make the biggest difference on, is in the zero-day and zero-day exploit space. But previously I was trying to accomplish that with making sure every Android phone didn’t have malware on it. So, that’s sort of my guiding principle, is I think the world would be a pretty amazing place if everyone could access and connect to all this amount of information and education and everything like that if – with safe and security and know that their privacy is protected. So, yeah.
JACK: [MUSIC] It’s nice that Maddie has a good ethical mindset to all this and is helping us all become more secure. But just keep this in mind; there are people just like Maddie who work for the bad guys, doing exactly what she’s doing, looking through patch notes and trying to figure out what exploit just got fixed to see if there’s anything the vendor missed or some sort of related bug, and then once they find the bug, they’ll develop it into an exploit and weaponize it instead of getting it fixed. That just makes me think okay, if there are enemies and allies out there where countries are hacking into each other, then what does that make Maddie, an enemy or an ally? Or is there some kind of third faction out there? Also, NSA stands for National Security Agency. Their job is to ensure the US is secure and is able to send secure communications without our data getting into the enemy’s hands. So, you’d think that if the NSA has found a way to bypass the security of something, they’d want to find a way to get that fixed right away to ensure that the software used by hundreds of millions of Americans is secure, right?
But despite that the NSA spends millions of dollars on finding and developing vulnerabilities, they don’t report that much to vendors. We have seen them report some things sometimes, but it’s often under suspicious reasons. Like when the Shadow Brokers claimed they had NSA exploits, NSA told Microsoft to patch a certain bug right away, and there were other bugs that the NSA reported, which made me think that they might have intelligence that some other enemy nation might be actively using that exploit to hack into our stuff. It becomes even more difficult to navigate all this when so many of the tech giants are also US-based. I’m not saying there’s any sort of collaboration between the NSA and the US tech giants, but it makes sense to me that there is a closer relationship than other nations might have with US tech companies. I kind of see it as an arms race; while nation states around the world want more exploits and zero-day vulnerabilities to carry out their objectives, Maddie is over here trying to neutralize those and build up the defenses for everyone to be able to defend against nation states better.
MADDIE: I don’t really think of it as a race unless we’re talking maybe in single vulnerability case, like oh, we know this bug is being exploited; it needs to be fixed as fast as possible. That’s really the only area that I sort of view as a race. Maybe also around the – this was just patched and we want to make sure that the patch is sufficient. We complete variant analysis before the attackers are able to. But at a longer haul, I don’t think of it as a race as much as making smarter decisions, because ultimately what we want is that – it is so difficult, so expensive, so – requires so much expertise that attackers really hold onto their zero-days close to the vest, and they’re so valuable to them that they only use them in really, really special cases. I think we’re still at the point now that yes, while it tends to be a smaller population of people targeted globally, I think we’re still seeing too broad usage of these zero-days to believe that attackers find them as valuable as we would hope. So, that looks like making it that much harder for them to find vulnerabilities. So, let’s say they cannot use variants of a previously-public vulnerability; they instead have to come up with their own.
They have to come up with a whole new bug class that we’ve never seen before, not using these use-after-frees and buffer overflows. They’re not able to use a public exploit technique that someone has – we’ve seen before or they used before and just want to plug-and-play a new vulnerability in, because we as an industry are not only fixing the vulnerability, we’re mitigating the exploit technique. They don’t need three zero-days; they need six now to maintain the same capability they had before. That’s really the way I think about it and what makes me hopeful – where I know a lot of people can feel down and that zero-days are this sort of impossible problem to solve – is the exciting part is iterative progress we will see the return on investment from. So, it’s not that you have to do steps A through J and that’s the only time you will begin to see this return on investment. Every little step we take forward in this to make it just that much harder – they just can’t use the variant on this bug, we fixed this exploit technique; every single one of those actions make it harder. So, that’s sort of the way that I view this whole problem.
JACK: So with all this effort, is it working? Is Project Zero actually making it harder for people to make zero-day vulnerabilities?
MADDIE: I think on a long scale, definitely since 2014, zero-day has become harder. But I think what’s hard is that to me, at least, it’s pretty obvious that it’s not hard yet. For example, for the first six months of the year through 2022, what was it? There was a huge percentage of the zero-day – in-the-wild zero-days were variants of previously-patched bugs. Okay, fifty percent of the in-the-wild zero-days from 2022 as of mid-June were variants of previously-patched bugs. That makes it really hard for me to look at, of – we had chances to block one and two of these zero-days that we as an industry didn’t take. Twenty-seven percent or twenty-two percent, somewhere in that range of the in-the-wild zero-days from 2020 are even variants of in-the-wild zero-days from 2021. So, the attackers could come back less than twelve months later and just use a variant of the bug again. So, I think there’s – I’m more focused on what we can do and the opportunities we have rather than smirking at the news as much. But of course we’ve gotta take the wins when we can get them.
JACK: You used this term before; private state-of-the-art versus public state-of-the-art. What does this mean and how does it apply to you?
MADDIE: So, in vulnerability research publishing, what’s the new attack surface? What’s the new bug class or exploitation technique that we consider state-of-the-art in terms of novel, a great way to bypass new exploit mitigations, et cetera? So, offensive security researchers like my team, we publish a lot to show oh, we found this new way to bypass X to help show this is what has to get fixed and this is where its weaknesses lie. So, that would be the public state-of-the-art, because it is offensive security researchers talking about it publicly, of this is where the techniques stand right now. Private state-of-the-art is, but what techniques do the attackers actually have? So, part of the reason why I focus on zero-days that are actually exploit in the wild is because it can help us close that gap between public state-of-the-art and private state-of-the-art, because a lot of the time we use public state-of-the-art to help inform what is the next area of research that we should focus on. But if that’s diverging too far from what the attacker is actually doing, then this research is not as useful to us because we’re not having what we call those collisions with attackers and trying to fix bugs and vulnerabilities. We’re not putting our resources in areas that are super-useful. So, that’s what we mean by – when we say or I say public state-of-the-art versus private.
JACK: That’s a really interesting concept to me. We know what’s out there when it becomes seen, but we don’t know what hasn’t been discovered yet, and what hasn’t been discovered yet could be a hugely overlooked use of technology or capability that we just haven’t been creative enough to imagine that scenario. So, it becomes almost a theoretical question; what theoretically could attackers do today, and how can we look into those areas to try to figure out what they are working on to stop them to make us all more secure?
MADDIE: Well, one of the things I think is most promising is that in 2021, there were the most in-the-wild zero-days ever – since we’ve been tracking since mid-2014 – detected and disclosed as in the wild. That might sound sort of – not make sense why I think that’s promising to some people, but I think it is because I didn’t say we can’t track the number of in-the-wild zero-days used; we can only track the number of zero-days in the wild that are first detected by someone and then disclosed as hey, in the wild. If folks are finding them and reporting them to other vendors and never saying hey, this is in the wild as well, it’s not just another vuln, then there’s no way for us to know about it.
So, I do think in the last three or so years, there have been huge improvements across the industry of people working on detection and trying to find zero-day exploits, not just brushing it off and saying this is an unsolvable problem. I’m also really hopeful of the trends and transparency around these. I think there’s still plenty of progress to make in the transparency space around these zero-day vulnerabilities and exploits. But I’m hopeful that we’re having more and more vendors transparently disclose when something is being actively exploited, that they’re – some vendors are making it easier to figure out which patch in open-source software goes with a CVE and getting more robust descriptions of it. My hope is then we get to areas where they’re doing these detailed and publishing root cause analyses and doing more variant analysis on their own rather than third parties like myself and my team and some other security researchers coming in and doing that work.
JACK: Yeah, I think I would like to see on my phone whether or not I was exploited. If there’s some sort of play protect feature that says oh, we’ve updated this; wow, somebody was actively exploiting you, big notice there, I want you to know.
MADDIE: Yeah. I think that would be super interesting, and I – that is one area that’s been growing, of lots of different researchers trying to figure out how do we – what type of forensics do we look for? These are sophisticated actors, so they’re also pretty good at cleaning up traces, and zero-day exploits don’t always leave a lot of traces, so how do we figure out if someone had spyware running on their phone, if they had an exploit delivered to their computer or device. Citizen Lab and Amnesty International are also doing some really awesome work in this space, as they also work closely with the targeted populations.
(OUTRO): [OUTRO MUSIC] A big thank-you to Maddie Stone for coming on the show and talking with us about zero-days. You can follow her on Twitter and see what she’s working on. Her name there is @MaddieStone. This show is made by me, the zero – just zero – Jack Rhysider, editing help this episode by the reverser, Damienne. Mixing is done by Proximity Sound, and our theme music is created by the botnet known as Breakmaster Cylinder. I saw a really big cell tower the other day and I just walked up to it and I looked up all the way at the top, and I was like, whoa, that’s really high tech. This is Darknet Diaries.
[OUTRO MUSIC ENDS]
[END OF RECORDING]