← Cybersecurity Today
Cybersecurity Today
From CVE To Cyber Attack In Minutes With AI: Cybersecurity Today
00:31:51
The Future of Cybersecurity: AI, Exploits, and the CVE Database In this special crossover episode of Cybersecurity Today and Hashtag Trending, the hosts explore the use of artificial intelligence (AI) in cybersecurity. The conversation begins with an...
Loading summary
Transcript57 lines
- [00:01]
A
Welcome to this crossover show of cybersecurity today and trending. Occasionally I get shows that I think are of interest to both audiences. Most of us have been thinking about artificial intelligence and how it's being used in programming and of course in cybersecurity. We know that it's being used by both the good guys and the bad guys. If you're in it, or especially if you follow cybersecurity today, you are aware of what I've described as the arms race in cyber threats. The bad guys are constantly on the watch for software vulnerabilities they can exploit. The good guys are continually trying to find these vulnerabilities before the bad guys can exploit them. Companies are constantly looking for issues in their code. They provide a lot of incentives for others to help find them in terms of bug bounties and other programs. But occasionally they find out about a vulnerability only because somebody exploits it. These are the so called zero day exploits where the vulnerability is not known to the developer or the vendor until the exploit has happened. Everyone's constantly on the look for these vulnerabilities and nobody, developer or vendor wants a zero day attack on their customers or their systems. Developers and vendors are constantly looking for vulnerabilities and if they find them, they need to evaluate them and prioritize them for patching or remediation. Some vulnerabilities are real, but they're not likely to be exploited or not easily exploited. And even if they were, some can't do a lot of damage. On the other end of the continuum, there are those that are easily exploited or where the consequences of an exploit are severe. But finding them and patching them is not enough. You need to make the industry aware of these vulnerabilities so that all users of the software will patch it, upgrade it, or remediate the issues. At one time this process was ad hoc, managed by individual companies for the most part. But today we have a centralized repository used by virtually all vendors and developers. It's called the Common Vulnerability and Exposures Database. Now the CVE database provides a standardized, publicly accessible catalog of cybersecurity vulnerabilities and exposures. It also provides a scale for the measurement of the risk, impact or severity of the vulnerability. And it provides a single common identifier. It's maintained by the nonprofit MITRE Corporation with funding and sponsorship Provided by the U.S. department of Homeland Security and the Cybersecurity and infrastructure security agency CISA. It coordinates the work of more than 100 other organizations. And at one point there was and may still be a worry that the US government might cut off funding as part of the DoGE or other austerity measures. It seems, at least for now, like we may have dodged that bullet. But it's still a huge worry because the database is now essential for organizations to manage a growing list of vulnerabilities. It allows organizations and researchers to identify, reference and share information about specific security flaws using unique identifiers, the CVEs. Once a vulnerability is identified, it takes time to develop a patch or remediation. And once that's available, you want to make that widely known, so that as soon as the vulnerability is published, organizations can patch, upgrade or remediate the problem. But it's not as simple as it sounds. Even once an organization is made aware of a vulnerability, and even when there's an actual patch available, that patching and upgrading can take days, sometimes weeks, depending on the severity of the vulnerability. Systems are complex, teams are overworked, you have to schedule the time to implement and test these. It it can take days, sometimes weeks, months. And in some cases, organizations never upgrade or patch at all. Now fortunately, it takes the bad guys some time to develop their exploits. The CVE might give them some clues, but even if they know the vulnerability, they still have to develop the attack and propagate it in some way. The vast numbers of CVEs offers some kind of insulation. There's about 40,000 of these raised per year, more than 100 a day. As a result, only a small percentage of these CVEs actually have exploits. Even the bad guys have to prioritize their activities as well. So last year there were 768 exploits that were publicly reported. The average time from CVE report to a development and exploit in the wild is approximately 170 days. Even though organizations are relatively slow at patching, they have some time, a buffer. But what if AI turned that on its head? What if you could develop exploits in minutes, automated, with minimal effort, turning those CVEs into exploits before anyone could actually mount a defense? That would be devastating. Well, it's happened. Two Israeli researchers, Effie Weiss and Nachman Kayat, discovered how to do this and built a proof of concept and put a post on LinkedIn. I was able to track them down and bring in Nachman for an interview for this weekend show. My guest is Nachman Kayet. He is the researcher many of you might have heard of. Over the past week he found himself in a position with one of his fellow researchers of developing a way to accelerate the development of exploits. That's the only way I can explain it. Well, I think it blew people away. The average time, if I've got it right, for an exploit logged into the CVE database to be developed is about 192 days on average. Most research says that you've taken that down to 15 minutes or less. That's scary.
- [06:29]
B
It is, it is. We didn't expect such a response. We knew that we did something that is very special because at the end what it showed is that, you know, exploit generation is no longer bottlenecked by human expertise. That's the real meaning behind it. Again, when the vulnerability is getting published, you just know that there is a. That may be exploited, but you don't know how to actually weaponize it, make it an attack. And you have to have special knowledge of an attacker or a vulnerability researcher to be able to make it into a working attack. And you know, it's 190 days for most of the CVs, but the critical ones, it usually takes around four to seven days to create the working inspector. So organization understood it. Yeah. It's not something that is new for them. And they have these controls to patch quickly critical vulnerabilities in their systems and it usually takes a few days. So I would say that we were able to do it in 15 minutes. And it still challenges the core assumption they had, which is like having 24 to 4 days to patch the LCV like 400 times faster to create an expert. Yeah.
- [07:37]
A
And you're not the first people to use AI for this or at least for the analysis of these, of these weaknesses that could cause exploits. I know Google has Big Sleep, which is named after a movie, and Nvidia has Project Morpheus. You don't know who Morpheus is. You're not the sci fi community, you know, but those really would detect vulnerabilities and normally report those. So there is the ability to automatically detect them. But you've taken that a step further and said we can turn that into an exploit.
- [08:11]
B
Yeah.
- [08:11]
A
Using AI.
- [08:14]
B
I wonder how BigSleep is structured. Like, they are able to find vulnerabilities, but the challenge after finding vulnerabilities is to validate their actions.
- [08:23]
A
Vulnerabilities, well, that's going to be one of the first things that we'll talk about the positives of what you've done, because right now you're scaring the pants off people. But the positives are that just because you see a section of code and you say we think there's a vulnerability in there, doesn't mean that there really is one that exists or you could exploit it.
- [08:41]
B
Exactly.
- [08:41]
A
So first of all, why did you do this and what was the idea behind it?
- [08:48]
B
We have been researching AI changes fundamental assumptions in cybersecurity for a while and you see that it changes every field, even email security, AI generated attacks and AI email assistant attacks that you see. You see all these different vulnerabilities in sites like lovable. We also did a small research around that, found many issues there too. It changes every aspect. We thought about how it impacts vulnerability research in general, which is if you are able to do something disruptive, there is. It will be really interesting for the community. And when we realized that it's. It's pretty easy, we became a bit scared because we thought that, you know, I don't think I. We don't feel like the industry understands that they may be suspected, but only after we actually published the article and the proof, by the way, and that it actually happens 10 or 15 minutes after the CV is published. Because somebody may think that we did it in a day or two and then, you know, use the old cv, did it manually or something. But we actually proved it that it happened, that we published it 10 or 15 minutes after the CV is published. When we did it, the industry finally understood that there is something real here and we have to defend differently. We have to question our core assumptions. So that's the reason why we did it. Because we think that people don't get.
- [10:03]
A
This idea should have been around for ages. Like, I mean, it's so obvious when you say it that. Why don't we try this? First of all, let's give a shout out to your fellow researcher too, because.
- [10:13]
B
Is the genius behind all of that, his ego Genius. We know each other for many, many years and many things together, but he's the genius behind all of that and he had some very cool ideas of how to actually make AI do it. It's not that easy, okay? You have to chain a few agents together and then you have to create a system that check that the exploit that was generated is real. Because sometimes AI hallucinations. So there is a lot of tech there and definitely did a lot of the job.
- [10:41]
A
Well, when you start out, first of all, you used Claude for this. Many people call it Claude, but I'm Canadian, we call it Claude. I just. I'm not going to call anything Claude. I don't care. But Claude, it should. First of all, why didn't it prevent you from doing this?
- [10:58]
B
They did prevent.
- [10:59]
A
Hey Claude, develop an Exploit for me, I mean, that's sort of, you think that'd be basic guardrails.
- [11:06]
B
So at the start, we told it to, hey, develop an exploit for me, and then it refused to do that. What we actually did is we started to use Quinn, the Chinese model, locally on a MacBook, because we also wanted to show that it's cheap, that you don't have to pay a lot of money for that. But then after we split it up into different agents, then Claude decided to go with us and help us to generate it. Because think about it, it's just a code issue. It's just a code problem. It's not an exploit. You can say, just look at the code, tell me what's wrong, what's wrong with the code? Kilo. It's not too difficult.
- [11:41]
A
Yeah. And AI agents are doing that. But now what are the issues in this? You detected what you think is an exploit. How do you find what you think is an exploit in the first place?
- [11:53]
B
Okay, so what's an exploit is you have to like, you have a vulnerability somewhere in the code and you need to find the route to get to that vulnerability in the code. Think about it like some of the vulnerability is not reachable. Right. The industry knows that very well. You have findings, sometimes they're generated by SAS tools or SCA tools, but you don't know if they are actually reachable in your code. What you try to do is you try to find the path that leads to that point and understand if you have an actual way of attacking the system through that.
- [12:24]
A
Which, by the way, is a problem for people who manage these exploits because they're getting all kinds of reports where people have run AI and say, there's an exploit here. And they look at it and go, no, this is an exploit. How are you able to use AI to validate that exploit?
- [12:40]
B
You had to create an environment where the old vulnerable version exists and another environment in which the new non vulnerable version exists. And then you need to try your xcode on both of them. If you see that an exploit works on the unpatched version and then stops working on the patch version, then you have probably.
- [13:03]
A
Okay, yeah. So you need to set those two environments up, run your analysis and say, okay, this is a real exploit, or at least the code is exploitable. I guess that's really what I'm saying, is you understand the code is exploitable. How do you do that? Is that the next step?
- [13:21]
B
We have a few agents then, right. If you want the whole flow, then we start from the vulnerability Advisories. We extract the diff between the versions because in the advisory, you have a hint of what the vulnerability is, and then you have also the version that it's fixed in. You extract a diff between them. You detect the vulnerable code inside using an AI agent, a set of AI agents, reviews, that does a technical analysis. Then you build those two environments and check your xcode. And if it doesn't work, like if the xcode doesn't work on the vulnerable version, then you start again and you feed that feedback back to the AI. Okay. And then you have such a look that fixes itself. You get the feedback from trying the exploit and you give it back to the AI. And the AI helps you to generate another option for the exploit until it works. And of course, it's not that easy. You may create this engineering work and make it all work, but at the end you have to teach the AI how to find the vulnerabilities themselves.
- [14:22]
A
Well, that's what I was going to get at. And I wouldn't think that the CVE gives you the ability to understand the vulnerability enough to develop an exploit. I'm sure they're not publishing that, but they're publishing enough information for you to start digging into it. And then you develop first of all the analysis of the exploit and then the exploit. This has caused quite a stir. Why is it so difficult? Why hasn't somebody done this before?
- [14:49]
B
Because in order to, again, you have the hints in the advisory, but you need to guide the AI to find it in the code. And every attack of vulnerability, not every attack of vulnerability, but some, you have, like, classes of vulnerabilities. Those are SQL I injections, SSRF and different types of vulnerabilities. And in order to find them in the code, even if you know the diff, in order to find them in the code itself, you have to know how such vulnerabilities look like. So you have to teach the AI. Look, there are hundreds of examples of this type of vulnerability. This is the way I would think about it as a vulnerability researcher. Now, try to imitate my way and do the same. And if you do that well, you have to have the expertise, you have to know how to do it yourself. So that's the reason why it's difficult. And the second thing is that it's not that easy. You have to chain a lot of agents together because it's too complex for one agent to do. Okay.
- [15:49]
A
Yeah. And that's I'm trying to wrap my mind around is the number of agents that are in there. Can you just give us a bit of the flow of what those different agents are? I mean, just so we can sort of understand what they are and how they work?
- [16:02]
B
Yeah, I'm trying to give more details, but I don't want to give too much details because I'm afraid that, you know, attackers.
- [16:07]
A
I totally understand. Yeah.
- [16:09]
B
Because at the end, the idea wasn't to help the offender industry, the idea was to help people defend against them and raise awareness. But that gives some information. You have one part, which is a set of agents that are doing the data preparation. Those agents responsible for taking the information from the advisory, taking the diff between the versions, the vulnerable version and the patched version, and generate options for the vulnerable code. That's one part of the aegis. The second part is those who are responsible for the context enrichment. We know that in AI, one of the most important things is to create the right context for the agents. And then you have those agents who are responsible for doing a deep technical analysis of these options of vulnerable code. They are writing an exploitation flow. Then they draft an exploitation plan from that flow, like how you would exploit such a thing. We have also a review agent who checks that plan. And that's the second part of agents. And the third one is the evaluation loop. Like that's actually creating Those, putting those half W2 versions, trying the exploit and feeding the feedback back to the context enrichment one to create a better response.
- [17:24]
A
And so you've been able to do this in under 15 minutes. You've been able to prove that is an exploit. How did I read about this in Dark Reading, where a lot of people. Did you just release a paper? How did people find out about the work you were doing?
- [17:39]
B
We also, again, we were very surprised. The response has been really intense. We published it on LinkedIn. We did a, like published a substack article, published it on LinkedIn. We thought that some of the friends and colleagues would respond nicely to that and maybe repost it. But then it just broke out and everybody started to talk about it. We saw it across CISOs, researchers, executives. Their responses were both validation of what we thought is a problem. Like this 15 minutes thing is real. And this is scary because our vulnerability management programs are not built for that.
- [18:13]
A
They're not built to handle what we can do. Today, Microsoft Exchange Vulnerability reported, I guess, a couple weeks ago, we cover these in cybersecurity. Today we report them regularly. Two weeks later, they're still ripping through that code. And that's a relatively contained number. I mean, there's going to be thousands, maybe more worldwide. But a Microsoft Exchange on site implementation, that's a pretty contained environment, that's a limited data set and yet two weeks later it still wasn't patched. I mean there's still finding unpatched exchange and I think this is a big problem because you can always find unpatched stuff. There are exploits that people are finding three years after the patches have been out. So there's plenty of unpatched stuff out there even today.
- [19:00]
B
I think it happens because of the talent shortages. You have this vulnerability growth. You have the same amount of talent that have to handle all of that. And you see all these mediums and lows stay in your organization. You only try to handle the critical ones that you have. But you don't go over all of that. And you have problems in your organization, in the culture, like how people respond to handling vulnerabilities. Is that something that it's like first priority for them or none? I think that's the reasons and we have to do something about it because the wave of attack is coming is the reality for the last few years. But think about it 400 times faster. It's not only the exchange one that was published. And think you'll be able to do that in a very cheap manner. You will be able to generate Experts for all CVEs released like every day.
- [19:44]
A
There are 40,000 of them last year weaknesses, vulnerabilities reported the year on year.
- [19:51]
B
Code of it by the way in 17% it's only getting up. And with AI generated code, I guess it will be much worse.
- [19:58]
A
Yeah, the stats I read were correct. It was that only like 700 or 800 vulnerabilities were actually exploited in that time. That leaves 39,300 other vulnerabilities of which some, and I agree that some of them will be. I mean if they're reported at the CVE level they're pretty. That's not just speculation. Those are real vulnerabilities.
- [20:21]
B
For these vulnerabilities the vulnerabilities exist, but the ROI for creating an expert is not that high. So people do not, you know, again you need this special expertise. But if those capabilities would be published, I don't know if more people will be able to do what I think already is happening in some places. And then yeah, much more of them will be able to weaponize. I like to call it the end day is the new zero day. Okay, the end day. Every cv, even that was published two weeks ago or two months ago or a Year ago, it'd be like a new zero day on your organization.
- [20:53]
A
We're not going to start referring to N days anymore. We're going to start N minutes. This is n minute 8. And for those who are listening to this, you don't understand. Zero days is the date of the detection and reporting of the vulnerability. The end days is what we start to count for, how long it takes to get an exploit together. And we did that in days, you know, and now we could be talking about N minutes. Have you and I just go back to this because it's been. I run a publication now. I was a cio, so I did run it shops. And you know, we do our patch days. And here's the problem you have is patching requires making your systems possibly vulnerable to downtime. So you have to schedule that. You have to do backups because you're not going to post new code and not have a backup that you can restore to. Then you'll apply the patch. Maybe you'll have to test the patch because they don't always work. And so, you know, users or even testing people around to say, we apply this patch, are your systems coming back up? Do they still work? These are all the constraints now. Maybe smarter people, people with more money, maybe, you know, people who could find better ways to do things, could collapse that. But unless you can get to something like virtual patching that you can just apply and see if it works and get rid of it, I don't know how we're going to cope with this.
- [22:21]
B
Yeah, I think two things. First of all, response times must accelerate drastically. Like we have to assume that in a few months, maybe a year, vulnerabilities will be commoditized, you will be able to easily find vulnerabilities into things. And there is a storm coming. In that sense, we have to accelerate our response time. That's the first thing. And the second thing is we must invest more. We need to assume our security strategies, must assure the attackers already have a working expert and what it leads to. If we assume that, that we have to put runtime protections and compensate the controls in our systems, create a more resilient architecture from the beginning. Otherwise I'm not sure how we can handle this wave of change.
- [23:12]
A
Well, one idea that I had, and it just, it makes me sort of crazy thinking about it, is if Google can develop something that can find potential exploits and Nvidia can, why aren't people running that on their code before they release it?
- [23:27]
B
Great question, I think.
- [23:29]
A
Yeah, so what I'm Just saying we may be the only answer may be building code that has fewer exploits.
- [23:38]
B
That's like the solution when you look five or 10 years ahead. But think about all the vulnerabilities that you have now in production and that's like your real problem. Even if I put those controls into my development life cycle, you have Systems running for 10 years, full of mediums and lows and highs that you can exploit easily. Yeah.
- [23:58]
A
What do you think? Have you come up with ideas that the next projects you want to work on in terms of helping address this?
- [24:06]
B
Here we are trying to understand how to create defender tools that use the same techniques as the attackers to auto generate those mitigations and detection rules to close that gap. We're still talking with. We get a lot of responses like people have different ideas. It's really interesting. The industry is full of smart people with great ideas. So some of them talked about like detection rules and mitigations for CVEs and we are looking into that direction and we still think that it will take time for organizations to adapt. So we try to raise awareness that people need to advance the response times, accelerate them as much as they can.
- [24:46]
A
What are your recommendations for people advancing what they're doing? Are there tips or tricks that you could offer that people could apply that might help them be better at mitigating these vulnerabilities?
- [25:00]
B
I think they need to build their architecture more resiliently. And meaning here is to reduce the ways of fail. Even if you exploit one vulnerability in order to get to the crown jewels of your organization, like to the important DB's and stuff like that, you have to find the whole way in. So it's not only just protecting the entry to organization, you need to think the whole way through how you secure everything, how you minimize the attack surface to gate into things in your organization. So what I recommend is when you build software and when you build architecture, especially when it's combined of different parts, think about that. Think about how you reduce the attack surfaces as much as you can. So when you go on to think the vulnerabilities that will be published later, you will need to do less job.
- [25:51]
A
I was thinking about this because I did an interview with the gentleman who's called the godfather of Zero Trust. And as I was preparing for this interview, I was thinking, is there a way to write code so that we could do what you were talking about to say, hey, everybody's going to break into some part of code. Can you segment it in the same way you'd segment a Network so that just because you get here doesn't mean you can get there. And it goes down to this whole idea of. And I think maybe something we don't think about enough is what are we actually protecting? What is the most important thing to protect in code? And I think that's something we don't give enough attention to. We really don't think about. This is. Of all the things we want to protect, this is it. I don't know.
- [26:32]
B
It's interesting to think about it from that perspective. Well, you have the easy answer, which is keep running better code. Yeah, but I don't like that answer because at the end, you have deadlines, you have to go fast. You want to use those coding agents who make your organization go in a much faster velocity. We can't stop that. In order to make our organization more secure, we have to adapt to that change. You can use one thing, which is AI coding agents that help you to write a more secure code. And then if you use those coding agents, it can help you to create a more secure code there. From the beginning. I think that the different solutions in the market for sast, for example, have to do a much better job. Like, they have to find real vulnerabilities and they have to work together with the coding agents as fast as they can, because this may help us to reduce the amount of vulnerabilities coming from the first place. But, yeah, we have a problem in that. And when you say about protecting, what especially we are protecting, and you don't think we are protecting code. We want to protect our data. It depends on the organization. We want to make sure the uptime is high. So I think that we need to think about it again. That's the reason why I go to architecture, because it doesn't matter if you have any vulnerability here or there. You have to make sure that even if you are breached, the attacker can find your critical asset. You have to think that way. That's the reason why you have to think when you deploy your software, you have to think about if an attacker would come and already rent code. In your endpoint, what snow?
- [27:56]
A
Yeah. And I think the aim of that was in terms of how I was expressing it, everybody thinks about uptime. Uptime is big in code. You don't want crashes, you don't want stops. You want uptime. If we apply the same rigor to protecting our assets, mostly data, but other things as well. But if we apply that same rigor as we do to uptime, we might get better code.
- [28:19]
B
I talk with Practitioners and some of them say to me that they try to use this continuous penetration testing, the new continuous penetration testing solutions, to convince their organization that what the findings that they find are important. They used Horizon 3, for example, to attack the organization, but not to actually find something, but to convince. Like show to decision makers, look, this issue is important. So that's one way of addressing the issue. Like for example, always finding new problems in your system, new ways of attacking it. And that way raise awareness.
- [28:54]
A
But. So you're a little overwhelmed by the attention that this has brought. What's your favorite interview that you've done so far? What was fun about this?
- [29:02]
B
I really liked the whole attention, but I really like that we found something that actually interests people and we had some other ideas of things we can do. And I really like the. I had one interview in Israel in Hebrew and they tried to ask us like why we are doing it. Okay, why we did it. And the true answer is that it was just really interesting. Like check what we can do with AI.
- [29:25]
A
So what are you up to next? What are you going to do next? It's just us and a few thousand, another 10,000 people.
- [29:34]
B
So again we keep exploring whether AI can adapt to zero day style challenges too. Like not having the advisory itself to try to exploit the vulnerabilities. We want to keep trying to use those generated endpoints to find maybe new vulnerabilities, which is also another assumption that we may break if we'll be able to do that. But the main effort now is investigating how we can create Defender tools, how we can maybe release something open source and tell the industry to protect against such things. I also want to mention that we didn't publish the whole idea behind it. Like when you read the article, you believe that it's possible, you see the proof, but you can't reproduce it easily. And I think that it buys us a lot of time and you still have to be an expert to be able to do that. But once you can do it, it becomes really easy and cheap, buys us some time.
- [30:26]
A
There's a lot of smart people out there who are trying to figure out how you did this. At this point, I just want to take another. Just to make sure we give a shout out to your research partners. It was Effie, I can't remember his last name. Effie Weiss and Nakamon Kayat. Thank you so much for sharing this with the world. Hopefully we'll get you back in the program when you work out the solutions to this. A lot of people will be interested to hear about those as well.
- [30:51]
B
Sure. Thank you. Thank you for having thanks.
- [30:54]
A
And that's our show for this weekend. Thanks for joining us. Just a note, if you're getting this on an Alexa or Google smart speaker and you're experiencing some interruptions, dreadfully sorry. But our tech guys are working like mad. And in fairness, Google has been very supportive. It's next to impossible to find a person at Amazon, but we're chasing it and trying to get it resolved. It's one of those things that works and then doesn't. The hardest type of bug to chase and fix. We will get it fixed and I understand it's part of many people's morning routine. But until that time, you can find us on Amazon every major podcast platform. I'll be back Monday morning with the tech news on hashtag trending. David Shipley will be on the news desk on Monday morning for Cybersecurity Today. Thanks for listening and have a wonderful weekend.