Risky Business #836 -- You can't patch the bugpocalypse

Hey everyone, and welcome to another episode of the Risky Business Podcast. My name is Patrick Gray. This week's show is brought to you by SpecterOps, and they make, of course, Bloodhound and Bloodhound Enterprise. And SpecterOps' very own Jared Atkinson will be along in this week's sponsor interview to chat about a few things. I mean, one of the things we're going to be talking about with him is something we're also going to be talking about in the news section, which is, you know, things are sort of pivoting back to a prevention paradigm and away from a detection and response paradigm at the moment. And that's all happening because of AI and big changes to the threat landscape caused by AI. So that is an interesting sponsor interview coming up after this week's news. Now, of course, Adam Boileau is still traveling this week, which means we've got a special guest co-host joining James Wilson and I for this week's show. He ran security for Adobe, both product and internal. He ran security at Cisco. He also ran security at Salesforce. Adding to that, we might put he was the captain of the Titanic. He piloted the Hindenburg. He is Brad Arkin, and he joins us now. Brad, thanks for joining us. Glad to be here. What was your actual title? Because we always have called you a CISO for those three, but your title was not actually CISO, was it? Yeah, so Salesforce was Chief Trust Officer. Cisco was a combo, chief security and trust officer. And then Adobe is chief security officer. Excellent. Okay. But basically you did the role that we normally associate with what a CISO does. Yeah, top security leader. Top security leader. Top security. Top dog. Yeah, yeah. The throat to choke. Well put. All right. So let's get into this week's news now. And we've got a couple of stories that pair nicely together. One is from Reuters and one is from The Record, where we've got govies, like officials from both the US government and the UK government, coming out and saying, hey, you know, AI is going to result in a big deluge of patches arriving. So, you know, you'll need to go out there and just start patching stuff quicker. This seems to me like somewhat magical thinking, because I think if people could patch quicker, they would probably already be doing it. James, what is your gut reaction here? Yes, if they could, they should, but also there's an element of maybe they shouldn't. Like if we are telling people to patch really, really fast and we're dealing with an absolute deluge of patches coming in, that to me means we are essentially saying don't test as much, shorten the improving cycle to make sure things are safe. And even if people do get faster at patching, the second order impacts here really concern me. like just patches getting deployed rapidly, the lack of testing, the amount of entropy that that's going to introduce into systems. You know, not every patch just fixes bugs. Sometimes they introduce bugs of their own. I get why they have to publish this advice, but at the same time, you just look at this and go, nothing good is going to come of this advice either. Yeah. Now, Brad, I mean, it strikes me that if you're a government official right now, you're under pressure to do something. This is something. So that's why they're doing it. I mean, it sort of feels a little bit like that. What's your take here? Yeah, I think because of mythos, we need to be shown to be busy in some way. I like the fact they're going from three weeks to three days while at the same time offering. Oh, now let me just, sorry, I should just step in there and clarify that, you know, really what they're saying in the US case is that once something's on the SysAkev list, you know, currently they can order US agencies to patch those bugs within three weeks. And now they're saying, well, we're going to shorten that to three days. So we're going to like really crack the whip. And, you know, once something is out there being seriously exploited, we we want to have the authority to give them three days to fix stuff which yeah again i just don't feel is actually realistic yeah and you ask them what to do about the seven day cooldown to avoid supply chain attacks and then their heads explode because they patch and get the malicious you know upstream compromise or do they not patch and get compromised by the kevalist exploit so yeah yeah i think this is all in pursuit of what is likely to be shown to be a failed strategy and right now we we can still pretend it might work if we can just get fast enough and i think ultimately uh we're gonna have to figure out some new approach here to keep things safe yeah well what does that approach look like right because i've got my opinions on that but i want to hear yours yeah so to me i keep going back to the like mid 90s you know when everything was fresh and we had problems for the first time and all software is trivially exploitable to people who knew how to do it and the way that we kept the world safe was not fixing everything it was just keeping the bad guys away from the software using network controls. And so firewalls are invented and other things like that. And so I think today, being able to gate the bad guys' ability to reach the surface in the first place is going to be the winning strategy that's more sustainable than the idea of the patching, you know, patching update over and over again. Yeah. I mean, I feel like, yeah, that sort of hardening is 100% where it's at as well. I mean, like listeners know, I am on the board of a company that sort of does these sort of network controls, which is knock knock. But I mean, there's other ways to do it as well. Like what's like tail scale, right? Like if you mess around with tail scale and whatever, IP restrict where you can. I mean, it really does seem like making yourself a small target is going to be, is going to get you further than trying to patch absolutely everything in three days, which just seems like an unachievable nightmare with awful second order consequences as well, right? As a bonus. Yeah, I think the thing for me is that a CISO or a CTO or a top security dog shouldn't be having a discussion about how can we patch faster. The conversation needs to be right now is what needs to be true for us to continue to operate despite virtually every system and bit of software and application in our network having easily trivially exploitable vulnerabilities, right? If that conversation plays out, I'm sure it's going to end up in all those answers that we just talked about, not, yeah, let's just patch really, really fast. Yeah. So look, to put all of this into context, let's look at what's happening with vulnerabilities out there like this week. And one of the big ones is this bug in C panel, where something like 44,000 sea panel instances have already been rinsed by this attack, this exploit that has apparently been in the wild since February, right? So it's been used as ODA for quite a while. Someone's found it. And now CISA is saying, well, federal agencies have until May 3 to resolve it. And I'm thinking, I mean, what is it you said, Brad? Like how long would you expect it to take an attacker armed with this exploit to own every single publicly reachable cPanel instance? The idea that you could survey the internet in advance, line up all your targets, get ready. And if we're only talking less than 100,000, it seems like you should be able to do that in a few minutes. And so from when you use the first one, do your QA in a lab offline, and then you're ready to roll, you roll it out and do it. It seems like you should be able to get 100% of them within minutes. And so whether it's three weeks or three days, you're going to be way, way too late with the patches on that one. Now, look, you know, staying with the theme of vulnerabilities that we've seen this week, there is an AI discovered bug called copy fail that popped up last week. Now, this is a priv-esque affecting every Linux distro out there. Tiny little babby exploit that is very reliable. So presumably every attacker out there who had a user shell on a Linux box now has root shell on those boxes. And again, this is the sort of thing where like unless you can outrun the attackers, impossible. you know it's going to get exploited but James I know you enjoyed this bug. Yeah I did I mean I remember when I saw it first in the bulletin and it was described as 372 bytes to get root it's like my god each one of those bytes must be magical and sure enough they are so this is exploiting a logic bug in some of the crypto code that handles essentially IPsec tunnels using encrypted sequence numbers right I won't get into the really eye-watering detail on it but classic sort of thing. There's a function that was taking a destination buffer. It was using that destination buffer as its own personal scratch pad. You could write outside that buffer and just outside that buffer was a really nice bit of page cache that you could essentially use to kind of mess with the cached attributes of virtually any file on disk. And of course, files like setUID binaries are great targets there. So just a beautiful bit of engineering. But the thing that makes this different, of course, is other previous bugs we've seen, they rely on some degree of race conditions or something specific to that distribution or something specific about how it was compiled in. But because this is a straight up logic bug, it's just it universally applies everywhere all at once. And that's what makes this thing a real Internet melting moment. so much so that you would think that a really high degree of coordinated disclosure would have gone into this and dot, dot, dot. Absolutely none from what we can see, which is just like, what were you thinking? Well, who was it who found this? And like, this was some sort of AI augmented bug hunt thing, right? Like this is an example of the new world, right? Where it's people that have not been, you know, bathed in the fire of being a vulnerability researcher for a long period of time are all of a sudden finding this sort of stuff and just sort of yeeting it into a blog post or whatever. I don't know if I want to give them that much of a free pass. So this is from Theori, which is I think a South Korean-based security company. It also has offices in the US. And yes, they have an AI pen testing or bug finding tool And they do actually call out in the write-up here that this was a combination of human sort of found the smell of that destination buffer being used as a scratch pad and then use the AI tools to sort of chain that together to get the full Privesk. But I think if you, no matter who you are, if you stumble across a bug that you found and they demonstrate can be easily trivially exploited on virtually every Linux distro, that is a point in time when you stop, contact an adult and say, what should I do here? And that just seems to have been completely missed. Well, and as a result, we get a 732-byte Linux Privas exploit that's universal. And yeah, of course, there were no patches for distros when this thing first landed. So that was pretty interesting. It looks like a bunch of the distros have shipped patches now, but it took a little while. Brad, you had some thoughts here. Yeah, yeah. So basically, I think this is a preview of what I think a lot is going to be happening in the world in the future. and so no coordinated disclosure, chaos everywhere, bugs that are being exploited in the wild for which there are no patches. And so then your patch latency timeframes and requirements, they don't kick in, I guess, until the patch is ready. And so you'd have active exploitation for how many days before a patch is available and then you've got three days to patch. And so, you know, when are we gonna admit that that's not the winning strategy? We need to figure out a different approach. I think this is a good example of what we could expect a lot more of in the future. Yeah, it's funny, right? Because I should mention that, you know, and you've been talking about the 90s, right? So people should understand from that that you have been in this game for a long time. You're actually part of the original OG, like at stake mafia from like back in the day. You know, I've been around for a similar amount of time in this industry. And I've got to say, it's a bit time warpy, right? The vibes right now feel very sort of late 90s, early 2000s. Is that the impression you're getting as well? Yeah, there's a lot of like first principles thinking that I can remember from 30 years ago that are suddenly incredibly relevant. Yeah, there's a whole bunch of new people kind of reinventing some wheels, right? Yes, yes, exactly. It's enjoyable. And look, speaking of like old school, like 1990s vibes, there's some new vulnerabilities in MoveIt from Progress Software. This is of course a file transfer appliance that wound up getting clopped. I mean, I don't think we should be surprised that there's more bugs in it because there's going to be infinity bugs in that platform basically. But I mean, yeah, I think the only reason I'm mentioning it is because I just feel like we've just looked at three bugs this week, which no one's going to patch them in three days. And even if you could, I don't know how far it's going to get you, given how accelerated the whole attack chain is by AI now. I can't see this advice being given by governments as being meaningful at the moment. Yeah. And for the movement bugs, they were either internally discovered or reported to them by friendlies from the outside. and so there's no evidence that they were being exploited in the wild before the patch was made available but it seems like you could chuck the patched binary update into some no guardrails local model and get a working exploit out of it with the right kind of harness to do that and in the old days this would have been tedious and not worth the effort except for certain people but now it seems like just about anyone could get it done in like 10 minutes and then put it to work And so the ability of the attacker to take a internally discovered bug patch, reverse out the exploit, and then use it within minutes is sort of the level of technology that we're at now. And the technology that goes into rapid patching hasn't really changed at all. And so, again, it takes us back to what's the right model that's going to win given these new timeframes. I mean, it's funny you mentioned that because I know people who in the early 2000s, that was literally their job was to take patches. from the majors, right? So like take the Microsoft patch and reverse it into an exploit. So that goes out into the exploit kit sold to the intelligence community for use as end day bugs because they're pretty effective like even on day two, day three, right? So I guess what you're saying is like, you know, the utility of that has been well-established, right? The utility of reversing a patch and rapidly turning around an exploit has been well-established. And yeah, with these AI agents, that is now like trivial to do that basically instantly. I think some appliance-based stuff, it's a little bit trickier because you might have encrypted updates and whatever. You might actually need access to one of the appliances to pull key mat off a box or whatever. But with something like this, I mean, you're just going to grab the VM, aren't you? Yeah. There'll be some VM version and away you go. But yeah, it's crazy, man, because everybody's got new abilities. Thanks for AI. Now, look, staying with advice from the U.S. government and its allies, the Australian and U.S. governments, along with a bunch of others, have put out this guide, James, which urges careful adoption of AI agents. And the guide itself really irritated you, as it turned out. Can you explain to the class why? Yes, this one really got me. it's it's lines like and i'm quoting from the the actual uh advisory that was published uh you know safely using ai agents means never granting it broad or unrestricted access especially to sensitive data or critical systems now i don't mind that that's good advice but then it's just you know companies should only use agentic ai for low risk and non-sensitive tasks and that's kind of the vibe of the whole doc it's very much carefully carefully softly softly gently gently And I don't think that is the advice that is useful or that the world needs right now. The low risk and low sensitive tasks, they're not worth deploying an LLM in the first place to do something there. And they should have been automated away if they truly low risk and low sensitivity a long time ago You know I want to see a doc that says you know here is compensating controls and other novel strategies for rapid deployment of high risk AI agents in enterprise, you know, or citizens, here's your new risk appetite. You're welcome. Adjust. That to me is the kind of publication that's needed because this in the hands of some folks in the C-suite will turn into a chilling effect that will slow down the use of AI to help defend against all the problems we've been talking about so far. Look, that's certainly the impression I get as well. I mean, it's something that I've been, it's sort of like this, it's the new old thinking, if that makes sense. This is the new old way. Because we've got new stuff and the until very recently way to do things like that's reflected in this document. But I guess what I mean by it's the new old thinking is it comes back to something I said like maybe a couple months ago, right? And sorry, everybody, if I'm a little bit foggy today and going a little bit circular to get to my points. I have spent the last couple of days in bed sick. I'm just sort of emerging now. So I'm still a little bit foggy, but I'll get there. Bear with me. But I guess the point I'm trying to make here is that this AI stuff is here and we've had a bunch of security people saying, oh no, it mixes code and data. We can't possibly use it for anything in the enterprise. And it's like, well, buddy, that's your job now. Your job is now to mitigate something that carries with it inherent security problems and risks. That's your job. So a document like this, I agree with you, James, where it comes out and it's like, here's how you can not have any risks while using this stuff, which is don't get it to do anything actually useful. And I feel like, yes, that is also like, thanks a lot. Thanks a lot. Slow clap for the govies who put this one together. Brad, I know you have feelings as well when it comes to advice like this. And in particular, the advice we've seen lately saying there should always be a human in the loop for anything important. And you agree with other commentators who've said that's a bit of a cop out when it comes to the way to use these things. Can I get your thoughts here? Yeah. So I think the first thing that jumps out at me is people lived experience using AI on the weekends at home on projects and helping the kids with homework or whatever it is they get exposure to the AI tools. they know it represents like a 99 99.9% reduction in cost clock time to get a task done it's an unbelievable temptation to be able to put this to work inside of the office like workplace and capture those savings and the acceleration to get something done a lot more effectively and there's no way that people are going to take years to ever so carefully roll this out as if it was you know like a three percent cost optimization opportunity it's a completely transformative of technology and everyone is so excited to experiment with it and the idea that the security person is going to stand in front of that freight train and just say no no wait wait or at least put a human in the loop because the human in the loop will like it'll first teach the human how to get out of the loop as fast as possible because they're just slowing it down and ruining all the value that's there to be had the other thing is the human will immediately their eyes will glaze over They'll stop paying attention. They'll stop inspecting after the third or fourth or 18th time that the AI was exactly right with whatever it is trying to do. And so it's just not effective control to insert the human there in the middle. And so to me, the idea that where you think a human might be valuable, having a separate sort of judge AI that would sit and evaluate, does this still make sense? is this consistent with our goals and things like that, that has a potential to be useful because they're not going to get bored or their eyes won't close over the way the real human would. And so I think the potential for people in the workplace to capture the opportunity this represents is way too high. And the idea that human loop or these other safety mechanisms are effective controls is fantasy because nobody's going to slow down and either slow it down to pay that much attention or they're going to do it in a way where they're constantly just hitting yes and approving it. And so to me, it's a, it's a pass through control and it's a way to basically like shift the blame onto the human and the loop, uh, instead of the policymaker. And I think engaging with the really, really hard problems of how do we make this new technology safe enough to use and like manage the blast radius and things like that. Those are really hard problems to solve, but that's what our job is now for as security people. And we've got to figure out how to do it. And shameless self-promotion here, Brad. That was kind of exactly the conversation you and I had earlier this week on the latest Risky Business Features episode is like, what are the actual real emerging patterns to start to deal with this without being the security guy standing in the way? And there's some really neat stuff there. It really got me thinking about, again, the co-mingling of data and code actually helps us a lot here because it carries context and command in one channel. But just thought I'd mention that, that that was a good conversation this week as well. Well, it's also, I was reminded Brad of a conversation you and I had many, many years ago when Adobe's code signing infrastructure was compromised and used to sign malware. I think it was like a Chinese APT crew. They managed to sneak in, get like one or two utils signed with a valid Adobe certificate. And then I think they were detected and evicted. Right. And I was like, why aren't you doing human review of code signing? And then you told me the number of builds that you were pushing in every, like in a single day. And I was like, oh well in that case you know and i think that's it's the same sort of thing right like in that case like i guess it was sort of controversial in some security circles when was that like 15 years ago 10 years ago september 2012 there you go 15 nearly 15 years ago um a date etched into your memory forever by the sounds of things but you know there were people in security back then saying it was insane that you would um you know have an automated process for code signing. I think this is similar, right? Where you need to automate as much as possible and then just have as many processes and safeguards as possible to prevent the bad thing from happening. Yeah. Just to give you a sense of scale, we had many thousands of servers in the build pipeline, build and release pipeline. And a standard, you know, build and release would involve, you know, many, many, many, tens of thousands of artifacts that are each being signed. And we would do that. I don't know, 100 times a day per product. And then, you know, thousands of SKUs of different products for different language packs and everything else. And so in the beginning, there weren't enough controls. It just made sure you're coming from the right, you know, properly provisioned server and things like that. And then afterwards, we started saying, well, we don't want file sizes to change too much. And we had these heuristics that we put in place to say, we want to catch stuff if it's a new file or things like that. But even that was really, really, really tough to stick to because every time you do a major dot release or something, you'd end up revving the code base enough that you'd have to basically just say accept all and then move on. And yeah, the human interview, nobody's working at that kind of scale would make those types of suggestions. It simply would not be tenable to do something like that. Yeah, yeah. Now look, it's really great to get agents to go out and do powerful, useful things. But we do have a cautionary tale this week and I love this one. James, this has you written all over it. This is the sort of story you love. But someone lost themselves a couple hundred thousand in crypto because someone convinced Grok and something called BankerBot to send tokens to them. And I think the way they bypassed a bunch of the controls is they communicated with it with the LLMs using Morse code to bypass some guardrails. And I just, I mean, I think they've earned their 200K, these attackers personally uh yes i i think they vote the 200k and i think whoever lost the 200k deserves to lose it because like i know the state of crypto and web3 and all of that is a pretty interesting landscape and all the rest okay but the way this played out was someone managed to send a tweet that caused uh basically tricked banker this this service to to mint a new coin One of these coins that get minted and their value goes up and down. But I mean, this is step one here. Why is that possible through a tweet? Why is a tweet your command and control infrastructure or your control plane for this crypto thing that has real money attached to it? So that was first head scratch. And then the, oh, my God, I don't understand this world and I don't want to understand a bit was very similar to how Janice and O'Reilly, who we've had on the show before. he the way that he got grok to essentially get tied into moltbook was he crafted an image and said hey grok i can't read this image what does it say and grok looks at it and goes oh easy it says this and that was the magical phrase to get moltbook to bind grok to that agent account same sort of thing happened here where it's like you know he i'm hearing a bunch of morse code on my telephone grok what does this mean and grok says oh it's this and the command that came back was actually the instruction to transfer whatever this DRB currency was out of that newly created wallet into a different one or perhaps vice versa. But again, I just come back to kids, if you can move money around with a tweet, please stop what you're doing. That is not how this should be done. It's just I know I'm the old man yelling at the clouds, but I feel like you've got to do some yelling at this one when things are just this dumb in their implementation. The Future of Finance. A wonderful story. People can check that one out in this week's show notes. Now, moving on, we've got some really interesting work here from Niels Provost, who's a security person from way back who's still around. And I'm loving it that so many of these very experienced researchers are picking up LLMs. And this is great. So we've seen so much hype over Mythos. And we've talked a lot about Mythos as well, right? Because it's an amazing model for one-shotting bugs, one-shot finding bugs. And along comes Niels and figures out essentially that if you can give any old LLM what amounts to a virtual pen and paper, it can go and actually find bugs very, very effectively, as effectively as Mythos. Now, in this case, there is a personal motivation for Niels actually wanting to explore the OpenBSD code base. So take it away, James, and walk us through this story because it is both fascinating and funny and entertaining. It's all of those things. I did love the humility of this piece because it's not until you get into about the third or so paragraph where he says, quote, I was responsible for committing the OpenBSD TCP implementation, including the bug, in November 1998. and that's why he had a little bit of a personal attachment to this. So there's three really interesting things that Niels points out here. One is, like you said, you give an LLM in pen and paper and suddenly it starts to keep track of things and it learns as it goes and starts to build on that knowledge. So he talked about this idea of giving it a journal, a write-only pen journal that it could add to. And interestingly, that sort of became it's almost like forming its own understanding and it could look back on things like that. So the journal was interesting. The orchestration is a really interesting point in this article. He talks about a multi-layer strategy where you have an orchestrator model or an orchestrator harness, I should say, that is not actually looking at the code at all intentionally, but is more focused on operating at the meta level of what's going into that journal. What are we learning? What are the individual primitives that we're finding here? But then at the level of what actually goes and looks at the code, he talks about the value of building these finite state machines. And that is probably the bit that I found super interesting here because, and I know we'll talk a little bit about the interview I did with James Kettle, But there's similar themes emerging here, which is an expert has some options available to them to codify their knowledge in ways that are really meaningful and useful for an LLM, right? If you've got a particular methodology for how you approach a code base when you sit down, for how you approach a black box pen test or whatever it might be, take that higher order sort of way you do things and codify it into a state machine that allows an LLM to do the same things in the same way. but obviously at a broader level of scale and deeper depth, then you get incredible results. And so when you put these three things together, yeah, able to replicate the mythos findings, a little bit of hand-holding, and we were joking before, I bet his hand-holding of the model is a little bit different to the way I scream at the model sometimes. But it's just beautiful work. And as you and I were talking in Slack, Pat, anecdotally I'm starting to feel like we are approaching the flattening out of the curve of model capabilities. It's an S-curve. It'll tick back up at some point because of some new development. But I think as, you know, like I can't tell the difference between Opus 4.6 and 4.7 or GPT 5.4, 5.5. Maybe that's just me. But what I can tell the difference is the capability uplift that you get when you start to graft on these finite state machines, these journals, these orchestrators, these harnesses. The harness is where the difference comes from now. Yeah, I mean, that's the thing, right? it's just fascinating that you can recreate these findings that had the whole world in a spin. It had policymakers thinking about legislative responses. It's just been such a big event. And then along comes Neil Provost and says, well, I'm just going to build a harness that's going to let other lesser models actually do the same thing. And it works. Brad, I mean, did this blow your mind as well? Yeah, I really liked the write-up. And my favorite quote in here, uh but fifth paragraph down it says with some manual steering i got the model to first replicate the bug and so basically like neils plus opus 4-6 equals mythos you know that's sort of my takeaway from this is that with the right uh you know know-how and experience somebody plus a model of lesser capability and it's the harness and everything else that james was talking about that's what's able to deliver these higher level findings and what interesting though is that as the models advance, the amount of skill required to steer that goes down. And so some of this is the model, some of this is the harness around it and things like that. But to me, the other thing that popped into my head is if you can picture Niels in a room full of more junior pentest type humans, and he's giving guidance about, you know, try this over here and like leaning over the keyboard and say, let me try this. And so I could see the team that he had assembled of people with different tasks, working on different parts of the exploit development chain. And then, but he had models doing it instead. And so now the idea that one human who knows what they're trying to achieve and they know a little bit about what they're doing can create a team around them of automated capabilities. And I think his blog post does a really wonderful job of going into a lot of detail about why he thought to implement these tools the way he did and how replicable the results were, no matter what model it was. And so the token cost, the number of tokens involved and like how much the inference cost was pretty much the same across the different models And so to me it just a really good example of being able to walk through all those details Yeah no I think it is amazing And it be interesting to see if the model capabilities are flattening out because it'll be a kind of a funny, like at least temporary end point for this whole hundreds of billions of dollars of CapEx is like, well, you put a few software engineers out of a job and that's basically where we are. But no, amazing that these LLMs have had such an impact in computing, but we'll have to see where else they are useful. Now, you alluded to this earlier. You spoke about an interview that you did with Brad in the Risky Business Features podcast channel. Brad does a weekly appearance, folks, so if you want to hear Brad and James having a chat, they do a weekly podcast in the Risky Business Features RSS feed, so you can find that by searching for Risky Business Features in your podcatcher, and I do hope that you do. And, of course, James is doing interviews across some of our other feeds. He did one the other day with James Kettle of Portswigger fame that was incredible. It was actually a sponsored interview for the Risky Bulletin RSS feed, which is where our news bulletins go and Tom and Grux podcast Between Two Nerds and also the Seriously Risky Business podcast. They're all in the Risky Bulletin feed. And so this was just the sponsored interview for that week. And it was so good that we pulled it out and stuck it on our YouTube channel because holy cow, this was James talking about the HTTP Terminator, which he's built. And look, again, I think it cuts against this mythos hype, right? Which is everybody's scared of mythos. Mythos is coming to get me. And then along comes James Kettle and builds something he's called the Terminator. And it's aptly named, right? He just let this thing loose on a bunch of domains that were participating in bug bounties and just let it run. And it was finding stuff like more stuff than he could handle. I mean, this is crazy work. And the other thing that I found fascinating about this interview is it shows the need, the continued need for tooling, right? So the idea that like something like Claude Code can go do a pen test just by itself is ridiculous. Like Tony De La Fuente over at Prowler is like, well, Claude uses Prowler quite a lot as well because it just can't do it itself. And I think Kettle, it was either Kettle or Def started of Port Swigur who made the point that like, you know, you can't do a pen test with just Netcat and Curl, right? Like you're gonna need some tooling at some point. So they're feeling pretty bullish on Burt. But yeah, like, geez, what haven't I covered there, James? It was a fascinating interview. It really was. I mean, for someone who's such a prolific researcher in their own right to find themselves in, I think James said that, you know, he kind of wakes up in the morning and he's got this HTTP Terminator running 24-7 on an instance in the cloud. And he actually has a sense of dread in the morning when he logs in because he just knows it will have found novel things at a rate of clip that he just can't keep up with at the moment. And, you know, that's a pretty wild position for him to find himself in. But again, the real secret sauce here is it's that encoding of his methodologies. I think, as he said, you know, he took his years and years of work of HTTP desync vulnerabilities and analysis and taught this thing, how to think like he does, how to work like he does. And that, along with those other tools that you mentioned there as well, that's the thing that makes the difference between getting a one-shot bug out of an LLM versus getting an entire exploit chain that I think his example was he logged in one day and it said, oh, here, I found an API key for a bank. And he was like, why'd you do that? I didn't even ask you to look at that bank. It's like, well, I found it. Here you go. It was funny where he's like, it sometimes would just get bored when it was trying to hit a target that it couldn't hit and it would just move on to the next one, which was pretty funny. But I do think this puts to bed as well the argument that I've seen a few people make, which is SaaS because it's security through obscurity. Everyone else is getting owned through these LLMs, but SaaS kind of has that obscurity piece, so it's going to be safer. And then along comes James Kettle gluing an AI agent to his methodology. And all of a sudden, everything on the internet is kind of like at risk. He's open sourcing this thing too around late July, which is just going to be the sort of chaos that frankly, I'm here for. Brad, what did you, I mean, I presume you had a look at that interview as well. Yeah, it's good stuff. Again, you know, we were talking about with Niels, with James, being able to take the repeatable methodology of how he approaches things and then how do you delegate that out to the alien technology like ai bots and own different parts of the workflow and so it's like the mickey mouse fantasia cartoon you know the broomsticks carrying the water everywhere um being able to mint out more and more copies of yourself to scale uh repeatable aspects of the workflow um that infinity james kennels is is not what the internet really i mean is it what the internet needs or is it the the last thing the internet needs. We're about to find out because that's what July is. Mark your calendars. That's happening. We're going to have to adapt one way or the other, right? We'll figure it out. That's right. The HTTP Terminator, it's judgment day is coming. Now let's move on. And this is like, man, this is amazing. Now I did mention that I've been in bed for a couple of days. I've not been feeling well, but still this one made me feel like I was having a bit of a fever dream. Headline is Trellix investigating breach of source code repository. and I'm like, I'm saying to James, hang on, again? They got owned again? And it wasn't Trellix that got owned the other week. What was the other one that starts with T? Trivy. Trivy, yeah. So that's why I was like confused because yeah, Trellix, Trivy, I mean, all kind of sounds the same. Like this is how many people are getting owned at the moment. But apparently Trellix had their source code repo breached. Trellix is apparently an EDR company which was born of a merger between what was left of the rotting corpses of McAfee and FireEye. and I think now I don't know if they've refactored that code at some point but I'm guessing the attackers here might be suffering from some sort of exposure trauma at this point from crack cracking open those repos James what do you reckon I think I think if there is a ransom it should be paid just so that they can cover their psychological bills and treatment that is going to be required like that you could imagine the attackers being you know running down their their target list and being like okay yep Trellix cool got it got their repos yeah got it cool let's take a look at what we've got oh good lord no put that put that away put that away can't unsee uh basically that's punishment enough i think uh we've also got an incident uh written up here by uh kaspersky which is uh demon tools or daemon tools depending on your preferred pronunciation um they got owned and were serving up malware uh with downloads what's interesting about this one though is there was a first stage that went to everybody and then a second stage that went to like 12 people. This has been linked to a Chinese speaking threat actor, probably, you know, Chinese government, you would think. And yeah, very, very selective targeting, which is kind of like, you know, maybe it's not the usual broad based D team Chinese stuff, right? If they're actually being selective here. Yeah, I think there is a lot more to this. Again, it follows the pattern of that very sophisticated social engineering, gain the trust, work alongside the maintainers, et cetera. And so, you know, and as we've seen, those things aren't cheap to spin up and run, right? There's a big investment there. And so I think what we're seeing here is pretty solid investment on a target that there must have been some, you know, at least prior knowledge of if we could exploit this, it would be very useful to us. And then, yeah, it's been out there for a while. There was the first stage and then on but of all the must have been tens of thousands if not hundreds of thousands of downloads of the first stage only 12 machines in stage get the stage two in very very selected industries as well I think I remember reading so yeah let's stay tuned to this one someone got what they wanted but it's not quite clear exactly what they're going to do with it yeah and I got a lot SolarWinds memories reading through, you know, this like multi-stage downloader situation. And when Russia did it, everyone was saying, hey, this is great espionage. You know, they're respecting norms. They're minimizing the blast radius and only going for legitimate targets. And so are we going to get the same kind of kudos for the Chinese? Or were they doing it to stay stealthy and extend their access for longer? You know, what are the motivations behind it to me is one of the things I'm really interested in to understand, you know, did they think they would get broader access for longer by staying stealthy. And then the final comment I'll make is that the number of open source supply chain attacks that are being discovered is through the roof. So Trivi is an open source project with Aqua, the Checkmarks guys, like there's been all these different security companies, open source tools are getting compromised repeatedly and used to push Moses code. And this is where you're getting things like seven day cooldowns and people saying we should wait longer for applying patches. What you do, Brad, is you would pre-position yourself in one of these companies' code bases. Then you would wait. You would find yourself a bug. You'd announce the bug and try to slip into the patch. If you can control the update channel, push a must-have update and then commingle it with something malicious. Set the world on fire. the zero day first and then push the update and then make sure the update includes something that you know the bad guys need running on the system so that is all happening in public because of the open source commits are all visible and so are we seeing the same amount of closed source supply chain compromises and they're just not being detected because no one can see it and then the Kaspersky caught this one but there's you know 10 more where that came from or is it going to stay as rare as you know like solar winds like once every four years kind of thing um so i think the upstream supply chain compromise as a vector for getting badness into your environment is really proven out very effective on the open source side and then it doesn't seem to have been matched yet on the closed source side so i'm keeping an eye out for that one that feels like a emerging tactic yeah i mean you don't know right like i i mean i i'm with you right like it's it's unlikely that it's as prolific, but you don't know. You just don't know. We've got it right up here too. I'm just linking through to it in the show notes. The FBI is now talking about these cargo freight thefts that we've been talking about because of the proof point research. So proof point's done a couple of tranches of research into these crews who hack into these freight companies and arrange to have their drivers pick up cargo that they want and whatever. The thing that was surprising here, though, is the FBI says $725 million worth of cargo was stolen in the US and Canada last year, which is more than I was expecting. I mean, that is what, you know, 72.5% of a billion dollars. I got to do the Dr. Evil like pinky in the corner of my mouth. Did that number surprise you, Brad? Yeah, I was bowled over looking at that. But I think it makes a lot of sense because, you know, the work it would take to assemble a crew and physically steal a single truck with that kind of labor you can apply it to just having the guys drive the trucks to where you want them to and then you know i'll float it for you and it that's a much more scalable attack and so these guys are profit seeking and optimizing you know financially driven outcomes and it makes a lot of sense it's much more scalable well they've learned from the cyber angle right well what's the the line we always say they don't they don't break in they log in and now this is they don't have to steal the truck they legitimately rock up and someone hands them the the consignment because they think that's that's the delivery driver it's just like yeah it's a good it's an amazing evolution it's goodfellas goodfellas but nerds yeah nerd edition of goodfellas i love it um congress congress has pushed the renewal of pfizer out to um june don't really want to talk about this, but James, you insisted that I keep reading past the headline on this one because the latest House action, and we've got Martin Matashak's right up in the record, the latest House action came after the Senate declared the previous bill dead on arrival because it included a ban on the Federal Reserve's ability to issue a digital currency. Now, clearly that is a good reason to torpedo the renewal of Pfizer. Brad, how America, how does America? I can't defend it. It makes no sense. Yeah, so 702, Pfizer, 702, yeah, kick down the can. The can has been kicked down the road until June. And then we've got a couple of, we've got a funny one here, actually, to get through, which is a piece from Forbes where the cops managed to arrest a guy who tried to, like, he was part of a home invasion crew who were trying to beat up some guy to get his, like, Bitcoin crypto keys and whatever. the guy wound up escaping so they didn't get the keys but they had they connected their phone to the stolen getaway car which meant that the MAC address of their phone was in the car and then they just went to Apple and got the information they needed to identify the suspect which is just like man when you're on the way in a stolen car to go and do some heavy criminal stuff like maybe skip the tunes I'm thinking I don't think you can skip the tunes sometimes And clearly that was the case here. And I do love that this wasn't just plugged in the OGS cord or found the Thunderbolt cord and plugged it in. No, no. They stopped and did a Bluetooth pairing. That's extra level of effort. It's all about the soundtrack. But kudos to law enforcement for thinking of this as an aspect. That's a pretty subtle detail to go and pull the head unit and see if there was a pairing for the phone. Yeah, it was a cyberpunk crime that got itself a cyberpunk investigation. You've got to love it. Now, we're going to end this week's news segment with some sad news. Stuart Baker, who was the host of the Cyberlaw podcast, he was a former government official. He has been always a big part of the debate around things like surveillance authorizations and digital privacy and whatever, usually more leaning heavily towards the side of the government and sort of intelligence agencies. agencies. But his name is Stuart Baker. And sadly, he has passed away aged 78 while he was out for a run. And, you know, it's a shame. I will miss Stuart. I did quite like him. I didn't agree with him on everything, certainly. But I was a guest on his podcast once, like, geez, I think that was around 2016. And that really cracked the door for us into the whole sort of DC scene. So he was always very generous with his time as well. He'd been on our show as well before. So yeah, Stuart Baker, Stuart Baker has passed. I mean, Brad, you didn't know Stuart, but you had listened to his show and heard him on ours. Yeah, I was a religious listener, at least the past 10 years, maybe longer. And he had a unique ability to piss me off like because he was so sharp in how he argued his points that I really really didn want to agree with But I had a tough time cutting through some of the arguments and the scaffolding that he had built to justify his position And so I had to really respect him for that He was someone that I felt I had to listen to because his angle would force me to think a lot harder about these topics. Yeah. And he was a big contributor at Lawfare and whatever. And I mean, I think this is the point about Stuart is even if you didn't agree with him, he was not, you know, you would never call him dumb right like he was a very very sharp guy who could argue his positions yeah extremely effectively and i think that's what made him such an important participant in the debates around all of this stuff right you got to have people on both sides who are capable of actually articulating a position and um you know we're all poorer uh for him no longer being with us so uh vale stuart baker but uh guys that is it for this week's news segment i do hope uh you enjoyed coming along Brad it was great to have you here first time ever in the news chair and again for those who want to hear more Brad you can hear Brad and James every week in the Risky Business Features podcast channel our latest podcast channel here at Risky Business Media but yeah that's it for this segment guys thank you so much for joining us we'll catch you again soon. Cool it's been a pleasure Pat thank you. Yeah thanks. That was Brad Arkin and James Wilson there with a check of the week's security news. It is time for this week's sponsor interview now with Jared Atkinson of SpectroOps. And SpectroOps, of course, is a company that does, you know, red teaming and pen testing, but they also make the product Bloodhound Enterprise. Bloodhound began as a open source project, which does attack path enumeration through Windows networks and Windows Active Directory. These days, though, it covers basically anything you want it to. They have done an amazing job with Open Graph so that you can extend that graph of attack paths out to everything from like GitHub to Google to, you know, whatever. It's really become like a Swiss army knife for enumerating attack paths for organizations. And, you know, there ain't no AI really in Bloodhound, but it is one of those companies that is benefiting from the AI revolution in that people have realized, much like what we were saying in this week's news segment, you kind of got to go back and gets a lot of the fundamentals right if you're going to survive in the sort of AI-enabled attacker age. So here is Jared Atkinson talking about that, about how the pendulum has swung back to preventative controls becoming favored again. And we also talk a bit about some of the latest attacks through SaaS and how OpenGraph can kind of help there. But yeah, here's Jared Atkinson with this interview from Spectrops. Enjoy. I think people are being driven towards kind of prevention. I think we kind of like skipped over prevention because we thought of it as this like thing that you build up the wall around your castle. And then we moved on to this assume breach thing, which was they're going to get in and now we just need to detect them. And I think there's this a little bit more of, OK, just because they got in doesn't mean they're going to be able to take over the domain. Doesn't mean that they're going to access your critical resources. What we need to start doing is kind of looking at the environment and understanding where are the most probabilistic places where they're going to get in. And that can be driven through vulnerabilities and external facing applications and things of that nature. What identities are associated with that? And then how are they going to move? How would they move from, you know, the point A, so to speak, all the way to whatever you care about? And then how do we start to eliminate those attack paths? So I think that that narrative is really starting to pick up and people are starting to appreciate. It's like if you try to detect them, you're going to be too slow. You're not going to respond rapidly enough. All we're seeing in all these breaches is people talking about how quickly the attackers are moving because they're aided with AI and things are just kind of moving a lot faster. And so it's all about kind of preparing the battle spaces, we used to say, kind of in the military, right? So make sure that you have eliminated the obvious attack pass or the easy ways for attackers to escalate from that initial access point. It's funny, though, because we were talking before we got recording. And as much as things have changed, they kind of haven't, right? Like all that's happened now is if you engaged in risky behaviors, like having, you know, like running Fortinets, you know, the odds were prior to all of this AI hoopla, you know, you were probably going to get owned. And now it's turned into like, you're definitely going to get owned. And that is funnily enough, like you would think you're probably going to get owned would drive behavior, but it didn't. whereas you're definitely going to get owned by some AI-equipped attacker, like what I describe as AI models are basically infinity script kiddies. It has actually changed behavior. I mean, this could wind up being good. Yeah, we were talking about how we've operated on this idea of assume breach for the past 10 years. The interesting thing is 10 years ago, it was kind of like you should act as if you're breached because one day you might be, and you're going to be better off if you kind of are operating from that perspective. Now it's like you're assuming breach because it's probabilistically likely that you are going to be, that you are breached at any given time. And there's also kind of like this interesting thing to where we started with more like server side exploitation as an initial access vector. Then kind of the landscape changed to where it became client side exploitation, phishing and things of that nature. And now it's almost like we're kind of coming all the way around to where now, like I know we joke about Fortinet, but it's almost like Fortinet is maybe benefiting from the, you know, conceptually, they're benefiting from this in the sense that now everybody else is going to be exposed as having similar amounts of vulnerabilities and being the initial access vector, you know, du jour from that perspective. So that's kind of a, it's an interesting perspective, I think. Now, another thing that you pointed out to me, again, before we got recording is people in InfoSec, and I never really did this conversation on risky business, because I always thought it was kind of like a pointless debate sure but everybody's always like out there on social media with the big opinions about uh open source you know tooling yep uh or offensive security tooling sorry ost like and whether or not you should make that available to all and sundry and it's oh it's terribly irresponsible to allow these things out you've pointed out to me that like these days if an attacker wants a tool they can just vibe code it so that whole debate has just disappeared you don't hear about it anymore yeah to be fair i haven't seen it so i don't know that i'm like looking for it all the time. But the general gist was that the two sides, there was a side that was producing and releasing the OST, so to speak. And the idea was, if you can think of it and implement it as an individual, then a real adversary is probably doing it. The other side was saying, hey, that's great. China might have that capability, but there's other people that are lower on the capability ladder, so to speak, that you're now enabling. But I think when we start to talk about, especially these newer models, that capability is readily available now. And it's just a question away from whoever wants that ability. I think of my brother-in-law who works in marketing, built a website for his company. There may be all kinds of problems with it, but literally it was just like back and forth, back and forth, and eventually a website pops out. So just the same kind of capability exists for somebody who doesn't know anything about offensive security testing, doesn't know anything about coding. They're able to just kind of describe what they want to do. And the LLM or the coding companion, so to speak, is going to be able to produce that for them. Yeah, I got to say though, it's absolutely insane what you can do with that stuff. Now we've developed a whole bunch. Well, when I say we, I mean, James, my colleague has developed a whole bunch of apps for us to use internally, which are just nuts. But look, I want to go back to what you said, right? Which is the pendulum swinging back to prevention. And we hear often about this pendulum swinging. if you've been in the industry long enough. On what basis are you saying that though? Like, where are you seeing the evidence that the pendulum is swinging back to preventative controls? Yeah, I think in general, what we're seeing is kind of this uptick in the discovery of exploits. And we're seeing that capability that we talked about with the OST. It's everybody now has the tool set that they need in order to conduct their operation. And so they're going to get in. And then we're seeing in a lot of these breach reports, like the Vercel breach report, I think there was the sales loft drift report that talked about that incident. And a big feature of all those reports is talking about the time to impact and how rapid that is. And the reason why I'm particularly interested in prevention is not necessarily to stop them from getting in. It's more from the perspective of by the time you detect them, they will have already achieved whatever it is that's going to hurt your business or hurt your organization. Yeah, yeah, yeah. So you're less about prevention and more about hardening, I guess. That's right. That's right. Yeah, the point. I could, yeah. We're particularly looking at like attack paths. So it's like, what are the, and we also have this idea that you're not going to stop them from getting into your environment. That's the assume breach mentality. You also probably can't protect every asset equally. What you need to do is you need to prioritize, essentially. And then you start to look at what are the inbound attack paths into whatever those things that we care the most about, those critical assets. And how do we start to eliminate those so that we talk about this concept of exposure, which is of all the different principles, the users or identities that that are in your environment, how many of them have attack paths into your critical assets? And if generally speaking, most organizations, the answer is 100 percent if they're not, you know, focusing on attack path management or this preventative approach. and what we could do is we could rapidly decrease the exposure number to something that's you know in the ballpark of like 20 which is uh you have 100 likelihood kind of the premise is you have 100 likelihood of breach uh but 20 now you have a 20 probability that that breach is going to lead to somebody having access to your critical assets as opposed to 100 20 20 chance of them getting like uh lateral movement to somewhere interesting handed to them on a platter as soon as they land anywhere, right? Yeah, no, I absolutely get that. Now, Bloodhound Enterprise, of course, it does, you know, your Windows, like it's originated from Windows land, right? And that's what it's, that's, it's meat and potatoes, kind of most of your market, I'm guessing, is that Windows market, but you've made great strides with stuff like OpenGraph. What's really interesting about those, you know, those incidents that you just mentioned, sales loft drift, Vercel, whatever, they had nothing to do with Windows networks. Like those attacks, they didn't even touch an endpoint you know i mean i know you've been ahead of the attackers somewhat in terms of developing open graph because you've been working on it for a while but are people starting to really pick it up in light of those sort of incidents becoming more common like the stolen tokens sort of not touching an endpoint you know or sas world stuff i think we're getting a lot of a lot of questions about that uh coincidentally like i don't even came and claim a strategic victory here it was very much coincidence and maybe maybe it was driven by our red team actually so one of the things that we benefit from at SpecterOps is that we have red teams and we are conducting operations. And we're kind of like using that as almost like the bushwhackers that are going into this uncharted territory to see what's going on. They have some objective that they have to achieve and then they're confronted with a real environment that they need to navigate through. And oftentimes they have to go off course from what Bloodhound is giving them, right? And so that means that they're going to confront these different platforms and all that kind of stuff. And so we had noticed that there was this big interest in kind of gaining access to the CICD platforms or to your code repositories. And so we used GitHub as an example of that. And GitHub ended up being a very central kind of platform for a lot of these kind of newer and modern incidents that we're seeing. And so that tends to be quite useful. One of the interesting things that we're really seeing is this has always been around with like OAuth and these third-party apps. what's happening is you have your environment and you're responsible for protecting and managing risk of your environment, whether that's like a GitHub organization or whether that's your Google workspace, like we saw with Vercel. But what's happening is people are granting a third party access into your environment. And that access could be as simple as like the ability to read a single file or the ability to have full admin over your entire Google workspace. That's becoming more common with these AI agents, right? So people are now granting access to third parties to access all kinds of things. And from your perspective, that's actually opaque. You have no idea what they're doing. One of the things that this was surprising to me when I first kind of discovered it. And so I assume some people might find this to be interesting. When you install a GitHub application, what you're actually doing is you're producing something that has access in your GitHub organization. And it's just an SSH key. When you install a third party app, you're just granting somebody's SSH key the ability to have those permissions into your environment. And you have no idea what they what they do to secure that that key right and so they like literally they may have it on on disc on their laptop or you know hopefully for some of these more reputable organizations they have some infrastructure that's protecting that and is reasonable but you have no idea and so what you've done is you've cut this gigantic hole into your into your environment and you have no idea what's on the other side and whether or not like in the in the versell situation would the compromise of an individual employee at that company lead to the compromise of your organization right so it's kind of like a third-party risk idea there i mean i guess the question is though is is this you know are the incidents like that driving interest in um you know in open graph yeah well so it's definitely driving interest in open graph and one of the big questions that we're trying to answer is how do we how do we represent all of these connections right and uh there's a lot of prioritization and what platforms we look at uh and and kind of start to build OpenGraph extensions for, specifically with kind of like enterprise support, because we want to be able to represent that third-party access as best as we can, maybe even help people go through those access reviews so that when a user asks for an OAuth connection, you're able to see like, what is the context and what is the downstream impact of granting permission A, B, or C? So that's kind of the direction that we're going with that. But also we're really interested in identity federation, in identity provisioning via protocols like SCIM and trying to understand how are all these systems interconnected? That's the thing that we think is really interesting is what we call hybrid paths or hybrid edges to where we're connecting, say, Okta to GitHub. And if I compromise Okta, I now have control over your GitHub account. People still using SCIM when there's been like decade-plus efforts for people to try to write better standards and everybody's still just using Skim. Oh, Skim is, yeah, it's very popular. Let's say that. All right, Jared Atkinson, thank you so much for joining us for this chat all about, I guess, you know, AI, how it's driving security fundamentals about offensive security tooling, a whole bunch of stuff. Great to see you as always. Yep, thank you, Pat. That was Jared Atkinson there from SpectraOps. Big thanks to him for that. And big thanks to SpectraOps for being this week's risky business sponsor. And that is it for this week's show. I do hope you enjoyed it. I'll be back soon with more security news and analysis. But until then, I've been Patrick Gray. Thanks for listening.