Mackenzie Jackson: Hello and welcome to The Secure Disclosure, the show where we bring you the latest and greatest tech content for you. We have an awesome show planned for you today. We're going to be discussing the McDonald's breach and how over 60 million potential McDonald's employees had their data breached. We're going to dive into how a Doge employee leaked private keys for XAI private models, and we're going to discuss that with the researcher, Philippe Katrigeli, that actually discovered those keys, how he did that, and what that means. We're also going to be looking into the discovery of 600 Laravel applications that were vulnerable to remote code execution with one of the researchers that found that, Remy Matas. And best of all, I get to sit down with Walt DeBond, drink some sake, and talk about the future of AI pentesting in a segment that's definitely going to ruffle some feathers. So stay tuned for that. All right, let's get into the news. The headlines this week have really been dominated a little bit by McDonald's. McDonald's had a very serious data breach thanks to a third-party tool that they were using. Over 60 million employee candidates had their personal information along with chat logs leaked thanks to Paradox.ai. Now, Paradox.ai is essentially an AI chat company that has someone called Olivia. Olivia is not a person. Olivia is an AI bot and Olivia does things like test candidates and does personality checks to see if they're viable for a McDonald's employee. And that's kind of creepy in and of itself. Now, this is an area where the news headlines tended to get it all wrong this week and annoyed me a lot. I talked a little bit about this on my social media, but essentially the headlines were all claiming that this is because a weak password was used: 123456. And that kind of alludes to the fact that either McDonald's had a weak password on their account or that there was some super admin account from Paradox that had this password. But like a lot of things in security, when you actually dig a little bit deeper and you get into some nuance, it isn't just quite that straightforward. The researchers that discovered this were Ian Carroll and Sam Curry. Shout out to them if you're listening. And what they discovered was that there was a test account that was created. This test account had the username 123456 and the password 123456, and it was really for a fake McDonald's restaurant. Now, this should have been the end of the story as in not that interesting, because if you're in a fake McDonald's restaurant, there's obviously no sensitive information there, right? A little bit wrong, in walks IDOR. And what they were able to do is manipulate an API call and basically change the ID. So, let's say this fake restaurant had the ID 1. They made an API call to retrieve information for the restaurant with ID 2, and it was accepted, which means it wasn't the correct authorization to actually prevent people from moving into different areas, thanks to the insecure direct object referencing. So this is actually kind of the real story behind it. The media, of course, has just focused on this 123456 headline, because it kind of makes everyone look dumb and a bit silly. But personally, I think an IDOR vulnerability inside your application is worse than using a weak password. And this doesn't appear to be the first time that Paradox.ai has had some security issues, because out there in the wild internet, there's also some other pwned accounts with passwords of leaks from employees of Paradox.ai. I think in this case, a dev considering the login that had their passwords leaked as well. And this time, I will say that they weren't 123456. The passwords were significantly better. Another big security headline this week has been that a Doge employee and someone working for X as well exposed some secret keys for internal XAI models. Now, it's kind of interesting because there's actually a very, very similar breach that happened a while ago, but I'm not going to go into the detail of this. Instead, I just thought I'd bring you the researcher that actually discovered this, how he discovered it, why it's significant, and what developers can do about it. All right. So, I'm joined here by Philippe Katrigeli. Welcome, Philippe. I'm so glad to chat with you today. 100% Philippe Katrigeli: Thank you for having me. Mackenzie Jackson: That's right. It's a running joke that we have is that I can't pronounce Philippe's last name, but he's told me that I'm getting closer and closer. So, I'm going to take that as a win. Philippe Katrigeli: That's a win. Mackenzie Jackson: But Philippe, recently some news has come out and it relates to research, or at least investigations that you did, about an XAI key that was leaked. This has been published in several publications at the moment, but not the least in Brian Krebs's blog. So maybe we just start with what actually happened here with this XAI key that was leaked. Philippe Katrigeli: Yeah, so that was I think on Sunday evening, but I got an alert on Monday morning that a key or a secret was potentially leaked by a developer. So I just got curious, looked at it. There were some things that were slightly interesting with this leak is that the developer was not using a standard XAI key. So the format of the key was slightly different, which I suspect is the reason why it didn't get, it didn't trigger, like 100 other alerts. I'm using GitGuardian, so I have some automated alerts and monitoring in place. And on Monday I got a notification that an AI entropy string was being leaked, which is not necessarily a secret, but it's an indicator that it could be a secret. So that's a string that has a high complexity that doesn't look like a normal word that can be used as a secret, but it doesn't match any known pattern as a secret, though it's not necessarily detected as 100% being a secret, kind of like I think you are talking also in the podcast about the Laravel app keys, and that's kind of the same thing when sometimes when you have a key, a secret key in an app, they recommend you to use a random string, but not with a known format. So there are ways to try to detect it with a higher probability of false positive. So that requires some manual investigation. So that's really what happened here. A developer leaked this key. Luckily, the key was labeled as XAPI_API_key. So it was fairly easy to figure out what it was, even though the format was not the standard XAI dash, and B64 key. And since I already reported some keys to them in the past, I already had some tools ready to test the key. So I just threw the key in the tool and realized that we had access to a bunch of stuff that we shouldn't have access to. So I reached out to the developer to let him know. It looks like he got my email because he fixed it, but he never responded or thanked. So then it doubled from here, and that's why I get a little bit more press coverage. Mackenzie Jackson: Yeah, yeah, see, this is the key out there that if a security researcher reaches out to you about a vulnerability, at least respond to them, because then the chances of it going to press are slightly smaller. Philippe Katrigeli: Yep. It's pretty much just a thank you would have been enough, but yeah, anyway. Mackenzie Jackson: So, but you mentioned you had some tools from previous leaks here. Like what, like we'll get into what this key gave access to in a minute, but what was the kind of previous leaks that we have, or why are we seeing such a problem with these XAI keys leaking out all over the place? Philippe Katrigeli: Yeah, so what's interesting is not so much the XAI key or anybody's XAI key being leaked. There's not much you can do with the standard API key of a normal user. These keys that we are talking about either like in back in May, I think Brian Krebs had another article, and these keys are internal developer keys that have access to a lot more models and information than the standard user key, and unfortunately, they don't have any restrictions in place. So the developers are using the same interface and the same API endpoints. It's just that they have more access. So when we reported it back in May for the same incident, we were kind of talking about the good practice of, all right, if you have internal developers or if they have access to an unreleased model, just give them like a special access. They should be able to access this API or this endpoint through a VPN or a special IP or different endpoints that is only accessible internally, rather than just putting it on the same endpoint as anybody else on the internet, because then all an attacker needs is this API key to start interacting with the internal models or things that shouldn't be publicly accessible. Mackenzie Jackson: Yeah. So we're really talking about kind of an admin access key from someone that's working, a developer that's working at XAI, and I think in this case they were a Doge employee as well. Philippe Katrigeli: Correct. Yeah, I suspect that's why it got a little bit more coverage. Yeah. And then what I was trying to highlight is the fact that we already reported something very similar back in May. Besides removing the key, they didn't change anything. So it's still exactly the same thing happened. They didn't put in place any safeguards for if they have developers making the same mistake, then restricting the access to this endpoint. They just removed the key, probably because it was talked about in the news, and then moved on to something else. So they didn't really take it seriously, in my opinion. Mackenzie Jackson: Right. And what, you know, in the reporting, this key actually gave access to a whole bunch of different models and internal models and areas like that. This is kind of interesting, and I like, I remember that I made some content around the last time that this happened, but what's the risk there for, like, let's say an attacker or just some malicious user actually getting access to these all these internal models and areas? Philippe Katrigeli: Yeah, so there's a little bit of speculation, obviously, because we didn't try to hack into XAI with this key. We only used the key to confirm that it was a valid key and it gave us access to some internal models, but we didn't go much further. But the speculation is out of these 52 models that this key was giving, the previous key was giving access to about 30 different models. There are some models that are internal that are labeled as Tesla or SpaceX, which we can assume that if they have models that are customized for these companies, they were trained with proprietary data from those companies. And then, by doing some smart questions or interaction with the AI prompt, you can potentially force the AI to leak some information that it was trained on, which may not be public information. So it's not like any model or public model. The concern, or what I was trying to highlight to them, is more that you shouldn't expose internal models to anybody, because you can potentially leak some confidential information that the AI was trained on. Mackenzie Jackson: And I think too, what also strikes me as very concerning is that this was hardcoded into a file. I mean, come on, you're dealing with sensitive information here. You're part of a government employee, a government program that has a plethora of access. We don't need to get into the political debate of if DO should have as much access to stuff as they do, right? But I mean, hardcoding a key, really? We're still here, right? Philippe Katrigeli: Yeah, I know. And ironically, so when I detected the key initially on Monday, the developer was still actively working on the project. I could see that there were regular commits throughout the day. Ironically, it looks like he was by-coding an AI agent to assist AI coding. So if you look at the project, it's a project for AI assisting coding, but it looks like he was by-coding doing it. Mackenzie Jackson: Oh, that's hilarious. That's like, yeah, right there. Prompt and cursor. Like Cursor, create a version of Cursor. Philippe Katrigeli: Pretty much. So and ironically, as he was progressing through the day and doing his by-coding, he probably realized at some point that the key was in the code and he did another commit to delete the key. Unfortunately, he didn't delete all his commit history. So it made it worse, because now the key was actually in several commits. And that's when I emailed him, letting him know that, hey, your key may not be in the master, but it's still in all the other commits and you may want to remove all this and cycle the key. Obviously, they got my email, because not even 5 minutes later, all the commits were removed. They scratched the project and restarted from scratch. But they didn't revoke the key. So the next day the key was still working. And as Brian Krebs published his article, the key was still valid. It is not valid anymore. So I guess he read the article somehow. Mackenzie Jackson: This kind of gets worse and worse and worse. I mean, this is classic, because I think what people, the knee-jerk reaction from a lot of people that I guess don't have experience is like, oh, I'm just going to remove that key and push another commit. But the diff exposes the key again. So if anyone missed it the first time, they're going to catch it on the second time, because now it's like, it's like it's propagated even further. Not to mention the fact that Git history pretty much lives forever. And I don't know if you've dealt with the fun of trying to rewrite Git history, but it, especially in a team, it... Philippe Katrigeli: Yeah, I think the easiest was to wipe the whole repo and then start from scratch, which is what they did. But yeah, that's, so, and again, this is a mistake that happens. I don't want to necessarily blame the developer for it. It's more that XAI, after us reporting the same incident two months ago, should have taken it seriously and had some slightly more restrictions for their internal developers. Mackenzie Jackson: Yeah. Yeah, absolutely. Well, Philippe, thanks so much for coming on the show and sharing this research. I hope to have you back. You always seem to find interesting things, so I'm sure we'll have you back on the show again. But thanks again for coming on. Really appreciate it. Philippe Katrigeli: Thank you for having me. Mackenzie Jackson: The final news segment that I want to get into today is that 600 Laravel applications were vulnerable to remote code execution when using keys discovered in public GitHub repositories. And this one's kind of interesting, because leaked API keys is one thing, but actually being able to effectively use them and match them up in the wild is quite difficult. Now, this one here is actually quite technical. So I wanted to bring in one of the researchers themselves that actually discovered this to try and break down the technical nuances of how this, because it's not quite as easy as discovering a Laravel app key and then immediately being able to use it. In fact, there's quite a lot that goes in between that. So, without further ado, let's bring on Remy Matas to actually walk through exactly what they did here. Remy, welcome and thanks so much for joining me on the show today. Rémy Matas: Hi, nice to meet you. Mackenzie Jackson: So, you're a security researcher. Do you want to just give a quick introduction about who you are and some of the interesting things that you've been working on? Rémy Matas: Yeah, so, hello everyone. I'm Rémy Matas. I'm working for Synacktiv. It's been like four years right now. I'm mostly working on stuff related to PHP and its frameworks. So today we are going to talk about Laravel, but I also worked on other stuff like PHP filter chains or this kind of subjects. Mackenzie Jackson: Just for those that maybe aren't aware, maybe we can just give a quick introduction about what exactly Laravel apps are and what the framework's used for. Rémy Matas: So Laravel is one of the most used frameworks, probably. So right now there is something more than 1 million public applications based on it. It's really useful in order to create applications quickly, because you've got some ORM, you've got all you need in order to create applications from e-commerce, CRM, or other things like that. You've got a ton of tools and plugins with a really active public community. So it's really easy to start developing by using Laravel as a PHP developer. Mackenzie Jackson: We're going to be talking about the app key that's actually kind of built into Laravel, and I think a lot of frameworks have a key like this. But let's start off with exactly what, what is that app key in there, and then we're going to talk about kind of some of the interesting things that you were able to find with this. But what is that app key that your research focused around? Rémy Matas: So the app key is one of the main secrets that is embedded inside the .env files in Laravel applications. It's used for anything related to cryptography. For example, if you need some data integrity checks with hashmac or something like that, it is usually used for that. You can also see that it is used when you are doing some ciphers with Laravel, and it's used for anything related to integrity or cryptography inside the Laravel environment. Mackenzie Jackson: These keys are kind of, can definitely be quite sensitive and we'll get into that. But one of the crazy things there is that you were able to find huge amounts of these keys in public GitHub repositories, I think 260,000 in total. So let's start with how on Earth you managed to do that and how you were able to kind of find those keys. Rémy Matas: It all started when we were trying to do the business ourselves. First of all, we tried to do some Google Dorks, some GitHub Dorks. We also searched inside the Laravel documentation itself, because it's not well known, but there was a default app key in really older Laravel applications, which was some random string. It changed a few years ago, and now any app key on a Laravel application is generated, and it's sorted to long bytes random string, which is B64 encoded. And so it's not really possible to guess it. You need to have it or to have a really big mistake made by developers in order to get your hands on it. So that's why we tried to see if there were some public common app keys leaking publicly. We met with Kim Waden, who is working for GitGuardian, who saw what we had to present. During that time, we only like started the project, we found three CVEs on really big projects, but it was really the premise of it, and he kindly said to us, "Do you want more app keys?" And of course, as you guessed, we said, "Yes, why not? That could be interesting." Because they were so interested in ways to detect when keys leaked on GitHub, and we were also interested in getting our hands on it in order to push our research even further. And so a few weeks later, they just sent out a big TXT file containing 200 and 200,000 app keys, something like that. And so, yeah. Mackenzie Jackson: Let's talk about what happens when these app keys now leak. So now you've got your hands on 260,000 of these keys. Are they all sensitive? Is it all critical? What was, because what's really interesting about your research is it is kind of you were able to go to the next step and actually kind of, I guess, prove impact. But were all of these keys kind of sensitive? Like what happened going to the next step of actually discovering? Rémy Matas: So, getting your hands on app keys in the wild is one thing, and as I said, it's a random string. You can't really know what it's linked to by default. So you need to make connections to understand where it's used. So there are two ways to do that. You can try to, with Dorks, as I said, with GitHub or Google, you can try to see what projects are using this app key. It's not really efficient. We found another way to be sure what they are linked to, and this way is to leak some Laravel ciphers on public projects. The way Laravel works, in fact, is that cookies are Laravel ciphers by default. So if you get some Laravel cookies from public applications, you can try to brute force the cipher you get. And as we saw, we had 260,000 app keys, so we just needed ciphers. So what we did is that we tried to browse on Shodan, which is a platform indexing the internet and getting information about publicly exposed IPs. And so by default Laravel will kindly send you cookies which have Laravel ciphers. So we just made a little Shodan research and we leaked 600k valid CSRF tokens. And so we could just get 600 Laravel ciphers this way from as much public projects as that. It was quite easy to do, but I don't think there were really other research basing their statistics or doing this kind of stuff on Laravel. Mackenzie Jackson: Super, super interesting. And you guys actually built an open-source tool that I think researchers, as you said, researchers haven't really done this, but now that you've actually built something that I think it's going to help the community kind of expand on this, I guess. And so you built Laravel CryptoKiller. So can you explain kind of what this tool did and how, how it's going to kind of help there, I guess, in the future, or help you to do more research? Rémy Matas: So we built a tool, yeah, Laravel CryptoKiller, as you said, which allows you to cipher data when you have a Laravel key, to decrypt it if you, if you found a Laravel cipher in any way. But also there is another mode on this tool, which is brute force mode, and in fact, you just put a list of app keys and it will try to brute force each value on your cipher. Mackenzie Jackson: Do you have any advice then for people that are building and maintaining Laravel applications? Rémy Matas: By default on Laravel, when you are creating your project and starting to work on, there won't be any default app keys. So by default you are secure, in fact, because what is an app key? It's 32 long bytes randomly generated. So good luck to try to crack that. I mean, you can optimize as much as you want with Rust or anything else. You won't be able to brute force it in a lifetime, because it's based on AES-256 in CBC mode, which is a secured algorithm. So good luck with that. So by default, in fact, we are secured. What we identified when we did our research is that people tend to reuse the same app key everywhere. So imagine you are using it on a development environment. You might be able to leak it, because it's less secured in many ways. Also, we identified that on public projects like Snipe-IT, Invoice Ninja, Crater, which were the three projects we identified, they had default app keys, which led us to identify ways to get remote command execution in an unauthenticated way on any of these platforms, because they had some default app keys and they were using the default decrypt from Laravel. And also when you sell products which are based on Laravel, which you know, you want that the project works fine. And in many cases, sorry, they did not rebuild a new app key. So there are many, many codecanyon applications, which is a selling base, which is quite famous. And yes, most of the time they don't really rebuild a new app key on their projects when they're selling. So that's the most common ways to leak your app key when you are doing public stuff or selling stuff, distribute it by default where you get your application. Mackenzie Jackson: Well, Rémy, I want to thank you so much for coming. Now, I do want to mention here that you're actually going and you're doing a presentation at Nullcon. And I want to just to maybe give a quick shout out to what your presentation and your research is actually going to be about, and if people are in Berlin, if they should head there. So, what are you presenting at Nullcon? Rémy Matas: So yeah, we saw that in most cases you won't be affected when an app key leaks. We still digged in other projects what we could do when you have your hands on app keys. And so we identified a way to get remote command execution when you are using Livewire inside your Laravel projects. You can see us during Nullcon. So it's the first week of September in Berlin. So see you there if you like. Mackenzie Jackson: Perfect. Well, thanks so much, Remy. And hopefully I'll be able to get to Berlin to Nullcon. And if so, I'll definitely be in the front row. So, thanks again for joining the show. We really appreciate it. Rémy Matas: Yeah, thanks to you for having me during the show. Mackenzie Jackson: And now, of course, it's time for my favorite part of the show, where I get to sit down with a security leader and drink sake and ask some questions. Today's one's really interesting. We brought onto the show Walt DeBond, who is actually one of the founders of Allseek, which is a company that's exploring AI pentesting, and it's really cutting edge, but it's going to ruffle a lot of feathers. I'm going to say pretty much wholeheartedly that this is going to light up the comment section a bit of people disagreeing, but it's really interesting to see where we're heading in this section. So, without further ado, let's go down to me drinking some sake with Walt DeBond. All right, so welcome, Walt. I'm so glad to have you here. We're going to enjoy some sake. We're going to talk about security. It's going to be a great time. So, first we have our first sake. So, this is non-alcoholic sake, which I didn't know existed until yesterday. And this is from the Nada region in Japan, which apparently is famous for its full-bodied richness. So, interesting fun fact. Walt DeBond: Give it a go. Mackenzie Jackson: All right. Walt DeBond: Cheers. Mackenzie Jackson: Cheers. Oh, this is good. Walt DeBond: I'm quite surprised. Mackenzie Jackson: Like, I didn't know what to expect, but this is actually really good. Walt DeBond: Yeah. Mackenzie Jackson: Yeah. So let's start off. So you obviously have a long history in security, in particular kind of pentesting, offensive security. But how did you, how did you actually get started in security itself? What got you curious about it? Walt DeBond: Yeah, I think it's a bit like the, the, the bit more classical story of like the hacker starting as a child. So I think as a child I was always like busy with computers. There was something that really interested me and especially like I had a Wii and I was really like focused on trying to do things with the Wii that I normally shouldn't be able to do. But you need to know like at my parents' place, the Wii was like three stories up. The computer that we had was like down, and we couldn't really go back and forth. So I was like constantly, like the whole afternoon, just looking something up on the computer, running up to the Wii, trying it out, it didn't work, go back down, Googling again. So I did this way like as a child, I could keep myself busy forever. Mackenzie Jackson: So you were, you were fit. Walt DeBond: I was fit just going back and forth all the time. Mackenzie Jackson: Sure. How did you get into, into actual pentesting and to like understand how you got into security, but how did you go into the offensive side? Walt DeBond: So yeah, as I was always busy with it as a child, it was like always this idea of I want to become a hacker. And so it's been always like in the back of my mind. And then when I went to university, like at the end, I had to think like, okay, what do I want to do as a job? And that thought came back to me like from the get-go, like I want to become a hacker. So I was like really researching like, how do I get into this field? How do I do this? And this is actually how then I got into contact with EY in the Netherlands, and they wanted to offer me like a job to start and learn there as a professional pentester. So I moved everything ahead, went to the Netherlands, lived there for two years, and then this is how I got into my first role as a pentester. Mackenzie Jackson: Yeah, it's fascinating. It's one of the few good stories I've heard from like kind of going into EY. Not that, not that I want to make any enemies with EY. So one of the areas why I really wanted to bring you here today is the work that you've been doing in building out a startup in AI pentesting. So conducting offensive pentests but using AI, I guess, as software. So how does that work? Let's start there. Like how does an AI pentest start and happen? Walt DeBond: Yeah, an AI pentest actually starts very much the same way as a regular hacker would work. So especially now with the rise of agentic AI, you can make like these very separate agents which each specialize in one specific task, and each specific task is a task that a regular pentester would normally do. For example, map out the whole infrastructure, see all the endpoints. So that agent has like their own task and then it would move that task once it finished to another agent who has done like the next thing, for example, try to find some injection points, for example. And this way you have like a whole network of agents who collaborate together in order to mimic the process of a real hacker on an application or an infrastructure. Mackenzie Jackson: So these agents are kind of like, you kind of have a team. Walt DeBond: A team of hackers. Mackenzie Jackson: And an agent is, and you kind of almost as if it is like with real pentesting, you have people that have specializations. Walt DeBond: Yep. Mackenzie Jackson: So these agents have specializations in specific vulnerabilities that they're trying to find. Right. Walt DeBond: Exactly. Mackenzie Jackson: So, so one question I have at the moment that I know is going to light up the comment section, but we've been talking about these AI style pentests kind of producing it as like a software service. Will this replace human pentesters? And if so, why or why not? But will it completely replace it? Will it partially replace it? What will happen in the future? You know, I kind of want to say like 10 years, but I think even just 5 years in AI world is kind of a lifetime. So, in 5 years time, are we still doing human pentests? Walt DeBond: Good one. It's one that I've also been thinking about a lot recently because everything is going so fast, like where will we be in the next years? And I think where we will land is that pentesting will be almost like 95 to 98% done through AI, because everything we do as a hacker is a lot of repetitive tasks that can be completely automated. Even the more creative tasks can be automated, and for most of the companies, that will already be sufficient to get their pentest checkbox marked and have the full value of a pentest. I think like the one or two percent of us still left is for the companies who actually need that a little bit more, that have like a low risk appetite. For example, banks, they don't, they probably will always want that extra little bit more. So I think for them, humans will still come into the loop, especially to test the more creative bugs that are tougher to automate with AI. Mackenzie Jackson: So you mentioned creativity. So I want to ask you a question about creativity, because you know, at some point all of the vulnerabilities that we know about, IDOR, cross-site scripting, SQL injection, they were all invented, well, not invented, but discovered by humans. So are we going to have blind spots? Like you're training these agentic agents on specific tasks, but those tasks were all discovered, found by humans. So will we have blind spots? Walt DeBond: That's a very good question, actually, because indeed, there might be a blind spot somewhere. But if we look at what the industry right now looks like, almost all different kinds of vulnerabilities are already identified. So it will, I don't think AI will invent new categories of vulnerabilities. But even nowadays, with humans, a new category of vulnerability is almost never found again. Now, with LLMs, there is a new category, like prompt injection, for example, but that's as the technology progresses. But yeah, so I think the blind spots itself will be very, very limited, just because humans are very slow on finding new vulnerability types as well. Mackenzie Jackson: How do you train these agentic agents then, right? What, like what's the process? You know, like is it, I know we're not, but I'm going to say it facetiously, are we sending out just OpenAI, look for cross, you know, like how, how are we training these models? Walt DeBond: Well, I think like, if you say training these models, we need to be a bit careful, because we are not in the traditional way of training models, of our machine learning models. We will not be providing them like a huge test set, provide them like ones that we know already labeled like this is good, and then we will have another test set to say, okay, this is like how does it respond now on what we know. That's not really how we're going to work with LLMs. So what we basically do is with each of these agents, we're going to provide them a specific prompt that says like step by step what they need to check. For example, for a path traversal, we can say, okay, if you find this kind of pattern, go and try this, this, this, this, and this. And if you've come across this kind of protection, then you need to try this. So this is like the step-by-step approach that a hacker would take in order to go through it fully. And this needs to be optimized. And the tough thing is not necessarily creating the prompts. The tough thing about these agentic systems is actually like getting it to be consistent. And in order to be consistent, you need like a huge benchmark to see, okay, with this small change in the prompt, am I still getting the same results or not? And that's something that we're seeing as well, like just a small change that for us feels like it shouldn't matter has a huge effect on the results on the benchmark. So, agentic systems is like almost more the benchmark that needs to be like very, very, very good before you, like, that needs to be better than the agentic system itself just to make sure you've got consistent results all the time. Mackenzie Jackson: Yeah, I feel like I'm grilling you here because I'm really interested and I really, I'm like fascinated by this whole system. So, don't take this negatively. But when you, when you talk about it through like the step-by-step processes that an attacker would take and we're getting agentic models to do that, I understand that. But isn't that the same as kind of traditional DAST type scanning or API scanning where we have a step-by-step payload that we discover API endpoints, we send a step-by-step payload to it, look at the, look at the results. How is that different than what you're describing with agentic models? Walt DeBond: Yeah, so first of all, like the DAST and stuff, I'm not really a big fan of it. Like in my opinion, it, it, every time when I came across it, it was so bad at finding things, because it just sends something. It looks at the response if it has like a certain pattern it expects and then it just stops there. And while with agentic system, what it will do is it will inject something, see how the response and then based on that, it will make assumptions. Okay, it looks like there's URL encoding active. Maybe I should try this payload. Okay, now I see it reacts in this way. We're already a step closer. Let's alter the payload a little bit more again to see, okay, this comes in. Got it. And this way, an agentic system is a lot more accurate. Because it doesn't just have like this pattern. It actually sees the context of what is going around it and it just doesn't alert on all these false positives. And in my opinion, DAST is, has so many false positives. Mackenzie Jackson: I feel like I feel like I'm bringing up some problems. I get it now. And that makes so much sense, because it's kind of like saying, here's the, here's the response or here's the error message, and we can go, oh, like, let's be creative. We're not just sending a payload going, "Oh, that didn't give us a token or that didn't give us access or, you know, so move on to the next thing." We actually go, "Oh, it didn't give us a token, but it did give us this syntax error, which may indicate that actually there's something deeper going on." Walt DeBond: Exactly. Mackenzie Jackson: Down below. Walt DeBond: Yeah, especially the context, like that, that's the huge things that these LLMs bring to the table and like the context that they can interpret and react based on that. It's huge, and it's really what's enabling this new kind of field in cybersecurity. I shouldn't forget to drink. Mackenzie Jackson: We have a, we have a different type of sake now. So, this one's from Kyoto in Japan. Again, also non-alcoholic. I'm not sure what the differences are, but we're going to see if we can tell. So, cheers to the next one. Cheers. Still good. No, very similar. Walt DeBond: Here, I was already thinking like, I prefer the last one better. Mackenzie Jackson: Okay, look, the first episode, my sake palette isn't developed yet. I can't tell the distinct notes between different sakes. All right. Walt DeBond: Nice. Mackenzie Jackson: All right. Okay. I want to flip, I want to flip it up right now, because we talked about AI for defense, AI for like pentesting areas like that. Wouldn't this also create the exact equal effect on the opposite side? So like, are we seeing, you know, there's a term script kiddies. It's someone that's like not a sophisticated hacker but is able to run, you know, bash commands from Google or use hacking tools to get in access into stuff, aka me. You know, are we seeing the next generation of script kiddies be able to use these kind of AI agents for evil and what, what's that going to, that dynamic going to look like in your opinion? Walt DeBond: Yeah, definitely, like, in general, if these AI agents get mass adoption and it's available for everyone, it's definitely going to bring a huge shift on how script kiddies, what they are capable of. Like, they don't, like, imagine like as a script kiddie, in the beginning, you can run a tool like Nmap and you're like, oh my god, I'm hacking. Let alone the feeling of this system is hacking for me and doing the actual hacking. I think this, there will be a huge uprise in like the amount of hacks that will come up, but also like this will change. Like, if they have access to these kind of system, that means that all the companies can also have access to these kind of systems. So I think it will again be like this cat and mouse game that will keep on developing. Like, this field might then make that, like, this catches up, but the defense will also catch up quick. Like, I don't think it will be a huge imbalance for long. Mackenzie Jackson: You mentioned Nmap, right? You described my first experience Nmap, like, oh my God, I'm a hacker, where's my hoodie? Walt DeBond: I found a port. Oh my God. Mackenzie Jackson: Yeah. What is a port? Port, hey, how do I hack? So, I have a game that I want to do today. It's called Would You Rather, and it's pretty self-explanatory. I'm going to give you two options, and you're going to pick which of those options you would prefer to do. Now, I'm going to refill our sake, because we need motivation for this next game here. Walt DeBond: Perfect. Mackenzie Jackson: This is just in case you're wondering, this is the same one as last time in case you're curious. Walt DeBond: Busted. Mackenzie Jackson: All right. Okay. Would you rather have all your credentials stored in a .env file in your Git repository or never be able to update your dependencies? Walt DeBond: Definitely the first. Mackenzie Jackson: The first? Walt DeBond: The, the, the environment variables there, like, because yeah, if, if I, if I can't update my dependencies then, yeah, if I have a web application running outside then, yeah, I'm just anyway. Mackenzie Jackson: Okay. I, you know what? I would have thought I would have thought environment variables, but I, but I understand, but I understand it. Walt DeBond: It's yeah, like, as long as it's in a Git repository, there is like still a line of defense, kind of, if it's private. Mackenzie Jackson: But I mean, that's number one, that's the first thing your agentic models are going to be trying to do, is is there exposed .git directory somewhere there? Walt DeBond: Exactly. Yeah, but like if I have to choose one. Mackenzie Jackson: Okay. Yeah. Walt DeBond: Is like definitely update your dependencies. Oh my God. Mackenzie Jackson: Would you rather have no MFA on your internal infrastructure or no firewall? Walt DeBond: I, I think the no firewall, again, for the same reason as the env files. Because like, you can't hack what you can't reach. If I wouldn't have a firewall and all my data would just be like, all my ports would be open to the internet. Yeah. Mackenzie Jackson: Yeah. No, definitely no firewall. Walt DeBond: No firewall. All right. Mackenzie Jackson: Would you rather have no security scanning in your application or only be able to deploy to production, no staging environment? Walt DeBond: I've got them. Mackenzie Jackson: I've got them on this one. The other ones were easy. The other ones were easy, but this one you're stumped on. Walt DeBond: Yeah, like I'm, I'm thinking like, as, yeah, I wouldn't want my production environment to be down, but I also don't want to be it to be vulnerable. And I think, yeah, risk-wise, I would choose for like no staging. Mackenzie Jackson: No staging and no security scanning. Walt DeBond: Like if, yeah, I, I would like security scanning, but like a good one. If like, if, if it's like just a general low-budget scanning, then no, thank you. But like if I would have like proper scanning on there, I think I would take the risk of no staging. Mackenzie Jackson: I feel like I feel like this is like the perfect segue to talk about the sponsor of this, on this, which is, which is security scanning, which is better than, than not having a staging environment. Walt DeBond: Exactly. Mackenzie Jackson: All right. Well, I want to thank you so much for coming on the show, drinking sake with me. I enjoyed it. 0% sake. Surprisingly good. Surprisingly, surprisingly fire. Walt DeBond: You should get them as a sponsor next time. Mackenzie Jackson: I should get them as a sponsor next time. I don't even know, I don't even know what, what, what one is called, but we'll figure it out. But until next time, I'll see you. Walt DeBond: See you next time. Mackenzie Jackson: I hope you enjoyed that episode today. We're trying to bring you high quality, engaging content here at The Secure Disclosure show. So, please like this video, subscribe to the channel. It helps us more than you know. And if you're feeling like it, also tell a friend about us. We'd really appreciate it. Well, I hope to see you on the next episode next week. And until then, have a great day and stay secure.
