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.

Transcript: https://securitycryptographywhatever.com/2024/06/24/mdowd/

Links:

"Security Cryptography Whatever" is hosted by Deirdre Connolly (@durumcrustulum), Thomas Ptacek (@tqbf), and David Adrian (@davidcadrian)

0:12

Welcome everybody to, uh, security, cryptography, and also whatever. Uh, I am Thomas and with me as always is, Deirdre, I'm Deirdre I'm, uh, I'm, I'm really psyched with us today, uh, Mark Dowd. Mark, thank you for being on. No problem, thanks for having me. So Mark and I, um, 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. Um, so, you know, and then. We've 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 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. Uh, so Mark is, uh, if you're not familiar with his work, Mark is one of the coauthors 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? No, I know that, um, hard copies are hard to come by because they are out of print, so I've seen them available for like 200. I have a small stack of them . They're running for upwards of 400 right now, 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, 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, uh, involves markets for software security exploitation. So I guess here's the part where I let you kind of finally start talking, but like, if you can give me kind of just a high level, like, um, 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, you know, you know, software security assessment stuff. 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, um, not the space station. It's, um, uh, internet security systems, which is now part of IBM. They got acquired at some point, but I was doing vulnerability research there, uh, in much the same fashion that Project Zero is now, where we find vulnerabilities, report them to the vendor, and then, um, put them out in public and then give talks at BlackHat and other conferences and so on. At some point, I left there and, um, I started, uh, Azimuth Security. This was actually not long after we published the Art of Software Security Assessment. So we started, I started Azimuth Security with, uh, one of my co authors, John McDonald. And we started, uh, Uh, going into the, the market that you're talking about of doing vulnerabilities with intelligence agencies and so on, like basically vulnerability research for the government markets. We actually didn't intend to do that initially. We started off doing regular application reviews and so on, but, um, we, we always had. much more interest in doing vulnerability research. And when we found a constructive way to do that, we're like, uh, this is so much more interesting and also hopefully it's doing some, some good. And quite frankly, it involves way less, uh, conference calls and paperwork. Um, so yeah, we did Asmodeus security ran that for about 10 years, which was then bought by a defense contractor in the UK called L3 who was merged with Harris, so they're called L3Harris now. Harris being a big U. S. defense contractor. So I stayed working at L3Harris 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, um, keynotes and presentations and stuff like that, and then started this new company, Vigilant Labs, which is also in a similar space. Thanks. as what, uh, was in. 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, uh, Microsoft annually puts on one or two, like, internal security conferences, and they're called Blue Hat, it's an 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, um, and the slides for that just now came out. So, like, I think that there's obviously, like, a lot of mystique, um, 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. Um, so like, a lot, a lot of people are familiar with the Zerodium 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, Zerodium will pay up to 2. 5 million dollars, which is a crazy number, right? Um, and the next line in the slide is the words up to are doing a lot of work, uh, in that price list. Can you expand on that? Yeah, before I do, so, yeah, Blue Hat was, um, last year in April. And this was actually, I, I gave a similar presentation the year before at Qualcomm, uh, Security Summit as well. Um, 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, uh, uh, whatever, here I am. Um, so going back to the slide you're talking about, um, basically what I was trying to say in that part of the presentation was that, um, 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. Um, each of them have Uh, unique properties that make them more or less, uh, attractive to, uh, a customer. And it depends on what that customer's mission is and also, uh, a lot of details, uh, around the vulnerability, uh, and the exploit itself. So, in the case of like, um, where they're talking about a full, basically a full chain for Android. On the surface of it, that sounds great, right? Like, uh, a full chain remote code execution Android vulnerability or set of vulnerabilities is, uh, very powerful, but then, if you're the buyer, you have to start thinking like, okay, wait a minute, which, which Androids? Samsung? Huawei, Xiaomi, like which of these are actually affected and then can you identify a target before you throw it? Um, 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, uh, for a number of customers. So, giving a, um, a figure in the, in the way that Zerodian does, they're covering all of these cases and basically when they say up to two and a half million or whatever, they're talking about the specific, best case scenario, and nearly nothing they come across will actually live up to that. So I guess my first question there is, , there's an example in your slides, um, of like the difference between a baseband vulnerability. And, um, like a vulnerability in, 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, um, not a deal breaker, right? Because if 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, uh, you know, what's valuing, say, a full chain persistence Android vulnerability, right? Um, some of that is a property of the vulnerability that you found, right? Where it is, how easy it 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 and you have to build out the exploit. To what extent does the price vary just in terms of how well the exploit is designed? It very much depends on the vector, like you were suggesting. If, 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. Oh yeah. 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, the properties of the exploit itself can make it, um, either desirable or, 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, um, 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. The start from like a baseline of, let's, let's say the baseline is, uh, this is probably not a reasonable baseline is going to reveal how little I know about your, about your work. Right? But let's, let's say the baseline is just somehow the vulnerability is reliable, remote code execution. Um, 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. This 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 find? ultimate goal that most people have, and again, this very much depends on who the, uh, 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, you know, messaging apps or iMessage and things like that, uh, satisfy all those requirements. If you can bypass the various security mitigations and achieve that. But, uh, doing that is generally a lot more complicated than say, Browser vulnerabilities, uh, since with a browser, you generally have a JavaScript engine to manipulate. So, uh, it's a lot more friendly to exploitation in general. So a lot of the time, when you're doing like fully, , remote zero click vulnerabilities, you very often don't have, Quite as friendly as a situation as you do it in the browser, perhaps. And also doing things blindly then makes it an additional layer of complexity. Uh, if you don't have some kind of, you need some kind of info leak or some kind of a weird machine to manipulate or something like that. So that's the ultimate goal, for a specific class of customers, I would say. So, like, how big of a deal is the silence part of that, that whole thing, right? So, like, just because I'm in the field that I'm in, anytime anything on my computer crashes, my heart skips a beat. Like, I actually go look at the stack trace, even though there's no possible way I'm gonna learn anything from it. So, like, I can imagine, like, you're looking for, you know, not visibly crashing components and things like that, right? Because that's how you're gonna get burned or whatever. Is that, like, a huge component of the price of it? Or, like, I have a hard time kind of getting my head around if you have, like, heterogeneous targets, if you have, like, every possible Android phone, um, and you can't precision target it, like, you don't have a channel to figure out, like, okay, this is the right kind of device for this kind of exploit, like, I can't imagine how hard that must be to build, you know, 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. Is that, is that really hard to do? Is that as scarce or as difficult as it sounds? I'm sorry. Yeah, so one of the things I touched on in that presentation was a lot of things that you see come out, , in public research, you know, sometimes, uh, 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 etc, etc, etc. Making things, taking things from there to working somewhat ubiquitously, uh, even on a subset of targets is often, , the bulk of the work. Taking something that It works a fair bit of the time, like 70 percent 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. 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? Uh, it's a little of both, but there's, uh, I would say, a great deal to do with, , the engineering. For particular vulnerabilities, usually, um, for memory corruption ones, you'll have some kind of primitive, and the primitive might be, uh, nice or, or not very nice. So, nice one might be that you get to, corrupt at a, at a chosen location within, 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, uh, To some extent, it depends on the vulnerability as to what you're able to do. Um, but then, some of the best exploit writers will then, um, show quite a creative flair for turning something that's seemingly not very great into, uh, very reliable and robust exploit. And those, uh, can drive up the value considerably, I would say. You give an example of Stagefright, right? Which is like very well publicized Android vulnerability. And like the, uh, like the headline for that vulnerability was that it impacted like the overwhelming majority of all Android phones. And your take is that like, you know, um, if I'm on a hacker news talking about Stagefright, um, I'm going to say like, well, Zerodium says it's up to 2. 5 million and Stagefright. Perfect example of a 2. 5 million dollar vulnerability. And your take would be that it is not. Um, what are the things that make Stagefright? Reliability, primarily, or are there other things to it? 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, um, there was a multitude of, uh, 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, uh, the biggest vulnerability. This is worth zillions, et cetera, et cetera. Whether that's true or not, though, is a large part of the, um, the value proposition was left out of the public commentary, , which is, how actually useful is this? We had a number of the, you know, top public researchers in the world, Talking about Stagefright 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, um, 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. And so, you're like, okay, but, I mean, we have browser exploits anyway. So I was suggesting by state fright, um, that although the vulnerabilities were indeed ubiquitous, uh, at least at the time with the public research available, , the ability to turn that into a reliable remote code execution that, uh, 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 top of that. So for Stagefright, was, 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 gotten gotten the way of people trying to write a reliable exploit for it? 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 not apparent. Solutions to crafting a exploit, not solutions to fixing the bug. Yeah, yeah, that's right. Um, I, I can't say that for sure, obviously, but, uh, that is my suspicion because,, there's been a great deal of research, , these days into doing more, , these style of attacks, but, um, at least, At the time of the, the research that was available, it, it wasn't, the people commenting on how valuable and, and so on that it was, we're not, uh, taking into account that, uh, the data at the time suggested that it wasn't nearly as useful as they were making out. 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, was all in the news. Uh, it seems like the, 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 Blastore and things in iOS. Can you speak a little bit to whether those things have significantly changed the, you know, vuln market and the zero day market over the last, like, 10 years or whatever? Yeah, sure. So, um, I actually vaguely talked about this in the, in that 2023 presentation, but mainly I alluded to. Another keynote that I've done in, um, Hack in the Box, I think it was, uh, talking about this. So, essentially, over the last, um, 10 years and particularly, there's been a lot of work in terms of mitigations and hardening, uh, both, Mitigations in terms of, um, preventing exploits from functioning correctly, but also like hypervisor type, um, mitigations that, and sandboxes that prevent you, , if you successfully exploit to, that you can't really do anything useful. Um, So those have had a large impact on the exploit market 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 SPTM bypasses and stuff like that for iOS. And so in order to make a fully functional chain, you constantly need to, you know, update five parts instead of like three or something like that., and finding vulnerabilities in those, 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. Back when Stagefright was happening, they did do a media sandbox, incidentally, which was a non trivial Uh it's not too dissimilar to Blastdoor. 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 of a successful full compromise of a chain, um, would over time, uh, 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, like, this is going to be like 10 million plus kind of thing. I also, I think suggested it 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? huh. we just like pull a file off of it or something like that. And that's enough. Cause it's our, our intelligence thing is just needs that or something like that. Is that what you're saying? That's right. Um, keep in mind that the consumers of this technology are interested in an effect, not in a product per se. The product, um, the, the exploit chain or whatever it is, is just a means to get. Data that they need and so if they're like well, we don't 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 be trying to do more with less I would suggest You said it just now. And I've heard you say it a couple, I've seen you, I've read you saying it in a couple of other places, right? But like this idea that now that we're like in an era of sandboxing and isolation, you need full chains. You'd multiple vulnerabilities. And 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, if, if you're, if your sandbox, you know, escape isn't, isn't working right now, right? Like, aren't you just like, at that point, you know, doing research and waiting to develop the next sandbox thing that relinks that chain together? Or is it really the case that like the vulnerability itself, like all of the work that you put into it, it's all going to be counterfeit just because, you know, your, your vector for, you know, 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 in, you know, independently. Is that not the case? It very much depends on the particular vendor, like from a vendor point of view, uh, it very much depends on what exactly, how the vendor's business model works. So, uh, 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. Um, 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. But vulnerabilities, uh, exploits are very fragile by nature, , and often have constraints. 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, etc. Uh, but if one of those components goes down, uh, 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 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 kind of tools, like testing and CI and, like, making, like, just a lot of maintenance stuff. How do vendors, like, maintain their nicely engineered exploit software? In concert with, say, a customer or a deployment or something like that. Yeah, so, again, it's sort of, firstly, it depends a bit on business model, so, again, some people just, uh, fire and forget, they're like, here's a thing, we'll sell it to you, and then it's your, your problem, uh, 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 your You haven't sold it yet or whatever. It has to work at the time that you want to sell it. So the 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 counter example of why agencies tend not to hoard vulnerabilities, because, Interesting. I'd seen a lot of discussion in the past publicly about like, Oh, yeah. You know, NSA or whatever, uh, they've just got like 50 Chrome vulnerabilities, I'm like, no, they don't. Um, can, can, can you imagine, like, it's quite a lot of work to maintain an exploit, uh, keep it 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, uh, components of the exploit and things like that. Sometimes you'll basically have to rewrite them. And so. If you had like 10 or 20 exploits, uh, uh, 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, um, 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, um, you know, some mitigation or some re engineering of the target software comes out that destroys that. Hmm. Hmm. all 20 of my vulnerabilities just went down, kind of thing. Yeah. 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. That like you're getting paid in segments and if the vulnerability is burned,, you stop 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 payment. You're going to get it no matter what. But if you sell a vulnerability to people who are actually going to 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. 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, 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. 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, you know, building an entire new component of the exploit, do you get to resell the vulnerability at that point? Or is that, is that maintenance? Generally it's maintenance. It depends exactly what you're talking about, but for example, um, 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. Like, and one of the quotes I have in the, in the presentation was. from Thomas Havaflake, where he said, um, 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, like, and that's it. So, um, If a V8 sandbox, for example, comes and gets put in and you're like, well, it doesn't do that, but like it does the first part, then it's not that useful to the buyer. Now, when you sell stuff, you negotiate the terms, uh, to a reseller. So, What you're exactly responsible for is not generic, and you're talking about, uh, also getting paid in tranches over time. That may or may not be true, depending on the terms that you've agreed to, uh, with the reseller or with the, um, end customer. And that also might be the case to some extent for some mitigation that, uh, gets thrown into the software. But generally, yeah, it sort of depends on the nature and the, um, extent of the mitigation, I would say. So if you have like an iOS kernel vulnerability, uh, and then a new device comes out that goes, Hey, uh, actually we've got PPL now or SPTM or something. You wouldn't be expected to, to bypass that as a, 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, uh, you know, we've made the, a heap hardening thing. then that generally would be something that you'd have to do. 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, the, the, 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 up front or? 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 Chrome bug, do you want it or not? And once you buy it, it's yours. Like, um, so recurring revenue is a possibility. Um, but subscription models tend to, I would say, be more about the effect than the particular bug. So they might be like, we will give you, or try and give you continual. RCE in Chrome, uh, 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, but it very much depends on who you're dealing with and what you agree to with them. So you were, at 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 gonna 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, uh, like the BRICS countries? Or Japan? Or like, is this basically how everything is driven? Or like, are there, like, does China do all of this stuff in house? Yeah, absolutely. So, um, 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, they buy stuff externally from, uh, perhaps companies that are housed there, but also ones that are located within, you know, the Western world or, or wherever, like any, anyone that's willing to sell to them will, um, enhance their capability and also, uh, give them insights into, uh, what their adversaries or even, uh, frenemies are utilizing. And so a lot of these companies around the world selling to, um, all sorts of different governments, and we only really have,, insight into some of them. 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 gonna 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 capability from somebody? In some regards, 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, as a vector for gathering information, it's sort of critical, right? Um, 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, uh, perhaps gather information about, , terrorism or, or, or perhaps counterintelligence. So what their adversaries are doing, how exposed their own critical infrastructure is. But, you know, there's also, , other situations. Where these kind of vulnerabilities are useful. So, you know, uh, at the law enforcement level, you probably know about Celebrite and Graceshift, who, you know, sell devices that basically break into, uh, 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 theatres and stuff like that, so Every country, pretty much every country, industrialized country, that has the money to, to spend on, on this kind of stuff, is doing it I mean, even at 10 million dollars for, you know, a full chain exploit for Android, that's still, like, just compared to the health insurance costs of the humans that you would have to roll up in trucks to do, like, collect things from people's garbage, it's gotta be, you know, it's gotta be a pittance, right? You, even at 10 million dollars, I would assume they're still gonna sell. I should let you respond to that, but I'm not going to, um, you, you have a, you have a thing in the slide about how kind of definitionally the, uh, you know, commercial exploit developers are a couple of years ahead of the vendors, um, 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, you know, signal intelligence agencies, is the market ahead of those people too? Or are you guys like neck and neck? Grr. Well, first of all, uh, so saying the, um, 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. Um, 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, uh, signal intelligence, um, And the commercial areas, I only have a limited insight into what's internally developed within governments. 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. I think we already touched on this, but just to like double down, there are still like countries that don't have their own like majorly staffed up intelligence, signals intelligence offensive capabilities who basically are able to go to the latest Zerodium or, you know, whatever, go to the latest vendor and just say, here's, you know, eight figures, like basically outsource me, uh, an offensive team. So that's still happening, even though there has been a lot of collapses or whatever. So it's not, we're not just worried about the intelligence agencies of the Five Eyes or the BRICS or, you know, whatever. We're, we're worried about smaller countries that have plenty of money to just You know, outsource. Yeah, so, um, 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 N days or whatever, or things that are less desirable. In terms of their engineering or whatever, um, or additionally, they might, um, uh, seek partnerships with Mm hmm. who is in either the same sort of bind or they, or someone who can, is well resourced and is prepared to, yeah, share with them or do things for them or whatever, um, in some kind of, um, information trade or, or something like that. Yeah, my mind in your, in your slide deck. Do you have a slide about like, 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, uh, a top tier intelligence, you know, signal intelligence agency at a five eye 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. The government isn't wise to that. A lot of the time that is the case. And while they are wise to it, there's reasons why they don't share. Um, it's pretty complicated and it very much depends on the country itself. But like, for example, the US has, uh, I think it was 17 ish intelligence agencies or Yeah. Yep. then, Uh, if you include some of the law enforcement, uh, kind of branches, which kind of have their own intelligence agency going on, there's a lot more. And the problem is, uh, if you sell something to, uh, one person, they might not really want to betray. All of their trade craft to, uh, even friendly agencies. Um, in terms of exclusivity, um, I would say it's becoming over time a bigger and bigger deal. So in the past, you, you could basically sell non-exec exclusively to a whole bunch of agencies, and they didn't love that you did this. But at the same time, it wasn't the end of the world, um, because if you go back, uh, 10 years or so, generally things weren't getting found in the wild. Exploit chains and vulnerabilities themselves and exploits were lasting for significant periods of time. Um, mitigations were, would come out from time to time, but way less, uh, 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. Um, and especially if you're making chains, like I said, you need more components. Um, and also they are tending to last less time because things are getting caught in the wild, uh, a lot more than they were in the past. And, uh, also mitigations are coming out quite frequently that, uh, cause significant problems. So you have this situation where, um, agencies have to pay more money, , for something that basically yields less result and for less time. 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, um, 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, uh, a lot of things get sold non exclusively currently, but, um, uh, over time, increasingly, I believe that the end customers, uh, at least in intelligence, maybe not so much in the law enforcement space. Um, are going to, insist a fair bit more on either exclusivity or some kind of semi exclusivity. Mhmm. 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? Yeah, I think, , there's several reasons for it. one is that the people doing defense, um, including both vendors and also, Teams, um, such as, uh, Kaspersky or OTAG, I know they're a vendor, but they're kind of adjunct. They're not like writing the software themselves. Um, I think these teams over time have matured in terms of their tradecraft 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, you know, , either our vast expansive ability to see vast tracts of the internet, or, um, or also like, um, collecting telemetry data and so on, like, um, maybe we can make some kind of deductions. And so I think it's a combination of those two things that things are getting discovered more now. And because of the increased. mitigations and things like that. If they impact, an exploits ability to function in a, 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.. Just Chrome, Firefox, Safari, You know, um, they all have different strengths and weaknesses, I think. both Chrome and, , Safari have very, uh, aggressive sandboxing now, which is significant, and, you know, they're constantly,, revamping various in place security mitigations to prevent V8 sandbox and, uh, various other, uh, mitigations that, um, both the browsers have added. I would say that, Both of them are, uh, are quite difficult, and it sort of depends on what researches you have at your disposal of, uh, what they like to specialize in and how well they know it, but like, finding a, um, a useful vulnerability and also being able to break out of the sandbox of those two, those two, uh, in particular are non trivial and require a lot of, I guess, Groundwork to, uh, have a good working knowledge base , to be even be able to spot vulnerabilities. And then beyond that, um, to, uh, 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, Thomas, so I can't really say Is that, is that equally true?, 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, you know, pointer authentication and all that stuff. Yeah, in general, the mobile targets are more difficult for several reasons. like you said, um, 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, uh, on desktops. I get the impression that things like targets like iMessage are in kind of the same rough tier as browser vulnerabilities, right? Like a, you know, a drive by iMessage, zero interaction, just point and click and own somebody's phone up is a very valuable vulnerability right now, like comparable to, you know, full chain through a browser or not the case. No, um, 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, um, man in the middle them or something like that. send them a text. yeah, but then, um, it, 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 theirs in some regard. That changes, uh, the value of it, um, uh, perhaps significantly. So details like that can, can affect the value of them, which is kind of what we were touching on earlier, I guess. 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? Are there third party applications? I mean, WhatsApp is probably an obvious example where, like, that's also, I assume, a very valuable vulnerability. But there are Spotify or something like that. Are there, like, goofy other applications that are weirdly valuable? 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, uh, it can also depend on, as I was saying, who you're actually selling it to. 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, uh, You know, the Middle East or something, and they're all using some particular application there. Maybe that is more valuable to people for whom that is their charter. But if you're like a domestic sort of law enforcement or something like that, then maybe it's 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, um, and who you're trying to target. As an another example, perhaps if your charter is trying to, for example, just discover, uh, people behind pedophile rings or something, then perhaps Mm hmm. Tor slash Firefox thing is more valuable to you than other agencies and so on. Or some dark web, very specific sort of platform that seems to be very popular with a certain clientele and only them. Yeah, exactly. So in your, in your deck you basically have a bunch of predictions of the future of the market. Um, and like speaking to a lot of the stuff we've already,, touched on, the sort of impact of a lot of these mitigations and like rewriting things and like all these protections on memory, reexamining the value of these memory corruption bugs and the longevity and usefulness of, uh, you know, those sort of exploits, predicting that that's going to retarget, uh, a lot of solutions for, you know, Uh, lower compromise, like lower capability, but cheaper, uh, 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 gonna be focusing more on web style bugs. Right so um I'm actually really glad you asked about this because I've been thinking of how to work in some commentary on this Firstly uh yes the sandboxes like that are thing that's driving the market to do something else, right? So, um, if, 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. Um, no one's targeting anymore because of that thing. Memory corruption, uh, has been the centerpiece of most vulnerabilities and chains of vulnerabilities. Um, not all, but like a large percentage of them. within the commercial market for, um, since the beginning, I think. And so the reason that they're generally, they're generally in the past being so popular is, um, uh, you can find them in, from all sorts of vectors, um, and, uh, with some engineering work, you can generally gain the highest level of access possible, which is code execution. But over time, um, the engineering, um, The effort has soared and the access that you get is less. So earlier on, uh, 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. Um, if you look at iPhone, for example, then you're like, oh, they've got a sandbox, so 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, uh, there's like KTRR and then, um, PPL and that. So we can't actually execute code in the kernel anymore. We can get read write, um, uh, whatever, uh, read write access to memory, which is nearly as good, but, but not as good. And then it's like, Oh, actually, um, with PPL and FVTM, 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, um, moving forward, uh, various, uh, 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 go, Okay, 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. 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, um, 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, um, to leverage significant amount of access. 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 this roughly the same capability that they were going to get with like 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, you know, hundreds of thousands of dollars. Yeah, generally that's not really the case. Yeah, in their 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, uh, the reason I bring, bring up cross site scripting is, uh, 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 and things like, um, Zoom and, uh, even Exchange, uh, had an RCE that was, uh, multiple vulnerabilities, but the first one was like an SSRF or something. Because they had a web, because the way Exchange is set up, it's got like an internal web server that it communicates, yeah. makes me even more worried about electron apps. Yeah, I think finding vulnerabilities that affect Electron apps would be useful because, you know, it's like quite widely deployed in all sorts of scenarios, so I think that would be useful. Um, again, it depends on the vector and, um, how you can actually utilize it. is there much of a market at all for server side vulnerabilities? I remember back in the day at Matasano, this would have been like pre 2012, we had a client that was particularly interested in like RCE and PHP BB, right? Like that was actually valuable to them, which was, you know, it would not have been like my pick for what would have been valuable. But like, is there like a real market for, like, all the vulnerabilities that we talk about when we talk about markets are all client sides, it seems like. Yes, there, uh, there is a market for server side vulnerabilities. They're, um, considerably less common, I would say. But, um, there is absolutely a market for that. Targeting various, I mean, we saw from EternalBlue, for example, they, you know, the vulnerabilities in SMB and stuff like that. Like, there's absolutely a market for, for that kind of thing. One of the hairy things that I think we're getting into is increasingly over time a lot of server side software has sort of been replaced by clouds. And then you start getting into like, okay, um, 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. Um, uh, so there's probably no real market for that locally, but for your adversary, like, why wouldn't they do that? Of course, I would, you know, so it's going to get into, I think, a tricky situation there. 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 slash 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, your signing, uh, 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 in all these other places, it's more likely to be now., I did specifically want to mention cryptography since it's, uh, in the name of the podcast. Um, in the past where we, you know, you have these, uh, chains of vulnerabilities, cryptography didn't play a huge part of it. Like, um, the only cryptography generally encountered a long time ago was TLS. And, I mean, uh, it wasn't even used very much, to be honest. But like now I, I think, um, cryptography in some format or another is baked into like every single layer of the infrastructure. So, you know, uh, TLS, which is ubiquitous, but then down to the code signing, uh, and then down to the CPU itself, which is using a PAC or similar and, you know, trusted bootchains and so on. So every layer has, um, some level of cryptography in it and cryptography in various situations is the keys to the entire kingdom, like if you can sign stuff as Apple or something, you bypass like 500 layers of security, like kind of thing, you know what I mean? Um, and so there's so much, there's so much there, uh, that can be useful. Um, we we've seen over the years, like. Uh, attacks of like, hey, you can actually do, you know, evil upgrades or things like that. So doing that, uh, 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, you know, the PAC signing on, on the CPU itself, they could go, hey, this is actually totally predictable or something, um, for iOS. That's useful. and so I think the people that have a crossover knowledge of both vulnerability research and cryptography is something, uh, to be highly sought after in the next, , five to 10 years. Oh, boy. Ha ha Yeah. Yeah. Yeah. So if paying off big time, Tom, uh, you can, you can apply, you can apply, uh, for a job. The, uh, the last exploit I wrote, I was impressed with myself for getting the shellcode to be all lowercase. That's how, uh, how rusty am I? That's how rusty I am. So just a couple of more questions, and then we will let you off the hook here. And these are, uh, 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 Other people in your field, like other people that are doing commercial development of exploits and selling them, uh, would like sharply disagree with you about. hot take. Uh, not that I can think of off the top of my head. Uh, generally what's happening in the market is people converge on very similar solutions to things, um, particularly as things get more difficult. Um, Um, and so, uh, 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, uh, with this new company was when I was taking a year off, I was giving keynotes like this, um, this blue hat one and, uh, several other ones where I was saying like, uh, 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, uh, with this company, um, and other areas, by the way, is also hardware, like we, uh, having very low level and hardware style vulnerabilities, not unlike the, you know, it started with RowHammer, but then, like, Spectre and all those kind of things, like, how practical are some of these kind of attacks, and, like, 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, uh, let's try and think about what's going to happen in the next five or 10 years. And try and build up some knowledge there. And, uh, a lot of it's speculation for me, like, I don't know as if various of 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. 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? Are you still, is your day to day still all technical, all doing development work? So I do a lot of, uh, management stuff for sure. Um, I, 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, um, we understand this work is very difficult and can be very demoralizing. And, um, it's asking a lot of people that you hire to be like, Hey, can you just, um, find a mainline, uh, Linux kernel bug for us or something? Um, so I like when I'm able to find vulnerabilities or craft exploits or something, um, cause 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. So, um, I think it's good kind of team, team morale to, if you have management trying to contribute in, in some way other than just going to meetings and so on. Awesome, 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, uh, no problem. If you've got any other fights on Hacker News, uh, drop me a message and I'll, uh, I'll come in and sort it out, not that I think anyone there will talk to me. Thank you, Mark. Security Cryptography Whatever is a side project from Deirdre Connolly, Thomas Ptacek, and David Adrian. Our editor is Nettie Smith. You can find the podcast online at scwpod and the hosts online at durumcrustulum, at tqbf and at davidcadrian. You can buy merch online at merch. securitycryptographywhatever. com. If you like the pod, give us a five star review on Apple Podcasts or wherever you write your favorite podcasts. Thank you for listening. 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. Uh, talking about, uh, you know, just the market for, for exploits. Um, and once again, we do really want to greatly thank, uh, Mark for, for coming on but now it is nighttime and it's time to talk about exploits with Thomas. Well done, David. I guess we learned that there is no market for logout CSRFs, Thomas. How does that make you feel? Alright, so, uh, yeah, I mean, I don't know. I'm glad to be talking to you about this now, right? So, um, I guess, like, I have, like, I have a couple of takes. Um, 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, Do you feel that you confirm your priors frequently? I feel the urge to use those words somewhat regularly, and I try to stop myself. So I'm gonna list off some priors, and you can tell me how sane they sound in light of that conversation, alright? 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, um, you heard Mark talking about how sorry, Thomas, is this, is this about exploit markets or does this become a seminar about B2B SaaS sales, right? Like we've got our solutions page, , and, that's how you sell things. You can understand me sticking close to my personal current area of expertise. So yes, it is both. It is both. So, um, You heard Mark talking about like, um, 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. 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. 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 10 different people who might be interested in having that outcome, right? Um, I don't believe that ever really happens. I'm prepared to be completely wrong about this, right? But I don't believe that that you're saying there's not like, uh, uh, outbound sales, uh, webinar type things, um, that are like convincing people that they want, um, uh, some sort of specific component, rather. It's that, like, the people that know that they need to achieve the thing are, are going and looking at how to do that, basically. Yeah, I think it's an easy sale to say that like, uh, 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. Um, like, there's, there's a sort of, Just, just to be clear, organized crime and, like, what Azimuth and Vigilant security, um, do are, are very different things, um, yeah, not associating Mark with this at all. Yeah. point, right? But in the context of a, in the context of a message board argument about exploits, which is where I live and breathe, right, like organized crime actually, uh, features much more, uh, potently than the intelligence community does, which is where like, And the entirety of where, where Mark plays. How does that sound to you though? That my, my, my pitch about like, there are, the buyers are calling all the shots about what they'll buy. And if you, if you don't have something a buyer already wants, your thing is worth zero. I mean, I made the joke about, like, webinars. I'm sure there is some level of, like, sales and showmanship, just like there is in any market. But yeah, it's not that, like, Um, you're, you're selling, um, 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, like, 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, I would do this, this is how I would further my investigation, this is how it would, fit into the, the corporate hierarchy, um, pivoting to like the non government offensive security world. Like if you are doing organized crime, presumably you already have business processes for like laundering money and like moving money around, right? Like if I were to myself to do a hardcore pivot from product management into, uh, uh, computer crime, um, much of the struggle. would be on, like, the boring business side, right? Like, once you've done some, like, you've, uh, acquired a bunch of Bitcoin, like, a 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, right? These are, these are all things that you need to have experience with. Like, whether it's 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, right, 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. 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 Yeah, but you, like, don't become, I think that, like, you don't join organized crime, or are you unlikely that your first, , foray into the criminal world is to, like, steal three million dollars of bitcoin from someone you've never met and then cash it out because, like, that's a great way to get arrested two years later, right? Like, Maybe? I don't know. I have no idea how often that happens generally. So like, um, I think that has implications for, like, bug bounties, and like the constant comparisons that are made between, 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 comment will be, well, this vulnerability was going to be worth, you know, 2 million, you know, in the, in the exploit markets or whatever. And it's like, um, probably not, right. There's a whole thing that Mark has about when the, when these vulnerabilities are worth money. And like Apple's bounty program wants a full exploit chain and like, they want, but don't require reliability. You can sell a lot of things to Apple and to Apple's bounty program that you presumably cannot sell to resellers for the intelligence community. Yeah, and you don't even need a full chain, right? At just about every bug bounty, you'll get more if you provide a full chain and you may even have like time to like amp up your payout if you give part of a chain and then you come back soon enough later and are like, hey, here's the rest of the chain. Um, but like fundamentally the price that's being paid for something like that by a bug bounty program and, the price that you would get selling into the vulnerability markets. Um, are just like two completely different products and so they're not directly competing on price and it doesn't make sense to to not only like you don't want to match the like theoretical like oh well if this affected every iPhone you could do you know 10 trillion of GDP damage payout but also you're not even trying to like match the price that you might get in a private vulnerability market like you're just selling different products. You get to talk about things you submitted to a bug bounty publicly. You get to understand how it's used in the sense that it goes into a bug tracker then is patched, right? 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 BlackHat 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? So like, I think 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, 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. It's just, um, 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. 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 gonna be much smaller. 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. Yeah. you know, Mark obviously believes that, you know, full chain exploits there, like the sky is kind of the limit. I what those prices are going to be right. Um, but like, yeah, like that seems true. Um, and, and that being the case, it's like, how are vendors supposed to compete with state level adversaries when like the states are always going to outbid. Yeah, I mean, I don't think that quite the sky's the limit, but you're comparing it to, like, 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, right, paying for health costs or care costs or pension costs or whatever for the people involved in that for like years to come afterwards. Massively more expensive to send someone halfway across the world to go and like use their magnifying glass and do investigative work than it is to like own their phone at a distance. So there's like an interesting dynamic here, right? Because, okay, so, 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, right? That's below the noise floor for what any individual buyer, like, human buyer was gonna feel, like, working with government budgets, right? On the long term, yes. Um, I, I don't think you can just, like, jack up for a variety of, , supply and demand and just, , budget reasons. I don't think you could, like, just add a zero to the price and have it work out. Right. I mean, it's going to be a gradual trend or whatever. Right. But like 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, you know, 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? 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, 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, like, 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, like, active war zones, or from, like, North Korea, but you tend not to see a lot of posts from the threat hunting teams that are like, Oh, and we found the, that, uh, this 0-day 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, at not getting detected as well as 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 gonna go away anytime soon. And so any compression on the supply side, i. e. firms going out of business. As long as the top end can still continue to find exploits, even if it's like twice as hard as it used to be, as long as they have enough to satisfy the demand from the top end of the market, those prices are just going to like 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, the, the, the demand side is fairly inelastic. So there, there is a rational goal for, you know, a big tech vendor to drive the cost of vulnerabilities up, right. Cause it's getting rid of a big swath of, you know, crappy or criminal exploiters with vulnerabilities, right? It's like getting rid of the riffraff, right? But I wonder, like, if you fix your adversary as, like, China or a Five Eyes intelligence agency, right? Like, what is your, what is your theory of change? What is your long term goal with, you know, working to drive the cost of exploits? Why are you outbidding? Why, if you're a big tech vendor, apart from getting rid of the lower class of, maybe just say like, apart from getting rid of the criminal exploitation people, right? Like, what is your, what is the outcome you're hoping to get by outbidding state level buyers for, you know, for vulnerabilities? Well, the bug bounties are already like not out bidding state, state, uh, yeah. But, uh, uh, state, uh, states for those vulnerabilities and it's like not clear that doing. So I, I guess your question is like, what would change if they did out bid them? And the answer is like. Unless they had, you know, absolute full visibility in the entire market, which you wouldn't. Like, you'd just spend a lot of money, right? Like, and then someone would still find something to use somewhere. And now we've just, like, jacked up the price for, uh, only a marginal security benefit, if any. I mean, they, they do outbid for a large class of vulnerabilities, right? For the large class of vulnerabilities that top tier buyers don't buy. Yeah, stage fright, for example. Um, actually I don't know if that one got paid out with a bug bounty, I don't, I don't know the reporting story on that, but, you But things like that. 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, like, don't actually, uh, um, Demonstrate a full exploit, like, or if you, you would get blocked by a mitigation later, if you're like, oh, I found a, like, type confusion in this code engine, um, and you can show how code could cause that to happen, but not necessarily, like, how would you get it at someone? What would you do after that? Was it still sandbox, right? Like, you'll still pay for it. Um, or if you can, you know, show just like part of the code where like you're obviously reading like attacker controlled data, even if in usual operation of the program, it's really hard for an attacker to control that data, like bounties will still pay that out, um, and those things just like wouldn't be useful to the offensive market. Or something that requires like a hundred unique UI interactions done in a specific order. Bug bounties will pay out for that sometimes, but there's no way in hell that like something that requires the user to do like a literal dance with their mouse is something that a vulnerability market buyer would want to buy. Yeah. I mean, that makes, that makes sense. This ties into a thing I've been, I've been thinking for a while about cryptography vulnerabilities and about like the standard cryptography adversary is NSA. And obviously NSA has like enormous budget and there are classes of, You know constructions that, that get used or mitigations that get used or whatever that like 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, you know, defending against terrorism or monitoring China or whatever it is that NSA thinks it does, but rather just accumulating budget for NSA is like, it would what, you know what they say, the purpose of the system is what it does. Well, Yeah, right? Like, I don't think this is a weird thing to believe, right? Is that, like, institutions, like, 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. 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. Like, uh, um, like, improving the security of software in general is probably still a net good, right? Yeah. I mean, yes, I'm We're not gonna knock the entire industry down. I'm, I'm, I'm making, I'm making positive descriptive arguments and not normative arguments. I am not a nihilist, but, uh, it's just interesting, right? Like, I don't know. I'm just, it's, it's, it's just an interesting thing to noodle on. At this point after hearing all of that, where do you come down on prices for cross site scripting vulnerabilities and random websites? Um, I mean, I've been of the opinion for a long time, including when I was, at Censys, um, where we didn't have a bounty, and I was like, no, we're not gonna have a bounty, and if we did have a bounty, um, we're definitely not gonna, like, outsource it to a third party, except for maybe the payment processing aspect because, like, it turns out, like, 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. We'll let like Ben Thompson and Stratechery 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 like, don't want a bug bounty. It's just a waste of time. This isn't to say that like security isn't important, but you're just going to get a bunch of bad submissions about stuff that isn't very important. Um, and like, you're better off just like having a security team. The, 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, like, where the security team should spend effort, right? 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, like, Stop groupthink. I believe Justin Schu said this in like our second episode or something, right? That it's a prioritization and sort of like a metric system for, oh, you know, are we doing well? Did we, like, we put in some mitigation or did some architectural change to make some class of bug be, you know, 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, like, just don't run a bug bounty because, like, no one cares about XSSs in your sites. Not that you shouldn't fix them, not that they're, like, not a problem, but there's not a buyer for them and you shouldn't, like, artificially create a market for it by creating a bug bounty. That's my hot take. seems like a reasonable take. Well, anything else you have on your mind after the Mark Dowd interview? Man, it's great to be at the top of any market is really what I'm saying, right? Like, it's what we're getting away here, right? 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. Let me tell you, that is probably bodes well for your future business prospects. I feel like going back to 2005, maybe, I would have, I would have still been saying it's good to be Mark Dowd. So, uh, I agree with that takeaway. 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 Ptacek. We've got a little podcast business on the way out. We are putting together a live event in Las Vegas during Black Hat. There will be mingling. There will be a live podcast. There will be a live Q and A. Uh, 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! Thanks again, Mark.

Security Cryptography Whatever

Zero Day Markets with Mark Dowd

Listen to this podcast on