EP57 Stop Zero Days, Save the World: Project Zero's Maddie Stone Speaks

Security. Hi there. Welcome to the Cloud Security Podcast by Google. Thanks for joining us today. Your hosts here are myself, Timothy Peacock, the product manager for threat detection here at Google Cloud, and Anton Chuvakin, a reformed, tamed, much nicer now former analyst and an esteemed member of the cloud security team. here at Google. You can find and subscribe to this podcast wherever your podcasts are sold, as well as at our website, cloud.withgoogle.com/cloudsecurity/podcast. If you like our content and want it delivered to you piping hot every Monday Pacific time, please do hit that subscribe button. You can follow the show and argue with your hosts on Twitter as well, twitter.com/cloudsecpodcast. Anton, this is a tremendously fun episode because we have somebody who is contributing to the mission of making the world's information universally accessible and useful in a way that I found surprising and yet completely true at the end of the day.

Yes, I definitely agree that I had a few profound realizations during the podcast because while sometimes people make loud proclamations about how they're really making the world more secure, making the society more secure, but our guest really does do that, really. And that to me is kind of fascinating.

Yeah, it's an interesting episode because we get to cover a lot of ground on both the technical side, the economic side, and the human side of an issue that often people only look at one of those lenses at a time.

Yes, correct. And of course, we didn't mention the actual topic. Those who clicked on the episode on the website already know it's about zero days.

Yes.

So it has additional magical flair of ominousness on top, right?

What could be more ominous than zero days?

Zero trust.

Oh no, not zero trust. Let's stick today's episode to zero days, not zero trust. And with that, welcome our guest. I am delighted to introduce today's guest, one of the bigger celebrities we've had on the show so far, Matty Stone, a security researcher here at Google. Matty, we are delighted to have you today. One of the things we wanna start out talking about is there's a lot of industry debate around the risk of zero days to organizations. You know, some people are like, oh, zero days are rare, you don't need to worry about that. Some people say, you know, zero days are unstoppable and they're monstrous and they're horrifying. How do we think about the real risk of somebody attacking my org with a zero day? Does it depend on who the org is? How do we think about this?

So I think there's 2 sort of questions and way to break it up there. And I think the reason why my team, Google Project Zero, and I care about zero days is the fact that while they are in fact targeted exploits, they're not things that are generally, you know, sprayed against anyone and everyone. Even though it's that limited target, they tend to have a very outsized impact and a societal impact. Even though you may not be the person being targeted with the exact zero-day, your company may not be the one targeted with this zero-day exploit, a lot of times these actually have impacts on the rest of us. For example, if someone is trying to hack an election in a country and they're targeting certain people that are critical to that election with these zero-day exploits, then it tends to affect a lot of us around the world or in that country as well. Or, you know, if certain minoritized populations are targeted, then that tends to have this like effect across the whole population in the world we live in. So I think that's one important point and why when we're thinking about zero-day exploits, it's really not just, are they gonna hack me with it? Are they gonna hack my company? So then sort of we get to that second part of the— question of, okay, how concerned do I need to be about being hacked, you know, individually as a company or an end user? And in general, yes, they are very targeted. They tend to be a capability that many attackers who use them don't really want them burned. It took a lot of resources, whether it's money or time or specialized people to build it, that they would like to get a good amount of use out of it. And therefore, you know, gonna be a little more deliberate in who they target. In general, probably most companies across the board, most end users do not need to worry about that targeting. However, if your company, say, doesn't have the best patching practices, if a lot of your users can be targeted with phishing, then those same attackers could just do that with this less technically sophisticated option. I think that's the, you know, other way we need to think about these zero-day exploits is, are you going to be hacked is sort of the question we want to get to. If you are more technically sophisticated, a special target, then they may use zero-days. But if you're not, you can still be hacked and have that same effect on you. It doesn't cost them as much to try and do it, and thus they don't use zero-days. Does that sort of answer the question?

Yeah. And there's a really interesting dynamic in there that I think might be interesting for you to speak to for our listeners around the wielder of the zero-day wants to get a good return on their investment with that zero-day, but they also worry about getting Burned, as you said. Could you tell our listeners what you mean by that and what that dynamic looks like in practice?

My team's mission is make zero-day hard. And hard is a really hard metric to actually define and measure. And so what we sort of interpret that is, is basically it costs more for a capability and it has a shorter use. So that return on investment keeps getting smaller and smaller and smaller when it comes to zero-day. In terms of getting burned, it's no longer a zero-day exploit when the defenders know about it, when there's patches out there, when there's antivirus signatures, when all these detection and intrusion teams know this is what I'm looking for, something targeting— the exploit looks like X, it's going after this vulnerability. The attackers no longer have that sort of ability to sneak in with something no one knows to look out for.

Mm-hmm.

So that's what we mean by burned is we want to get information about it out there fast, get information to whatever vendor it is, out there, so it's no longer that super special capability that attackers can use.

So in light of this, I wanted to sort of turn back to the framework of judging the risk. I don't know why I'm so obsessed about it. Maybe it's my analyst past when analyst firms made loud proclamations that most normal companies shouldn't really worry about it because if you patch Windows twice a year, then you have many, many, many bigger issues than zero days. And of course, you mentioned phishing, as well. Can you build us a little bit of a framework how to think about it? So if I don't make aircraft parts, but I make, I don't know, shovels, am I at risk? Of course, I may think no, but you may say, what if I'm a supplier for somebody who makes spacecrafts, and suddenly I am at risk? How would I think about zero-day risk for me if I am a company?

Basically, you start with making sure you're safe and protected against the least technologically sophisticated attacks. First off, can your systems be compromised with just run-of-the-mill malware that has been documented, people know about, signatures exist for? Can then your company or networks be compromised through phishing? Can it be compromised through in-day exploits, you know, ones that have patches available and we know about? And if you are then sophisticated and protected against these less technologically sophisticated attack vectors, that's when then you can really start focusing on the zero days. 'Cause otherwise, sure, you may be blocking against these super sophisticated attack vectors, but you're allowing the attackers to come at you with things that cost them a lot less money, take a lot less resources and a lot less time because they're known ways to attack. They don't have to put in the effort to find a brand new vulnerability and build a whole new exploit chain and find out how to deploy it. While more people may be targeted, we got to start with the basics and make sure we're robust and protected against those first before we start looking at the zero days.

And I think that answers it nicely because for a vast majority of companies, they never depart the phase called, I need to fix the basics. They fixed the basics in 2007. Hey, happy new year, 2027. They're in, oh, we need to fix the basics. And that sounds like they shouldn't be concerned with zero days. They should be concerned with— The basics. Okay, fine. Maybe I'm more cynical today. What a surprise. Tim, yours is next.

I don't think you're more cynical today. I think this is about a standard level of cynicism on the show. I want to shift gears a little bit, Mati, and talk about cloud because, you know, I care all about cloud. That's my day in, day out. What about zero days in cloud? You know, we hear a lot about iOS zero days and Windows zero days and Android. What about AWS and Azure and GCP? Are we seeing zero days there?

In the cloud. Let's just not name names. It'd be safer for all of us. Big public cloud providers. I've heard there are 3 of them.

Yeah, 3 unnamed cloud providers.

I actually posed this question while I just finished doing this year in review of all of the zero-day exploits known as in the wild in 2021. There are no cloud-targeting zero-days, and there actually aren't any since mid-2014 when we started tracking all of this data. So there's never been a known publicly disclosed as exploited in the wild zero-day for cloud. This sort of brings up 2 questions for me. One, is the detection work not happening? Are people not going through and trying to find these exploits? Because finding zero-day exploits, finding exploits that are targeting something you don't know about are really hard and it requires a really concentrated effort and creativity to try and come up with ways to find them. So if you're not detecting them, we're not going to have them list even if they are being used. And then second, are they being publicly disclosed as exploited in the wild? Because that is the second piece of the puzzle. If certain vendors are hearing about this happening and like, hey, it was reported to them, and whoever reported say, hey, this is actively exploited, you may want to get it fixed faster. If either that reporter or the vendor doesn't come out and say it, then we're not gonna know about it either. So there's this sort of 3-part question to the fact that we don't have any. Is it one, are attackers actually using these? 'Cause you can't detect or know about things that aren't happening, which I would say pretty confidently, there's at least been some, you know, it's just too ripe of an attack surface not for folks to be looking at it. So then that really breaks down to 2. Is it one, lack of detection?

Mm-hmm.

We don't have the capabilities to find them, or just the resources haven't even been put in to build these capabilities to find them? Or 2, is it happening, but those finding them or those fixing them aren't disclosing it publicly that, hey, this was actually in the wild, it's not just another vulnerability?

That's really interesting. This kind of reminds me of a conversation I was having recently about cloud ransomware. We haven't seen a lot of public cases about cloud ransomware, and I wonder if that's because the attackers are still finding it so profitable operate elsewhere. And I wonder if in cloud it's still so profitable to attack the things running on top of cloud that adversaries aren't having to move down to the cloud infrastructure itself.

Maybe. I would find it hard to believe with just the number of folks that I would think would be interested in gaining access to the infrastructure that there are none. But it's hard to find such small things, especially when you think of like who could actually be doing this detection work. You know, when it's iOS and Android, While of course those vendors are gonna have more visibility into what's happening across the devices through maybe telemetry or something like that, end users, individual security researchers can still do some work to try and hunt these down or find them, you know, especially with the browsers. But with the cloud infrastructure, it'd sort of be like, who can emulate that type of situation as individual researchers or stuff like that to try and hunt them down and do that detection?

And also, we can point out that the detection side of the cloud providers, like, well, us, are probably the best of the best of the best of the best security engineers on the planet. So if we are not seeing them, there's a decent chance we're not being hit by them. Like, I'm sorry, I'm an optimist in this little fragment of a discussion, but I feel like if we're not seeing them, they're not happening to us because, again, of the quality of the detection. Yeah, okay, fine. I see you're smiling, so it wouldn't show up on audio, so we're going to drop the subject. That's great.

Listeners, you can take Maddy's silence as she doesn't believe Anton. It's great.

Okay. Now, the other fascinating subject. Of course, I spent a couple of nights reading Kim Zetter's book on the zero days and all this stuff. And what struck me in that book is like the whole obsession with pricing. I know that pricing matters. And like Maddy, for example, mentioned the fact that Zero days are costly to develop. They're big numbers, you know, even if you look at what black market pays, what white market pays, big numbers. So, what does pricing for zero days tell us? Is your team succeeding because the price is growing? Like, make zero day hard means make zero days expensive, right? Or am I thinking about it all wrong?

It does, in a way, make things more expensive, require more investment for a capability that gives you less returns. But I don't think that pricing always actually equals expensive in those terms, because it also can be driven up in terms of things like demand as well. And so I use it as a data point when looking at, like, especially when we're talking changes in magnitude of increases in prices. I think that can be just an interesting thing to keep in mind, but in general, The pricing for zero days going up, I don't think is something that we can use, even though it may make us feel better about our jobs of like, hey, I want to put up on my performance evaluation, price of this zero day went up, clearly it's all me or whatever. But no, I don't think we can take that as what that means because also, if you're selling a zero day to certain entities versus others, Like generally we've heard from black markets and stuff like that, that selling to Five Eyes countries tends to, you sell for lower prices than say other geographic regions or regions that might be on sanctioned lists and things like that. To me, it's, you know, numbers in a game that I don't put a lot of, not confidence, but I don't put a lot of stock in that. Stock. That's the word.

That's really interesting that there's different pricing dynamics depending on to whom you're selling these things. That's fascinating. I hadn't considered that.

And I love it how it's like so nice and corrupting. Like the bad guys pay more than the good guys. Like this is like almost like a moral test. Okay, that's not a subject of our podcast, but it's still kind of fascinating how the good guys pay less and the bad guys pay more. Like this is satanic.

Why don't we shift gears before we learn a lot about Anton's inner political leanings? Matty, could you tell us about a day in the life of a zero-day explorer here at Google? What does that actually look like? Do you sit in a dark room with thumping music? Like, what does it look like?

It's usually country in my case.

Country, okay.

I'm all about the country music.

And is that the good country music or the bad country music?

Both.

Both?

You gotta support the bad country music too. So it sort of looks different on a day-to-day basis. I work closely with other teams within Google as well, which I think is really a cool aspect, like Google's Threat Analysis Group, Google Chrome, Google Android. across the board to come up with what are areas where we can make progress to make systems more robust for better detection? How do we all partner together? And so that's really exciting, you know, to not just be working on your own all the time. A lot of it is just staring at disassembly and bytes because I'm looking at one, either exploit samples to figure out what vulnerability were they targeting and how were they exploiting it? 'Cause exploits really are 2 parts. You can't just have a vulnerability, you also have to come up with an exploit method to make it useful.

Hmm.

Trying to figure out what those 2 chunks really are and then sort of taking back of what can we learn from it? Because each time a zero-day exploit is discovered in the wild, it truly is the failure cases for attackers, sort of as we were talking about of trying to burn zero-days or burn vulnerabilities. We want to sort of milk as much information as we possibly can from that finding. And so also then performing things like variant analysis on the vulnerability.

Mm-hmm.

A lot of vuln researchers find more than one vulnerability at a time because that bug pattern lives in many different places around the code base, or you're looking at a new attack surface for the first time, which hasn't been thoroughly audited, so you find a lot. So then as defenders or vuln researchers who want to get as many vulns patched, we then try to apply that same sort of process to, oh, the attacker found and used this vulnerability. what other ones might they have found that looks similar to this?

Mm-hmm.

And that's sort of that trying to make it that much harder that they can't just plug and play a new vuln in once this one has been patched. Also sometimes spurring into new areas of research. I'm really lucky that I work with like a lot of really awesome vulnerability researchers across many different platforms. And so while I'm sort of a generalist with all this zero-day exploits, looking at all the different platforms from, you know, even Internet Explorer to WebKit, Safari, Android, Windows, etc. Each of my teammates are really experts in deep dives in each of those, so partnering with them to be like, okay, I've got to this level, what also do you think this means? What should we take from that? And lastly, partnering with lots of vendors and communicating with general public about like, how do we actually make this more difficult in the long haul? Because Each of these zero-day exploits oftentimes really do have this human impact. Someone is being harmed through the use of it. And so remembering that this isn't just this cool technical problem, it has real-world impacts. So how do we make sure that we can try and limit the amount of harm that comes in the future and make sure we're doing everything we can in that respect?

There's a really real motivation at the end of the day behind the work you're doing.

Absolutely. This past year, I mean, it's been over and over and over more headlines of people who are actually having their devices targeted, especially sort of from the commercial surveillance vendors. And this has really big impacts to not just, you know, digital privacy and having, you know, their lives opened up, but physical safety as well.

Mm-hmm.

And so trying to make sure though that we can help these people, 'cause a lot of them are trying to, really stand up and be human rights defenders across the world or journalists and that they can be safe and continue doing this like really important work is something that definitely drives me as well as like just how cool would it be if we lived in a world where everyone had safe and secure access to the internet?

Yeah.

Regardless of price, your device is secure. Like that just seems like an amazing world I want to live in where everyone can access information, talk to people, It doesn't depend on who you are or what you have to access.

Yeah, you really are a key part of the— like, as cheesy as this is going to sound and you're all going to make fun of me— you're actually a core part of the mission of Google of making the world's information universally accessible and useful. It's not accessible and useful if you worry about your security. That's fascinating. I hadn't thought about that.

Me too. And I think the human cost is something that Maddy mentioned multiple times, and it's kind of stuck in my head at this point because I was a little bit leaning towards like technical challenges, how to solve it. I was not focused that much on the human cost. So I can— it definitely switched something in my brain. Thank you, Maddy, for this. So I want to switch gears a little on the defense side. And of course, lots of vendors try to sell this and this, whatever technologies. But let's think about it in the most strategic manner. Certain defenses, certain security controls clearly rely on the knowledge of the attack. And so a zero-day would not be stopped by them. But certain other types of defenses, I'm thinking allowlisting, I'm thinking like turning off certain functionality are clearly— I guess you may hate me for the term— zero-day proof. So how do you think about the defenses against zero-days? Broad question.

First of all, it's thinking about who you are and who might be targeting you with zero-days. Because again, this is, as we've talked about, generally a relatively small target population, especially when you consider, like, do you think you are going to be targeted by, say, one of the commercial surveillance vendors or a nation state or whatever it may be. If you are one of those people and zero-day is a large risk for you, then it's thinking about what are sort of those TTPs, that's a threat intel word that I'm stealing. What are the techniques they're using? So like, for example, a lot of the commercial surveillance we've seen over the past year has been they send one-click links. So they send a link to someone, maybe through email or SMS, try to make it seem relevant, and when they click it, it actually goes to that attacker's exploit server, which then delivers the exploit chains. So if that's you, then maybe not clicking on those types of links. But in terms of actually being zero-day proof, I think it would be something along the lines of like you can make yourself protected against JavaScript exploits if you turn off all JavaScript in your browser.

Yeah.

That's not a great internet usage option for a lot of people, but that's really, I think, the extremes you have to go to to really have that confidence in CRD proof. And in that same way though, then you're really only protected against those browser exploits that are targeting JavaScript. You'd still be vulnerable to DOM exploits. And so if you don't wanna be targeted by browser exploits, then it's really at that point don't use a browser. Trying to hit that zero-day proof metric is probably unrealistic for any of us. I mean, that's why these zero-days are such a sophisticated capability, especially if you're a company or corporation maybe trying to track the behaviors of what might happen if they got access. So are they trying to install an implant that sends information back? Then maybe that's what you detect. So You got exploited, but if you detect that really quickly, then maybe the impact is not actually that great. So yeah, there's really not a great answer to that zero-day proof question overall.

Maddy, this has been a wonderful conversation and I hate to have to wrap it up, but I'm gonna ask our last 2 questions. Do you have, one, recommended reading for our listeners so they can go learn more about this? And 2, this is kind of an odd one, do you have a recommendation for people to be, I guess, better at finding zero-days or not getting popped by them? Like, what's your Do you have an actionable tip for our listeners?

Further reading, if you check out the Project Zero blog, we tend to talk about getting really into the nitty-gritty sort of details of the bits and bytes of these exploits, as well as I publish year-end reviews. The 2021 one will be coming out soon, but 2019 and 2020 is actually up, as well as the Google Tag blog also publishes more from that threat intel, the context behind it point of view of zero days. So highly suggest that. And one action item I would give, I don't think it fits exactly what you're asking, but one area I think where we'll really see progress is if end users and companies, customers of the big vendors, pushing the vendors whose products you're using, asking them, are you saying that you will publicly disclose anytime you've heard that there is an in-the-wild exploit and vulnerability?

Mm-hmm.

So will you annotate your release notes? And What work are you doing to make yourself more robust and your software devices more robust about this? Do you have teams working on zero-day detection? Are you doing things like variant analysis and exploit mitigations each time one of these comes? The first one I would say is the disclosure and the transparency around them is what I think will make the biggest progress step first.

I really like that answer. Maddy, thank you so much for joining us today. This has been a terrifically enjoyable conversation.

Thank you all so much for having me. I'm honored you invited me here. Thank you.

And now we are at time. Thank you very much for listening, and of course, for subscribing. You can find this podcast at Google Podcasts, Apple Podcasts, Spotify, or wherever else you get your podcasts. Also, you can find us at our website, cloud.withgoogle.com/cloudsecurity/podcast. Please subscribe so that you don't miss episodes. You can follow us on Twitter, twitter.com/cloudsecpodcast. And your hosts are also on Twitter at Anton underscore Chuvakin and underscore Tim Pigo. Tweet at us, email us, argue with us, and if you like or hate what we hear, we can invite you to the next episode. See you on the next Cloud Security Podcast episode.

Security.