Zero Day Markets with Mark Dowd

We have Mark Dowd on, founder of Aziumuth Security and one of the authors of The Art of Software Security Assessment, to talk about the market for zero day vulnerabilities, and how mitigations affect monetizing offensive security work.

Links:

This rough transcript has not been edited and may have errors.

Thomas: Welcome everybody to security cryptography and also whatever I am. Thomas. And with me, as always, is Deirdre.

Deirdre: I’m Deirdre.

Thomas: Hi, Deirdre. I’m really psyched with us today. Mark Dowd. Mark, thank you for being on.

Mark: No problem. Thanks for having me.

Thomas: So Mark and I came up at roughly the same time in vulnerability research. And the difference between me and Mark is that Mark is actually good at it. And then we have wanted somebody like Mark on the show for a long, long time, maybe from one of the first episodes. And I will say that is primarily because I am going to conclude so many stupid message board arguments with this podcast. I can’t tell you how many dumb threads I’m going to be able to shut down or I myself will be shut down, but either way there will finally be closure. So Mark is, if you’re not familiar with his work, Mark is one of the co authors of the art of software security assessment. Mark, do you have any idea of what copies of the art of software security assessment currently cost?

Mark: No. I know that hard copies are hard to come by because they are out of print. So I’ve seen them available like $200.

Thomas: I have a small stack of them. They’re running for upwards of $400 right now. Yes, but the Bible of software vulnerability assessment. And obviously that’s one of the things you’re best known for. But like, you know, ordinarily like a couple of years ago or whatever, if we were talking to you, I would be talking to you about vulnerability research. I’d be talking to you about why you’re so much better than me at this stuff. But I think what we really want to talk about is the last couple of presentations you’ve done and like the work that you’ve been doing over the last several years because that work involves markets for software security exploitation. So I guess here’s the part where I let you kind of finally start talking.

Thomas: But like if you can give me kind of just a high level, like how you got where you are, the thing that you’re doing right now from kind of the work you were doing, kind of vendor based commercial software security assessment stuff.

Mark: Yeah, sure. As you mentioned, I started off doing vulnerability research. One of my early jobs was working at a company called ISS, which is not the space station, it’s Internet security systems, which is now part of IBM. They got acquired at some point, but I was doing vulnerability research there in much the same fashion that Project Zero is now where we find vulnerabilities, report them to the vendor and then put them out in public and then give talks at Black Hat and other conferences and so on. At some point I left there and I started azimuth Security. This was actually not long after we published the out of software security assessment. So we started, I started azimuth security with one of my co authors, John McDonald. And we started going into the market that you’re talking about of doing vulnerabilities with intelligence agencies and so on, like basically vulnerability research for the government markets.

Mark: We actually didn’t intend to do that initially. We started off doing regular application reviews and so on, but we always had much more interest in doing vulnerability research. And when we found a constructive way to do that, we’re like, this is so much more interesting. And also, hopefully it’s doing some good. And quite frankly, it involves way less conference calls and paperwork. So yeah, we did asthma security, ran that for about ten years, which was then bought by a defence contractor in the UK called L three, who was subsequently merged with Harris. So they’re called l three Harris now, Harris being a big us defense contractor. So I stayed working at L three Harris for several years after we got acquired there and then quit and sort of did not very much for about a year, a handful of keynotes and presentations and stuff like that.

Mark: And then started this new company, Vigilant Labs, which is also in a similar space as what was in.

Thomas: So like some months ago you did a presentation at Blue Hat. I think probably most people listening here know what blue hat is, but if you don’t, Microsoft annually puts on one or two, like internal security conferences, and they’re called Blue Hat is going to homage to black hat whatever. You gave a presentation at Blue Hat Israel some number of months ago and it was just kind of like a, like a state of the markets for software security vulnerabilities. Yes, sir. And the slides for that just now came out. So, like, I think that there’s obviously like a lot of mystique and a lot of mythology about how vulnerabilities are priced and who buys them. And I think we can get kind of a long way just kind of talking through those details. I want to kind of start with, um, like my favorite slide in the entire deck.

Mark: Okay.

Thomas: So, like a lot, a lot of people are familiar with the zero DM chart, which is like one of the few, like, published. Here’s like a, you know, a rack rate price list for all the, you know, different kinds of vulnerabilities that you might sell. And on the slide, you point out, it says that, uh, it’s like for a full chain with persistence, Android vulnerability, or zorodium will pay up to $2.5 million, which is a crazy number. Right. Um, and the next line, the slide is the words up to are doing a lot of work.

Mark: Yeah.

Thomas: In that price list. Can you expand on that?

Mark: Yeah, before I do. So, yeah, Blue Hat was last year in April, and this was actually, I gave a similar presentation the year before at Qualcomm security summit as well. In both instances, I had asked them not to publish because I didn’t really want to be a spokesman for the zero day industry or whatever, but. And whatever. Here I am. So going back to the slide, you’re talking about basically what I was trying to say in that part of the presentation was that all vulnerabilities aren’t the same. In fact, they’re really unique. They’re not like burgers or something where everyone is the same as the next.

Mark: Each of them have unique properties that make them more or less attractive to a customer. And it depends on what their customers mission is and also a lot of details around the vulnerability and the exploit itself. So in the case of where they’re talking about basically a full chain for Android, on the surface of it, that sounds great, right? Like a full chain, remote code execution. Android vulnerability or set of vulnerabilities is very powerful. But then if you’re the buyer, you have to start thinking like, okay, wait a minute, which androids? Samsung. Yep. Huawei, Xiaomi, like which of these are actually affected? And then can you identify a target before you throw it? If you throw it against the wrong one, what happens? Is there visual artifacts? Does it lock up the phone for five minutes or something? Does the user have to do anything? Does something happen where they going to notice it? Or how difficult is it to deploy? Like does it require a base station or something? Or can you just do it remotely with just their phone number or something like that? So there’s actually a lot of different factors in a quote unquote remote, full chain Android that can make it either extremely desirable or not usable at all for a number of customers. So giving a figure in the way that zerodium does, they’re covering all of these cases.

Mark: And basically when they say up to two and a half million or whatever, they’re talking about the specific best case scenario and merely nothing they come across will actually live up to that.

Thomas: So I guess my first question there is, there’s an example on your slides of like, the difference between a baseband vulnerability and like a vulnerability and say imessage or whatever. And like there’s certainly more like street cred to the baseband vulnerability. It’s more sexy, you know, it’s at a lower level, it’s seemingly, you know, more widespread but it’s also harder to actually deploy, right. Because you have to be essentially like, you know, a layer one hop away from your target, right? So not a deal breaker, right. Because if you, you could sell that to somebody who has control over local carriers, right? And they could just deploy it that way, right. But like obviously like some of these issues with, you know, what’s valuing say a full chain persistence Android vulnerability, right? Some of that is a property of the vulnerability that you found, right, where it is, how easy this is to deploy, does it involve user interaction? And then my understanding of what you’re talking about in general is that some of it is also a property of kind of the engineering around it where you have the vulnerability, you have to build out the exploit. To what extent does the price vary just in terms of how well the exploit is designed?

Mark: It very much depends on the vector. Like you were suggesting, if you have a vulnerability in say imessage or something, that’s really great. It’s far better than baseband actually because all you need is like their Apple ID or something in theory.

Deirdre: Oh yeah.

Mark: And so you don’t need, as you said, you don’t need rogue base stations, you don’t need carriers to participate or anything of that nature. But the engineering can make it, the properties of the exploit itself can make it either desirable or not very desirable. For example, as I was alluding to earlier, if you can’t identify what the other side is running and the consequences for getting it wrong are significant, that could be a problem. The ability to make it reliable when you’re doing it, you know, blindly and remotely obviously is a huge factor of how useful the exploit is. And there might be other things that are a product of not necessarily the fact that the author has done anything wrong with the engineering. It might be specific constraints of the particular vulnerability itself where like okay maybe you can do something remotely with imessage but you can’t really get code execution. You can maybe read a file or something instead. So there might be other limiting factors, but usually the limiting factors around reliability and yeah, being able to deploy it in a manner that’s useful.

Thomas: I guess a question I have is if you start from like a baseline of, let’s say the baseline is this is probably not a reasonable baseline is going to reveal how little I know about your, about your work, right? But let’s say the baseline is just somehow the vulnerability is reliable remote code execution. And we’re back to Android vulnerabilities here, right? And we’ve got this scale where, you know, the vulnerability could be worth zero or it could be worth $2.5 million is just an abstract number, but let’s just call that the ceiling, right? What are the hardest to get things there, like what are the things that are, that escalate the price for the vulnerability that are the most scarce or the least likely that you’re going to.

Mark: Find the ultimate goal that most people have. And again, this very much depends on who the buyer is. But in terms of remote vulnerabilities, ultimately you want something that is silent, fast, ubiquitous and reliable and yields like the largest compromise possible. So being able to do something remotely through messaging, apps or iMessage and things like that, satisfying all those requirements if you can bypass the various security mitigations and achieve that. But doing that is generally a lot more complicated than say, browser vulnerabilities, since with a browser you generally have a JavaScript engine to manipulate. So it’s a lot more friendly to exploitation in general. So a lot of the time when you’re doing fully remote zero click vulnerabilities, you very often don’t have quite as friendly as a situation as you do in the browser perhaps. And also doing things blindly then makes it an additional layer of complexity.

Mark: If you don’t have some kind of, you need some kind of info leak or some kind of weird machine to manipulate or something like that. So that’s the ultimate goal for a specific class of customers, I would say.

Thomas: So like how big of a deal is the silence part of that whole thing? Right? Just because I’m in the field that I’m in, anytime anything on my computer crashes, my heart skips a beat, like actually go look at the stat trees, even though there’s no possible way I’m going to learn anything from it. So I can imagine you’re looking for not visibly crashing components and things like that, cause that’s how you’re gonna get burned or whatever. Is that a huge component to the price of it or. I have a hard time getting my head around if you have heterogeneous targets, if you have every possible Android phone and you can’t precision target it, you don’t have a channel to figure out, okay, this is the right kind of device for this kind of exploit. I can’t imagine how hard that must be to build an exploit that’s kind of, even if it just works when it works on the right target but doesn’t blow up visibly somewhere else. Yeah. Is that really hard to do? Is that as scarce or as difficult as it sounds? Yeah.

Mark: So one of the things I touched on in that presentation was a lot of things that you see come out in public research. Sometimes researchers will release exploits and I talk about how they’re often not in really a saleable condition because either they’re not particularly reliable or they’re like, it’s reliable on the two phones that I have on my desk kind of thing. And also, by the way, I know everything about what version they’re running and et cetera, et cetera, et cetera. Taking things from there to working somewhat ubiquitously, even on a subset of targets, is often the bulk of the work. Taking something that works a fair bit of the time, like 70% up to like 95 plus percent, but also works on a wide variety of targets, is a great deal of engineering, and it’s a very difficult task and is often quite time consuming.

Thomas: I’m wondering is that generally, I’m sure it depends on the circumstances, but is that property generally more a property of the vulnerability, or is it generally more a property of the engineering effort that goes into weaponizing the vulnerability?

Mark: It’s a little of both, but there’s, I would say, a great deal to do with the engineering for particular vulnerabilities, usually for memory corruption ones, you’ll have some kind of primitive, and the primitive might be nice or not very nice. So nice one might be that you get to corrupt at a chosen location within reason, with data that you can control and size that you can control and stuff like that. But many vulnerabilities don’t really have properties that are quite that nice. And so to some extent it depends on the vulnerability as to what you’re able to do. But then some of the best exploit writers will then show quite a creative flair for turning something that’s seemingly not very great into very reliable and robust exploit. And those can drive up the value considerably.

Thomas: I would say you give an example of stage fright, right, which is like very well publicized Android vulnerability. And like the headline for that vulnerability was that it impacted the overwhelming majority of all Android phones. And your take is that like, if I’m on hacker news talking about stage fright, I’m going to say like wolves or odium says it’s up to $2.5 million and stage fright, perfect example of a $2.5 million vulnerability. And your take would be that it is not. What are the things that make stage fright? Reliability primarily, or are there other things to it?

Mark: Okay, yeah, so there’s a couple of things. And this was going back to when it was in the news. I can’t remember what year it was, but at the time there was a multitude of vulnerabilities within the stagefright library and some had better properties than others. But there was a lot of talk at the time that’s like, oh, this is the end of the world. Like, this is the biggest vulnerability this is worth resilience, et cetera, et cetera. Whether that’s true or not, though, is a large part of the value proposition was left out of the public commentary, which is how actually useful is this? We had a number of the top public researchers in the world talking about stage fright for quite a long time, and they more or less did not really come up with a useful one that could be done remotely over mms in some like stealthy way. Like, I think one came out where they’re like, well, if you send like 2000 messages and the person doesn’t do anything to upset the heap or whatever, then this will work on some phones. The best examples of the exploit that came out at the time were actually browser exploits, which is something that project zero did, I think.

Mark: And so you’re like, okay, but I mean, we have browser exploits anyway. So I was suggesting by state fright that although the vulnerabilities were indeed ubiquitous, at least at the time, with the public research available, the ability to turn that into a reliable remote code execution that affected, you know, a bunch of handsets was not really there. In addition, the zerodium 2.5 million thing talks about a full chain, so you’d also need a privilege escalation kind of thing on Twitter.

Deirdre: So for stage fright, was the inability to get a reliable exploit and the nature of the vulnerability itself, or was it other isolation or other mitigation mechanisms in Android that just basically got in the way of people trying to write a reliable exploit for it?

Mark: Yeah, I think a combination of both. I suspect that if we went back to it today and had another look at it, we could probably come up with solutions that at the time were.

Deirdre: Not apparent solutions to crafting an exploit. Not solutions fixing the bug.

Mark: Yeah, that’s right. I can’t say that for sure, obviously, but that is my suspicion, because there’s been a great deal of research these days into doing more of these style of attacks. But at least at the time of the research that was available, it wasn’t the people commenting on how valuable and so on that it was were not taking into account that the data at the time suggested that it wasn’t nearly as useful as they were making out.

Deirdre: Kind of scrolling back a little bit. The market, not since your recent talk, but at least especially since like 2015 when stage fright was all in the news, it seems like, at least from where I’m sitting, as just a regular person who just looks at the news or whatever, the market seems to have changed, at least for the highest targeted platforms. And the players in the market, like NSO Group was a big name in buying and deploying exploit chains. And then there’s been a lot of hardening work on Android and iOS, especially with memory safe implementations of certain components and other deployments of isolation and things like that, like blast or things in iOS. Can you speak a little bit to whether those things have significantly changed the vuln market and the zero day market over the last like ten years or whatever?

Mark: Yeah, sure. So I actually vaguely talked about this in the, in that 2023 presentation, but mainly I alluded to another keynote that I’d done in Hackinthebox. I think it was talking about this. So essentially, over the last ten years in particular, there’s been a lot of work in terms of mitigations and hardening, both mitigations in terms of preventing exploits from functioning correctly, but also like hypervisor type mitigation that and sandboxes that prevent you if you successfully exploit to that, you can’t really do anything useful. So those have had a large impact on the exploit arc, because to successfully compromise a device significantly, you have to add extra steps into it, usually in the form of sandbox escapes or maybe ppl or SPGN bypasses and stuff like that for iOS. And so in order to make a fully functional chain, you constantly need to update five parts instead of like three or something like that. And finding vulnerabilities in those areas can be very difficult and you run into a potential problem as well, where if a critical part of that chain is missing, then all of it is useless kind of thing. So basically, I think that those kind of mitigations have had a large impact.

Mark: Back when stage fright was happening, they did do a media sandbox, incidentally, which was a non trivial thing to bypass, and it’s not too dissimilar to blastoir, but yeah, having to do all those extra steps makes it a lot more complicated to produce a working chain and keep it operational. And so in one of the slides I suggested as a prediction back in 2018 or something like that. But I reiterated it several times. A successful full compromise of a chain would over time become less available. Like a lot less people would have access to a fully functional chain and the price of those chains would go through the roof. So I started predicting back at the time, these are going to be $10 million plus thing. I also suggested at various points that increasingly what another result of this will be, that people in this industry will go like, okay, producing a full chain is great if we can do it, but we have to do more with less. Do we actually need to compromise the entire device to get what we need to get?

Thomas: Or could we just pull a file off of it or something like that? And that’s enough because our intelligence thing just needs that or something like that? Is that what you’re saying?

Mark: That’s right. Keep in mind that the consumers of this technology are interested in an effect, not in a product per se. The product, the exploit chain or whatever it is, is just a means to get data that they need. And so if theyre like, well, we dont actually need this whole thing, we can operate, we would like to get more data, perhaps, but we can operate with this. So they might be trying to do more with less. I would suggest.

Thomas: You said it just now and ive heard you say it a couple, ive read you saying it in a couple of other places, right? This idea that now that we’re like in an era of sandboxing and isolation, you need full chains, need multiple vulnerabilities that if any part of that chain doesn’t work, the whole thing doesn’t work, which makes sense, right? Like if one part of the chain is missing, you can’t sell it because it’s not going to give the effect. Right. But like my mental model of the way you know this would work, right, is, okay, so you’ve got a chain and one link of the chain is missing, but like the other links of the chain wouldn’t be worthless, right? Like they were just, you’re just waiting for, I don’t know if your sandbox escape isn’t, isn’t working right now, right? Aren’t you just like at that point doing research and waiting to develop the next sandbox thing that relinks that chain together? Or is it really the case that the vulnerability itself, like all of the work that you put into it, it’s all going to be counterfeit just because your vector for getting through some mitigation doesn’t work, right. I would assume these things are relatively mix and match. Right. Like each portion of the chain is kind of developed independently. Is that not the case?

Mark: It very much depends on the particular vendor. Like from a vendor point of view, it very much depends on what exactly how the vendors business model works. So there’s some vendors that just sell components. They’re like, they don’t try and do chains at all. They’ll just, here’s a sandbox escape, here’s a browser bug, here’s a whatever, and that’s it. And the idea is they’ll sell these components to agencies who will be buying from multiple places, as you suggest, and mix and match them to some degree. Incidentally, that mixing and matching part is often a lot more complicated than it sounds, because you’re just like, oh, well, I’ve got this remote thing and I’ve got this sandbox escape. Great, I’ll just click these together.

Mark: But vulnerabilities exploits are very fragile by nature and often have constraints that might mean you can’t necessarily just put two things together and have it work. It’s often a great deal of engineering. So some vendors will instead go, okay, well, here’s a whole chain of things that works together. We’ve done all of that work for you. We know that they all work together, et cetera. But if one of those components goes down, obviously the other components are not worthless. But if your business model is selling things as an entire chain, then you’re quite motivated to fix the part that’s missing, I suppose, for those vendors that.

Deirdre: Are selling like, especially those full chains. But like, you’ve already talked a lot about how, like taking a vuln and a proof of concept exploit to like a reliable, consistent, broadly deployable piece of engineering exploit. That’s some heavy duty software engineering. And I think it involves all the like, regular non offensive software engineering tools like testing and CI and making just a lot of maintenance stuff. How do vendors maintain their nicely engineered exploit software in concert with, say, a customer or deployment or something like that?

Mark: Yeah. So again, it sort of, firstly, it depends a bit on business models. So again, some people just fire and forget. They’re like, here’s the thing, we’ll sell it to you, and then it’s your problem. Other people will maintain it over a period of time. Generally, no matter what your business model is, though, you have to maintain it to some extent, because if you want to continue selling it or you haven’t sold it yet or whatever, it has to work at the time that you want to sell it. Maintenance burden, which is something that I touched on in the presentation actually is very large and often not taken into account. So I used it as a counterexample of why agencies tend not to hoard vulnerabilities, because, interesting.

Mark: I’d seen a lot of discussion in the past publicly about like, oh, yeah, NSA or whatever, they’ve just got like 50 crime vulnerabilities. I’m like, no, they don’t. Can you imagine, like, it’s quite a lot of work to maintain and exploit qubit in a working state? Sometimes a new version will come out and you don’t really have to do anything. Other times you will have to completely rework some of the crucial components of the exploit and things like that. Sometimes you basically have to rewrite them. And so if you had, like, ten or 20 exploits of targeting the same software, such as chrome, that’s an enormous amount of work to do that. And generally what would happen as well is that you basically arrive on the best way to achieve certain outcomes, and then you tend to put that best way into most or all of the exploits you have, and then some mitigation or some re engineering of the target software comes out that destroys that, and you’re like, all 20 of my vulnerabilities just went down kind of thing.

Thomas: So real quick. So there was a, there was a presentation at black hat a couple of years ago. It was also just about vulnerability markets. And, like, my one takeaway from that talk was that whatever the rack rates you’re hearing for vulnerabilities, if you’re selling through resellers or directly to agencies or whatever those payments are, the payouts are tranched, you’re getting paid in segments, and if the vulnerability is burned, you stopped getting paid. So you’re taking a risk when you’re selling it. The comparison was being made there to like, like a bug bounty that Apple would give you. Like, that’s a fixed game that you’re gonna get it no matter what. But if you sell a vulnerability to people who are actually gonna do, you know, computer network exploitation with it, right? Like, there’s, there’s a chance that will break midway through the sale or whatever.

Thomas: So when you’re talking about maintenance, like, like, the simplest, dumbest example of maintenance I have in my head is like, okay, uh, you know, a dot release of this software comes out and, like, the offsets change or something, right? Like, I have to go back in and, um, you know, just fix some dinky things just to, like, make it compatible with it, right? So if there’s a dot release that comes out, that doesn’t close the vulnerability, doesn’t actually fix whatever the, you know, the dumb, you know, use after free or whatever was. Right? Yeah, but, but it does add some mitigation. Like for instance it hardens the allocator somehow, right? So the original software vulnerability is still there, but your path to exploitation is that like one of the links in that chain is broken, you have a mitigation you have to get around. Is that still maintenance? Like at the point where you’re building an entire new component of the exploit, do you get to resell the vulnerability at that point or is that maintenance?

Mark: Generally it’s maintenance. It depends exactly what you’re talking about. But for example say you have a remote chrome vulnerability and then they go hey, we’re now putting in a V8 sandbox, then you have to do something about it. One of the quotes I have in the presentation was from Thomas Halvar Flake where he said offensive software occupies a unique position in the software market in that it does reliably what it advertises that it does or something to that effect. So the buyer, they need it to work and that’s it. So if a V8 sandbox for example comes and gets put in and you’re like well it doesn’t do that, but it does the first part, then it’s not that useful to the buyer. Now when you sell stuff, you negotiate the terms to a reseller. So what you’re exactly responsible for is not generic and you’re talking about also getting paid in trenches over time.

Mark: That may or may not be true depending on the terms that you’ve agreed to with the reseller or with the end customer. And that also might be the case to some extent for some mitigation that gets thrown into the software. But generally, yeah, it sort of depends on the nature and the extent of the mitigation, I would say. So if you have like an iOS kernel vulnerability and then a new device comes out that goes hey actually we’ve got ppl now or SVtM or something, you wouldn’t be expected to bypass that as just maintaining an iOS vulnerability like kernel vulnerability. But this is a whole other field of research that you have to do. But when they do stuff like we’d made the heap hardening thing, then that generally would be something that you’d have to do.

Thomas: Yeah, it feels sort of like you’re selling subscriptions, you’re calling it maintenance, but really they’re backloading some of what they’re paying you, right? Like whatever the terms were of that sale right, like they’re paying for the maintenance. Is that a continuing stream of revenue going forward, or is it like, did you get it upfront? Or.

Mark: Yeah, again, it very much depends on your own business model and who you’re dealing with. So in some cases, subscription models are a thing where you’re like, we’ll just keep this functioning for as long as it’s life or whatever. And then, like I said, other times someone’s like, here’s a chromebook, do you want it or not? And once you buy it, it’s yours. So recurring revenue is a possibility, but subscription models tend to, I would say, be more about the effects than the particular bug. So they might be like, we will give you, or try and give you continual RCE in Chrome, whether that’s a new bug or this bug kind of thing. For selling a single bug, usually there’ll be some kind of maintenance period. Maybe you’ll get recurring revenue if it happens to last for a long period of time and you continually maintain it. But usually they’re more kind of like fixed term maintenance contracts, I would say.

Mark: But it very much depends on who you’re dealing with and what you agree to with them.

Thomas: So you were azimuth, you were primarily selling to five Eyes governments, right? And there’s like a variety of different agencies within, you know, each of those governments. My next question, and this is not about azimuth, right. And it’s going to be you speculating a little bit, maybe, but, like, is there like a parallel apparatus? Is there like a, you know, an azimuth with a goatee on that sells to, like, the BRICS countries or Japan? Or like, is this basically how everything is driven? Or like, are there, like, does China do all this stuff in house?

Mark: Yeah, absolutely. So there is a significant number of companies like this around the world. Some of them we sort of have insight into and some of them we don’t. In countries like China and stuff, the government does have significant capabilities themselves, but no doubt they buy stuff externally from perhaps companies that are housed there, but also ones that are located within the western world or wherever. Anyone that’s willing to sell to them will enhance their capability and also give them insights into what their adversaries or even frenemies are utilising. And so a lot of these companies around the world selling to all sorts of different governments, and we only really have insight into some of them.

Thomas: Yeah, but if you had to guess, as like, a general rule, leave out the United States and leave out China, which I assume both of those are you know, big enough actors that, like, they’re distinctive in a variety of ways. Right. But if I was going to pick, like, first, one simple question, like, would it be reasonable for me to assume that basically every major industrialized country in the world is buying this kind of.

Mark: Capability from somebody in some regard? I would say probably yes. And basically, as time goes on, we put more and more data onto our phones and computers and so on. So utilizing this as a vector for gathering information, it’s sort of critical. Right. And there are a variety of potential customers of this kind of thing. So you’re probably thinking mostly of intelligence agencies which want to do this to perhaps gather information about terrorism or perhaps counterintelligence. So what their adversaries are doing, how exposed their own critical infrastructure is. But there’s also other situations where these kind of vulnerabilities are useful.

Mark: So at the law enforcement level, you probably know about celebrite and grayshift who sell devices that basically break into phones from a close access vector generally. Yeah. So it’s useful to catch criminals and stuff as well. And so there’s multiple different use cases, and there’s other use cases again, within the military and war theaters and stuff like that. So every country, pretty much every country, industrialized country that has the money to spend on this kind of stuff is doing it.

Thomas: I mean, even at $10 million for a full chain exploit for Android, that’s still like just compared to the health insurance costs of the humans that you have to roll up in trucks to do, like, collect things from people’s garbage. It’s got to be, you know, it’s got to be a pittance, right? Even at $10 million, I would assume they’re still going to sell. I should let you respond to that, but I’m not going to. You have a, you have a thing on the slide about how kind of definitionally the, you know, commercial exploit developers are a couple of years ahead of the vendors. If they weren’t, they wouldn’t be able to do the thing. Right? Is it generally the case that, like, whatever internal capabilities, large countries with intelligence signal, intelligence agencies, is the market ahead of those people, too? Or are you guys like neck and neck or.

Mark: Well, first of all, so saying the, the commercial market is ahead of public research is generally true, but not always true. Like, like you alluded to, the. The commercial market is required to be ahead in some extent. Otherwise, it doesn’t exist. When you’re depending on it for your paycheck, you’re a lot more motivated. Plus, people working in commercial and in signal intelligence agencies and stuff, know what works, what is deployable, and what is actually going to achieve an effect, whereas in public research, that is either less known, but also it’s not as an important factor. Like, if you’re interested in looking at researching whatever you feel like, just do it. But signal intelligence and the commercial areas, I only have a limited insight into what’s internally developed within governments.

Mark: I would say in some respects they’re neck and neck, but I suspect in other cases, internally, they probably have a few aces up their sleeve that we don’t really know about.

Deirdre: I think we already touched on this, but just to double down, there’s still, like, countries that don’t have their own majorly staffed up intelligence, signals intelligence, offensive capabilities, who basically are able to go to the latest zero dm or whatever, go to the latest vendor and just say, here’s eight figures, basically outsource me an offensive team. So that’s still happening even though there has been a lot of collapses or whatever. So we’re not just worried about the intelligence agencies of the five Eyes or the BRICS or, you know, whatever. We’re worried about smaller countries that have plenty of money to just, you know, outsource.

Mark: Yeah. So plenty of smaller, smaller countries or even smaller agencies within bigger countries might source a significant amount of their offensive capability externally. And that’s, I would say, pretty common practice. Because one of the problems that I suggested in the presentation is that because these are getting prohibitively expensive, in some cases, these smaller players, it can have an impact on them in several ways. One is they either have to find more budget, but the second thing is they might be priced out of the market and have to rely on second rate tools, perhaps things that don’t affect the latest or end days or whatever, or things that are less desirable in terms of their engineering or whatever. Or additionally, they might seek partnerships with someone who is in either the same sort of bind or they. Or someone who’s well resourced and is prepared to share. Yeah, share with them or do things for them or whatever in some kind of information trade or something like that.

Thomas: This kind of blew my mind. In your slide deck, do you have a slide about, you have a triangle where at the top there’s a small number of intelligence organizations and then a larger number of military and then a much larger number of law enforcement. But, like, the intelligence agencies also spend a lot more money on this. Right. So there’s like, the other, like, interesting detail or like, I think one of the more surprising details I would have assumed that most of these sales are exclusive, right. But if you’re selling a vulnerability to like a top tier intelligence, you know, signal intelligence agency at a five x government, right, they’re going to want exclusivity. But it seems like that’s not the case. In fact, I get the impression from the slide deck that you can literally sell the same vulnerability to multiple organizations in the intelligence community of the same country.

Thomas: The government isn’t wise to that.

Mark: Yeah, a lot of the time that is the case. And while they are wise to it, there’s reasons why they don’t share. It’s pretty complicated and it very much depends on the country itself. But for example, the US has, I think it was 17 ish intelligence agencies or something. And then if you include some of the law enforcement kind of branches which kind of have their own intelligence agency going on, there’s a lot more. And the problem is if you sell something to one person, they might not really want to betray all of their tradecraft to even friendly agencies. In terms of exclusivity, I would say its becoming over time a bigger and bigger deal. So in the past you could basically sell non exclusively to a whole bunch of agencies and they didnt love that you did this.

Mark: But at the same time it wasnt the end of the world because if you go back ten years or so, generally things werent getting found in the wild. Exploit chains and vulnerabilities themselves and exploits were lasting for significant periods of time. Mitigations would come out from time to time, but way less often perhaps than they do now. But as time goes on, the cost of these vulnerabilities is going up because the complexity is going up. And especially if you’re making chains, like I said, you need more components. And also they are tending to last less time because things are getting caught in the wild a lot more than they were in the past. And also mitigations are coming out quite frequently that caused significant problems. So you have this situation where agencies have to pay more money for something that basically yields less result and for less time.

Mark: And so there comes a point in time where they’re like, hey, it’s kind of annoying to us that you’re selling to these other, especially if someone else that you sold it to basically got the capability burned. Yep, because they used it in some manner that was careless and got caught in the wild. So in the market there’s a lot of things get sold non exclusively currently. But over time, increasingly I believe that the end customers, at least in intelligence maybe not so much in the law enforcement space are going to insist a fair bit more on either exclusivity or some kind of semi exclusivity.

Deirdre: Do you have a feeling of why discoverability is going up? Like we’ve kind of talked about reasons why mitigations are improving and that things aren’t lasting as long, but do you have a sense of why the exploit, discoverability is increasing? Is it there’s just a bunch of researchers looking all the time?

Mark: Yeah, I think there’s several reasons for it. One is that the people doing defense, including both vendors and also teams such as Kaspersky or tag, I know they’re a vendor, but they’re kind of adjunct. They’re not like writing the software themselves. I think these teams over time have matured in terms of their trade craft, of how do we filter through all the noise and find the things that are actually useful. And increasingly I also think vendors are like, hey, we actually have all this data from either our expansive ability to see vast tracks of the Internet, or also collecting telemetry data and so on. Maybe we can make some kind of deductions. And so I think it’s a combination of those two things. But things are getting discovered more now because of the increased mitigations and things like that.

Mark: If they impact an exploit’s ability to function in a way that it becomes more noticeable, then perhaps someone who’s a suspected target goes, hey, my phone’s doing something really weird. Can someone look at this? So that probably plays a small part as well.

Thomas: Just Chrome, Firefox, Safari, how are we doing here?

Mark: You know, they all have different strengths and weaknesses. I think both Chrome and Safari have very aggressive sandboxing now, which is significant. And they constantly revamping various in place security mitigations to prevent V8 sandbox, and various other mitigations that both the browsers have added. I would say that both of them are quite difficult, and it sort of depends on what researchers you have at your disposal of what they like to specialize in and how well they know it. But finding a useful vulnerability and also being able to break out of the sandbox of those two in particular are non trivial and require a lot of, I guess, groundwork to have a good working knowledge base, to be even be able to spot vulnerabilities. And then beyond that to getting around all the mitigations, some of which tend to destroy entire classes. I don’t really know if I can rate them. I haven’t really looked at Firefox for a while.

Mark: Thomas. So I can’t really say is that equally true?

Thomas: The difficulty of chrome and safari and getting full chains together and dealing with the sandboxes, is that equally true on desktop and mobile? I would assume that safari is a harder target on iOS because of pointer authentication and all that stuff.

Mark: Yeah. In general the mobile targets are more difficult for several reasons. Like you said, pointer authentication can be a problem. Also sometimes the sandboxing capabilities are a little bit different between the platforms and they tend to be a little bit more stringent on the mobile devices than they are on desktops.

Thomas: I get the impression that targets like iMessage are in kind of the same rough tier as browser vulnerabilities. A drive by iMessage, zero interaction, just point and click and own somebody’s phone up is a very valuable vulnerability right now comparable to full chain through a browser or not the case?

Mark: No, I would say significantly higher value than through a browser because you don’t have to entice them to visit a website, you don’t have to man in the middle or something like that. You send them a text yeah, but then it sort of can depend on the vulnerability itself as well. So perhaps you have a vulnerability in imessage or some similar technology and you’re like oh, I can totally do this zero click drive by thing. However I need to be a trusted contact of this in some, regardless that changes the value of it perhaps significantly. So details like that can affect the value of them, which is kind of what we were touching on earlier I guess.

Thomas: And like iMessage is part of the iOS platform. Like I would think of it as just, you know, it’s part of what Apple ships with the phone right. Other third party applications. I mean WhatsApp is probably an obvious example where yeah that’s also I assume a very valuable vulnerability. But there’s Spotify or something like that. Are there like goofy other applications that are weirdly valuable?

Mark: I can’t think of any offhand that you wouldn’t expect to be valuable. Basically the things that everyone’s using are valuable but it can also depend on, as I was saying, who you’re actually selling into. So some vulnerabilities are very useful to some people but not at all useful to others. So for example say you were targeting people over in the Middle east or something and theyre all using some particular application there maybe that is more valuable to people for whom that is their charter. But if youre a domestic law enforcement or something like that then maybe its of little to no value to you so the value of particular apps and stuff can vary greatly depending on what your actual charter is and who you’re trying to target. As another example, perhaps if your charter is trying to, for example, just discover people behind pedophile rings or something, then perhaps a Tor firefox thing is more valuable to you than other agencies and.

Deirdre: So on, or some dark web, very specific sort of platform that’s seems to be very popular with a certain clientele and only them.

Mark: Yeah, exactly.

Deirdre: So in your deck, you basically have a bunch of predictions of the future of the market. And speaking to a lot of the stuff we’ve already touched on, the sort of impact of a lot of these mitigations and rewriting things and all these protections on memory, re examining the value of these memory corruption bugs and the longevity and usefulness of those sort of exploits. Predicting that it’s going to retarget a lot of solutions for lower compromise, like lower capability but cheaper options. And that includes moving away from memory corruption flaws to web style bugs, logic flaws, and other things like that. So related to that, does the V8 sandbox do anything if we’re probably going to be focusing more on web style bugs.

Mark: Right. So I’m actually really glad you asked about this because I’ve been thinking of how to work in some commentary on this. Firstly, yes, the sandboxes like that are the thing that’s driving the market to do something else, right?

Deirdre: Hell yeah.

Mark: If you have a bunch of mitigations and you’re like, no one’s targeting these anymore, so they’re useless. That’s not really true. No one’s targeting anymore because of that thing.

Deirdre: Yeah.

Mark: Memory corruption has been the centerpiece of most vulnerabilities and chains of vulnerabilities, not all, but like a large percentage of them within the commercial market for since the beginning, I think. And so the reason that they’ve generally in the past been so popular is you can find them from all sorts of vectors. And with some engineering work, you can generally gain the highest level of access possible, which is code execution. But over time, the engineering effort has soared and the access that you get is less. So earlier on, when you would make a chain, you would go, okay, this is like two bugs, a remote thing, and then a kernel bug, and then you have kernel code execution. If you look at iPhone, for example, then you’re like, oh, they’ve got a sandbox now for the browser, so maybe you need another component there. So we need three of them now. And then you’re like, oh, now there’s KTR and then ppl and that.

Mark: So we can’t actually execute code in the kernel anymore. We can get read write, whatever read write access to memory, which is nearly as good but not as good. And then it’s like, oh, actually ppl and svtm. You’re like, oh, actually we can access some of kernel memory but not actually the critical data structures unless we do this other thing. So over time the access you’re getting is less and the engineering effort is going up. And I think moving forward various customers are going to be like, okay, well, this is costing more and more and it’s being less and less effective. At what point do we do, firstly, we don’t need all that access to do what we need to do. And secondly, if you find some other style of vulnerability, can that do something that’s good enough for what we want? And in the scenario where you have a full chain, I imagine that it will be memory corruption, but also other things as well.

Mark: There was a really good presentation several years ago called owning an iPhone with Gen Z bugs, they called it. And like the first whole half of the chain was like cross site scripting and stuff like that inside of, I think it was itunes or something. And then it would start a. Yeah, like it was using basically web style bugs for the first half of it before getting to any memory corruption to leverage significant amount of access.

Thomas: Just to be clear, for hacker news sake, when we’re talking about a saleable XSS vulnerability, we’re talking about a client side vulnerability that gave, you know, the Ic roughly the same capability that they were going to get with RCE or whatever. Right. Like there’s a, there’s a prevailing belief that cross site scripting vulnerabilities in like random web apps are worth hundreds of thousands of dollars.

Mark: Yeah, generally that’s not really the case. Yeah. In, in that particular case, the cross site scripting vulnerability yielded a method to get onto the phone via USB. It wasn’t like a random web app. Yeah. The reason I bring up cross site scripting is and web style vulnerabilities is because one is a lot of applications use web internally. And second of all, around the time when that Gen Z bug came out, there was also a couple of rces in things like Zoom and even exchange had an RCE that was multiple vulnerabilities. But the first one was like an SSRF or something because they had a web.

Mark: Because the way exchange is set up, it’s got like an internal web server that it communicates. Yeah.

Deirdre: This makes me even more worried about electron apps?

Mark: Yeah, I think finding vulnerabilities that affect electron apps would be useful because it’s quite widely deployed in all sorts of scenarios. So I think that would be useful. Again, it depends on the vector and how you can actually utilize it.

Thomas: Is there much of a market at all for server side vulnerabilities? I remember back in the day at Madasano, this would have been like pre 2012, we had a client that was particularly interested in RCE and PHPBB, right?

Mark: Yeah.

Thomas: That was actually valuable to them, which would not have been my pick for what would have been valuable. But is there a real market for all the vulnerabilities that we talk about when we talk about markets are all client sides, it seems like.

Mark: Yes, there is a market for server side vulnerabilities. Theyre considerably less common, I would say. But there is absolutely a market to that, targeting various, I mean, we saw from eternal blue, for example, the vulnerabilities in SMB and stuff like that. Theres absolutely a market for that kind of thing. One of the hairy things that I think were getting into is increasingly over time, a lot of server side software has been replaced by clouds. And then you start getting into like, okay, you can’t really, like, what are you allowed to do here? The answer is probably not much like, you can’t really just hack Google infrastructure or something like that. So there’s probably no real market for that locally. But for your adversary, why wouldn’t they do that? Of course it’s going to get into, I think, a tricky situation there.

Deirdre: Okay. One of your other predictions was kind of in the same stew of factors and forces that will drive to other kind of exploits and vulnerabilities, you predict high demand for authentication, bypasses, crypto weaknesses. And this is very funny because in kind of like very real world sort of security assessments of like where you’re most likely to get pwned, the crypto being broken, or the implementation being exploited of, you know, you’re signing your signing scheme or whatever you’re doing is less likely to be the target or the actual, you know, vector. And you’re basically predicting that because we’ve done so well and all these other places it’s more likely to be now.

Mark: I did specifically want to mention cryptography, since it’s in the name of the podcast in the past where we, you have these chains of vulnerabilities. Cryptography didn’t play a huge part of it. The only cryptography you generally encountered a long time ago was tL’s. And it wasn’t even used very much, to be honest. But now I think cryptography in some form or another is baked into every single layer of the infrastructure. So TL’s, which is ubiquitous, but then down to code signing and then down to the cpu itself, which is using PAC or similar and trusted boot chains and so on. So every layer has some level of cryptography in it. And that cryptography in various situations is the keys to the entire kingdom.

Mark: If you can sign stuff as Apple or something, you bypass like 500 layers of security kind of thing, you know what I mean? And so there’s so much there that can be useful. We’ve seen over the years like attacks of like, hey, you can actually do evil upgrades or things like that. So doing that, bypassing code signing has been a huge thing for iOS. And then if someone found, for example, a weakness in the implementation of say the pack signing on the cpu itself, they could go, hey, this is actually totally predictable or something that’s useful. And so I think the people that have a crossover knowledge of both vulnerability research and cryptography is something to be highly sought after in the next five to ten years.

Deirdre: Oh boy.

Mark: Yeah, paying off big time. Tom, you can apply for a job.

Thomas: The last exploit I wrote I was impressed with myself for getting the shellcode to the all lowercase. That’s how rusty my rusty I am. So just a couple of more questions and then we will let you off the hook here. And these are higher level questions, right. So I guess one thing I’m curious about is do you have like a hot take about your work in your field that you think that other people in your field, like other people that are doing commercial development of exploits and selling them, would like sharply disagree with.

Mark: You about hot take. Not that I can think of off the top of my head. Generally what’s happening in the market is people converge on very similar solutions to things, particularly as things get more difficult. And so in the past perhaps we had all different products and they didn’t really overlap that much and so on, but increasingly everyone’s kind of doing the same thing. One of the things that I wanted to do with this new company was when I was taking a year off, I was giving keynotes like this blue hat one and several other ones where I was saying like the things we were just talking about, like, oh, we actually have to have a significant expertise in cryptography. We need a significant expertise in web people and things like that that we weren’t really focusing on before. And so one of the things I wanted to do with this company. And another area, by the way, is also hardware.

Mark: We having very low level and hardware style vulnerabilities, not unlike the it started with Rohama, but then Spectre and all those kind of things. How practical are some of these kind of attacks and what should we be looking for here? So one of the things I was kind of interested in doing with this new company is speculating in some of those areas and going, okay, let’s try and think about what’s going to happen in the next five or ten years and try and build up some knowledge there. And a lot of it’s speculation for me, like, I don’t know, as if these directions are going to work out, but I think it’s a mistake to just keep doing things the way they’re operating now and hope that nothing happens kind of thing.

Thomas: My last question is just so you’ve been doing this for a long time. I’ve been doing what I do for a long time, and people look at me funny because I still occasionally write code, although I write more blog posts than code at this point. Right. Is your day to day still all technical, all doing development work?

Mark: So I do a lot of management stuff for sure. I like doing the direction of the company and stuff like that. And there’s a lot of other random administrative things that I do. So while I do technical work, sometimes it’s often interrupted. However, I like doing the technical work. And also I think there’s a specific benefit of me doing it, which is we understand this work is very difficult and can be very demoralizing. And it’s asking a lot of people that you hire to be like, hey, can you just find a mainline Linux kernel bug for us or something? So I like when I’m able to find vulnerabilities or craft exploits or something because I feel like that’s a good contribution. But it’s also sort of saying like, I’m not asking you to do something that I won’t try and help with, you know, that I won’t do as well.

Mark: So I think it’s good kind of team morale to, if you have management trying to contribute in some way other than just going to meetings and so on.

Deirdre: Yep.

Thomas: Awesome. That’s a, that’s probably a good place for us to wrap this up. Mark, can’t thank you enough for taking the time to talk to us right now. Your work has always been super fascinating, but like, it’s fascinating in multiple dimensions here. And it’s really generous of you to kind of, I know, like, you don’t want these presentations getting out necessarily, but I really appreciate you helping me win arguments on hacker News. So.

Mark: Yeah, no problem. If you’ve got any other fights on hacker News, drop me a message and I’ll come in and sort it out. Not that I think anyone there will talk to me.

Deirdre: All right, thanks for having me. Security cryptography, whatever, is a side project from Deirdre Connolly, Thomas Tatzak, and dear David Adrian. Our editor is Nettie Smith. You can find the podcast online at SCW Pod and the hosts online at Durhamcrustallum, QPF, and avidcadrian. You can buy merch online@merchecuritycreatographywhatever.com dot. If you like the pod, give us a five star review on Apple podcasts or wherever you rate your favorite podcast. Thank you for listening.

David: What’s this? It’s more security cryptography, whatever. After dark. And because I wasn’t on earlier, now Thomas and I are going to continue talking about, you know, just the market for, for exploits. And once again, we do really want to greatly thank Mark for. For coming on. But now it is nighttime and it’s time to talk about it.

Thomas: Wait.

David: With Thomas.

Thomas: Well done, David.

David: Yeah, I guess we learned that there is no market for logout zservs. Thomas, how does that make you feel?

Thomas: All right, so, yeah, I mean, I don’t know. I’m glad to be talking to you about this just now. Right. So I guess, like, I have, like, I have a couple of takes based on that conversation, which is like his whole spiel, everything he’s doing is kind of mind blowing for me. It’s really super. Like, just the raw facts are pretty interesting to me. I’ve had, like, this, like, there’s some bullshit that I have been on about exploit sales for a long time, and like, I was about to not ironically use the term, the term confirming my priors, but I feel my priors somewhat strengthened. Right.

David: Do you feel that you confirm your priors frequently?

Thomas: I feel the urge to use those words somewhat regularly, and I try to stop myself. So I’m going to list off some priors and you can tell me how sane they sound in light of that conversation. Right, so, prior the first. I have a general belief that when it comes to marketing vulnerabilities or exploits, that there are no saleable loans or exploits that don’t fit into a pre existing business model. And what I mean by that is you heard Mark talking about how, sorry.

David: Thomas, is this about exploit markets, or does this become a seminar about B two B SaaS sales. Right? Like we’ve got our solutions paid and that’s how you sell things.

Thomas: You can understand me sticking close to my personal current area of expertise. So yes, it is both. It is both. So you heard Mark talking about like vulnerability. Buyers are looking for particular outcomes and I feel like it’s worth calling out that pretty much regardless of who the buyer is. It could be like the intelligence community trying to get like RCE on a phone to go after a particular intelligence target. Or it could be, you know, organized crime or whatever it is. They’re all buying outcomes.

Thomas: They know what the outcomes are. They know what the outcomes they want are before they buy. I tend to believe that the serious buyers are universally people who have already achieved that outcome before, that they have a repeatable process, um, that they repeatedly get that outcome. They repeatedly pop shells on people’s phones or whatever and they’re looking for things that slot directly into it. Um, this like runs against a pretty popular message board argument about exploit sales, which is like, you take any given new exploit, um, no matter how interesting the outcome is, and people will say, well, like, I can imagine ten different people who might be interested in having that outcome, right. I don’t believe that ever really happens. I’m prepared to be completely wrong about this. Right.

Thomas: But I don’t believe that that happens.

David: So you’re saying there’s not like outbound sales, webinar type things that are convincing people that they want some sort of specific component. Rather it’s that the people that know that they need to achieve the thing are going and looking at how to do that basically. Yeah.

Thomas: I think it’s an easy sale to say that like, you know, GCHQ never goes to Bob’s house of weird exploit outcomes and just browses around looking for interesting shit. Right? Like they know going in what they want. But I also think it’s true of organized crime as well. Like there’s a sort of, maybe just.

David: To be clear, organized crime and like what azimuth and visual insecurity do are very different things. They’re not associating mark, with this at all.

Thomas: Yeah, you called that out. That’s a very good point. Right. But in the context of a message board argument about exploits, which is where I live and breathe. Right, like organized crime actually features much more potently than the intelligence community does, which is where like the entirety of where Mark plays. How does that sound to you though, that my pitch about like there are, the buyers are calling all the shots about what they’ll buy. And if you don’t have something a buyer already wants, your thing is worth zero.

David: I mean, I made the joke about webinars. I’m sure there is some level of sales and showmanship just like there is in any market. But, yeah, it’s not that you’re selling access to someone’s phone, and the people that want that are people that know what to do with access to someone’s phone. As part of. If you’re an intelligence community, member of the intelligence community, you have existing investigative workflows that are like, oh, if I had access to this person’s phone, I knew what I would do. This is how it would further my investigation. This is how it would fit into the corporate hierarchy, pivoting to the non government, offensive security world. If you are doing organized crime, presumably you already have business processes for laundering money and moving money around.

David: A. Right. If I were myself to do a hardcore pivotal from product management into computer crime, much of the struggle would be on the boring business side. Once you’ve done something, you’ve acquired a bunch of bitcoin. Great. How do you turn that into money you can use in the real world without getting arrested, which, notably, is where people get arrested. These are all things that you need to have experience with, whether on the crime side. You need to have been repeatedly doing crime for a while to even have this stuff be useful if it’s on the intelligence community side.

Thomas: Right.

David: You need to be able to do intelligence, and then at some point during that intelligence work, you have some outcome that you’re working towards, and you’re like, oh, the computer guys can help me with this.

Thomas: Yeah, and, like, I buy that. Like, if the outcome of your vulnerability is that it directly siphons cash from a blockchain or something, like, sure, I don’t need any more, you know, reasoning than that. That fits into every organized crime workflow ever. But anything.

David: Yeah, but you, like, don’t become, I think, that you don’t join organized crime. Or are you unlikely that your first foray into the criminal world is to steal $3 million of bitcoin from someone you’ve never met and then cash it out because that’s a great way to get arrested two years later?

Thomas: I don’t know. I have no idea how often that happens generally. So I think that has implications for bug bounties and, like, the constant comparisons that are made anytime, like, a bug bounty number is cited, um, the very next line is going to be whoever’s market cap, right? And, like, um, the, you know, the, the, like, Apple will pay $75,000 for some vulnerability and the immediate found will be, well, this vulnerability was going to be worth, you know, $2 million, you know, and then in the exploit markets or whatever. And it’s like, um, probably not right that there’s a whole thing that Mark has about when these vulnerabilities are worth money. And Apple’s bounty program wants a full exploit chain and they want, but don’t require reliability. But you can sell a lot of things to apple into Apple’s bounty program that you presumably cannot sell to resellers for the intelligence community.

David: Yeah, and you don’t even need a full chain, right. At just about every bug bounty youll get more if you provide a full chain. And you may even have time to amp up your payout if you give part of a chain and then you come back soon enough later and are like, hey, heres the rest of the chain. But fundamentally, the price thats being paid for something like that by a bug bounty program and the price that you would get selling into the vulnerability markets are just two completely different products. Theyre not directly competing on price. And it doesnt make sense to, to not only, you dont want to match the theoretical, oh, well, this affected every iPhone. You could do 10 trillion of GDP damage payout. But also youre not even trying to match the price that you might get in a private vulnerability market.

David: Youre just selling for products. You get to talk about things you submitted to a bug bounty publicly. You get to understand how its used in the sense that it goes into a bug tracker and its patched. You get some level of visibility into what happens after you report the vulnerability that you might not get in a private market. You can go give black hat presentations about it. You don’t have to sign NDAs or get a security clearance to be able to continue to talk about it or like burn your future payout by talking about it. Right.

Thomas: So, like, like a thing I’m trying to get my head around is like Mark. And Mark’s presentation in particular would say that, like, almost by definition, the exploit market is a couple of years ahead of the vendors. There’s a thing about how, like, how valuable these vulnerabilities are to their state level buyers that I’m really kind of stuck on. So, like, my thing with this is trying to figure out what the possible price ceiling of a workable exploit is. But you know, another, another like, line of bullshit that I’ve been on forever is just, if you look at the prices for full chain vulnerabilities with tooling and maintenance and all that. It’s like, okay, so you’re talking about like, you know, mid single digit millions of dollars or whatever. And I could be wrong, but I think Belize can afford that.

David: Yeah. Like at the end of the day. Well, one, these prices aren’t very high relative to total government budget, although obviously the budget of any agency or sub department of an agency is going to be much smaller.

Thomas: But like, so, so like if you, if you think about what state level buyers, law enforcement buyers, whatever are getting out of exploits, it’s replacing what would otherwise be human intelligence or like human driven signals intelligence, like people literally clipping wires to telephone wires or whatever, whatever it is. Right. And when I think about those costs, it seems to me like they’re likely dominated by personnel costs. You’re competing against the health benefits budget for large organizations, which is going to be like nosebleed high amounts of money. Right. So like I can’t really get my head around the possible ceiling for. Mark obviously believes that full chain exploits. The sky is kind of the limit on what those prices are going to be.

Thomas: Right. But yeah, that seems true. And that being the case is how are vendors supposed to compete with state level adversaries and the states are always going to outbid.

David: Yeah, I don’t think that quite the sky is the limit, but you’re comparing it to the full cost of sending people across the world to go do a physical thing and then paying for that if something goes wrong on that, paying for health costs or care costs or pension costs, whatever, for the people involved in that for years to come afterwards, massively more expensive to send someone halfway across the world to go and use their magnifying glass and do investigative work than it is to own their phone at a distance.

Thomas: So there’s an interesting dynamic here. Right. Okay. You figure in the near term, there’s nothing that like a big tech vendor is going to do to drive the price of an exploit so high that, you know, a major world industrialized government will not shell out to have it. Right. So they’re, they’re, they’re not going away. They’re getting more expensive. But like, the people that feel those costs don’t feel those costs.

Thomas: Right. That’s below the noise floor for what any individual buyer, like human buyer is going to feel like working with government budgets. Right.

David: On the long term, yes. I don’t think you can just jack up for a variety of supply and demand and just budget reasons. I don’t think you could just add a zero to the price and have it work out.

Thomas: Right. I mean, it’s gonna be a gradual trend or whatever, right. But my thing here is there is a group of humans that will very profoundly feel that budget shift, right. And that’s the people who are selling vulnerabilities. Right. So, like, there’s a way of looking at this, and I am not saying I subscribe to this view of the world, but there’s a way of looking at this where countermeasures, hardening, isolation, bug finding and all that, it drives the cost of vulnerabilities up. It knocks out crappy players in the exploit sales field. But if you were a top tier player in that field, it’s mostly great for you, isn’t it?

David: Yeah, we see the bottom end of the vulnerability market drop out. Like year to year, right? You see firms shut down, or you see enough exploits get burned, or like back in 2014, 2015, somewhere around there, there was that italian hacking team company, or was it Finfisher? Or both of them, I’m not sure, got hacked by someone else and then basically went out of business. And presumably what we’re seeing there is the low end of the market. And then if you just look at blog posts coming out of the threat hunting teams from the various big companies, you’ll sometimes see reports about state sponsored activity in active war zones or from North Korea. But you tend not to see a lot of posts from the threat hunting teams that are like, oh, and we found that this OD was in use by one of the five Eyes intelligence agencies. Right? Like presumably the top end buyers are doing a much better job at not getting detected as well. They’re still able to do what they need and it’s probably because they’re buying from the top end of the market. And it doesn’t seem like the top end of the market is going to go away anytime soon.

David: And so any compression on the supply side, that is firms going out of business as long as the top end can still continue to find exploits, even if its twice as hard as it used to be, as long as they have enough to satisfy demand from the top end of the market, those prices are just going to keep going up as the lower end players fall out because supply is restricting overall in the market, but their supply is still good enough and the demand side is fairly inelastic.

Thomas: So there is a rational goal for a big tech vendor to drive the cost of vulnerabilities up because it’s getting rid of a big swath of crappy or criminal exploiters or vulnerabilities. It’s like getting rid of the riff raff. But I wonder, if you fix your adversary as China or a five eyes intelligence agency. What is your theory of change? What is your long term goal with working to drive the cost of exploits up? Why are you outbidding? If you’re a big tech vendor? Apart from getting rid of the lower class of, maybe just say, apart from getting rid of the criminal exploitation people, what is the outcome you’re hoping to get by outbidding state level buyers for vulnerabilities?

David: Well, the bug bounties are already not outbidding state, uh, states vulnerabilities, and it’s, like, not clear that doing. So, I guess your question is, like, what would change if they did outbid them? And the answer is, like, unless they had, you know, absolute full visibility into the entire market, which you wouldn’t like, you just spend a lot of money, right? Someone would still find something to use somewhere, and now we’ve just, like, jacked up the price for only a marginal security benefit, if any.

Thomas: I mean, they do outbid for a large class of vulnerabilities, right? For the large class of vulnerabilities that top tier buyers don’t buy.

David: Yeah, stage fright, for example. Actually, I don’t know if that one got paid out with a bug bounty. I don’t know the reporting story on that, but, you know, but things like that. Yeah, things like that. Or even things like less impressive than stage fright from a bug bounty standpoint, many bug bounties will pay out anything that looks like it could be exploitable, even if you don’t actually demonstrate a full exploit, or if you would get blocked by a mitigation later, if you’re like, oh, I found a type confusion in this code engine, and you can show how code could cause that to happen, but not necessarily how would you get it at someone? What would you do after that? Is it still sandbox? You’ll still pay for it. Or if you can show just part of the code where you’re obviously reading attacker controlled data, even if in usual operation of the program, it’s really hard for an attacker to control that data, bounties will still pay that out. Those things just wouldn’t be useful to the offensive market or something that requires 100 unique UI interactions done in a specific order. Bug bounties will pay out for that sometimes, but there’s no way in hell that something that requires the user to do a literal dance with their mouse or something that a vulnerability market buyer would want to buy.

Thomas: Yeah, I mean, that makes sense. This ties into a thing I’ve been thinking for a while about cryptography vulnerabilities and about the standard cryptography adversary as NSA. And obviously NSA has enormous budget and there are classes of constructions that get used or mitigations that get used or whatever that foreclose on attacks completely. And then there are things that just make it much harder for attacks to happen. One of my beliefs is that it may be the case that NSA’s primary mission is not defending against terrorism or monitoring China or whatever it is that NSA thinks it does, but rather just accumulating budget for NSA.

David: You know what they say, the purpose of the system is what it does.

Thomas: Well, yeah, I don’t think this is a weird thing to believe, right. Is that like institutions, their primary objective is just to perpetuate the institution, right. So it’s like, it’s a thing where like you can make NSA’s life harder, but you’re not hurting it by making its life harder. You’re giving it reasons to acquire more budget, which is like the prime directive, potentially maybe the prime directive of NSA.

David: Yeah, I mean that being said, I think we are all better off with that price being driven up and with that supply being reduced. Improving the security of software in general is probably still a net good, right?

Thomas: Yeah. I mean, yes. I’m not, as we’re not going to knock the entire industry down, I am making positive descriptive arguments on that, normative arguments. I am not a nihilist, but it’s just interesting, right? Like, I don’t know, it’s just an interesting thing to noodle on at this point. After hearing all that, where do you come down on prices for cross site scripting vulnerabilities and random websites?

David: I mean, I’ve been of the opinion for a long time, including when I was at census where we didn’t have a bounty. And I was like, no, we’re not going to have a bounty. And if we did have a bounty, were definitely not gonna like outsource it to a third party. Except for maybe the payment processing aspect because it turns out paying people across the world can sometimes be difficult to do through stripe invoices or something. But unless you are a platform for some definition of the word platform. Well, let Ben Thompson and strick Heckery decide who’s a platform. Unless you are a platform, unless you’re running someone else’s code or doing something along those lines, you probably dont want a bug bounty. Its just a waste of time.

David: This isnt to say that security isnt important, but youre just going to get a bunch of bad submissions about stuff that isnt very important and youre better off just having a security team. One of the benefits of bug bounties, aside from being a quasi competitor to the vulnerability markets for things that actually have interested buyers in them, is just kind of a guiding factor for where the security team should spend effort. If the security team is super focused on some area and then something else starts showing up in the bug bounty, it’s a way to stop groupthink. I believe Justin Hsu said this in our second episode or something, that it’s a prioritization and a metric system for are we doing well, put in some mitigation or did some architectural change to make some class of bug be impossible or very close to impossible? Do we see those submissions going down in the bug bounty then? Like, yes, that’s a way to measure your success. If you’re not doing that, just don’t run a bug bounty because no one cares about xss in your sites. Not that you shouldn’t fix them, not that they’re not a problem, but there’s not a buyer for them and you shouldn’t artificially create a market for it by creating a bug bounty. That’s my hot take.

Thomas: Seems like a reasonable take. Well, anything else you have on your mind after the marked out interview?

David: Man, it’s great to be at the top of any market is really what I’m saying.

Mark: Right.

David: I think it’s what we’re getting right here.

Thomas: Right?

David: Is that any market where like if you’re at the top of it and supply is shrinking and demand is increasing, man, that’s the place to be in. What tell you that is probably bodes well for your future business prospects.

Thomas: I feel like going back to 2005, maybe I would have still been saying it’s good to be marked out. So I agree with that takeaway.

David: I think that’s where we end it. It’s good to be Mark Dowd. All right, well, this has been security, cryptography, whatever. After dark. I’m David Adrian here with Thomas Tatchik. We’ve got a little podcast business on the way out. We are putting together a lot event in Las Vegas during Black hat. There will be mingling, there will be a live podcast.

David: There will be a live Q and A. Stay tuned for venue details. We’ll be posting those on our social media channels. And once again, thank you to Mark Dowd and to everybody listening. Have a great summer.

Thomas: Sounds good. Thanks again, Mark.

Zero Day Markets with Mark Dowd

Latest Posts

A Little Bit of Rust Goes a Long Way with Android's Jeff Vander Stoep

Campaign Security with [REDACTED]