From Description to Exploit AI Agents for Smarter Audits

Transcript

Hi everyone. Uh welcome to the AI session. Thank you all for coming. I'm Leor. I'll be chairing this session and uh let's begin at the beginning. So without further ado, I'll present you the first speaker uh Sophia Bobilo, a PhD student at KTH and Sophia will tell us about how to use AI to generate PC's from description. Hi everyone. Thank you so much for coming here on this morning. Thank you for the intro as well. Um to check that you're in the right m right room. The talk is from description to exploit a just for smart ter audits. And I'm Sophia. I'm in the second year of my

PhD and I'm part of the research group that we call ourselves assert for awesome software research engineering team. [snorts] We are four around. So if you see more people like this, you know it's one of us. Um and yes, so you know I'm a PhD student and I have to give these talks a lot in academia and always starts with like why smart contracts are so important, why the security is so critical. But there wouldn't be a defy security summit if it wasn't a huge problem, right? So I can skip that part. So let me just uh set the stage into our conception of the software development of a secure smart contract protocol.

Right? as as in any software you start by thinking about okay I want to do something and I need to design and model how I want it to work and then you give it into development team to actually write the code and ideally they will test it [laughter] they will think about this uh security issues as well and once they have a stable version right uh particularly in the in the blockchain space we do security audits which are extremely relevant because if you deploy the code right it's not being able to modify afterwards and then a vulnerability can be extremely harmful.

So in this process of a security audit you usually not usually you rely on a external third party service which is extremely important because you want someone with a new perspective to look into your code and to find new scenarios in which you can be attack. Yet this process h can be a bit of a bottleneck for your service to end up being monitored which is the step in which you deploy the code and then you look into uh the transactions that are going and if something funk it's happening like an attack. The problem is is that between step and two if something sleeps on you get wrecked you get wrecked and probably everyone gets wrecked because everything we're using on the blockchain has been audited by someone that probably is in

this conference. So it's extremely important. [laughter and gasps] So as I mentioned these audits are essential like extremely important. I I I hope by what I'm saying here you don't take it that I'm saying that we don't need it. We do need it but they are represent a little bit of a bottleneck because there is only so much budget you can put into your audit and there is only so much time that you can put into it. So the idea is how we can make audits the most efficient way so no nothing will slip through deployed code. And so there are some areas for improvement in here. Uh we have seen a a huge amount of AI agents coming which the idea is to um automate the detection of vulnerabilities. There are also

overall improvements into vulnerability descriptions, right? So how a vulnerability works and relates but still natural language code. And the last one that is the one that evolves in this talk is proof of concept exploits. And here for example I I put the guidelines from Immunifi into how if you want to submit a report with a proof concept you should do it for web three which is still a bit different from from web two and uh today I will I will show you our I would like to call it our humble solution. So we thought okay we are using AI for generating software right and uh while vulnerability detection is still a problem itself we thought we

thought we needed to separate them because the the the way you will identify a vulnerability it's a problem so complicated that if you include the generation of a proof concept that you're missing two very hard research areas. So we created Poco which is an identic way to generate proof of concept exploits for smart contracts. And here I put my collaborators. So BB Anderson is a PhD student on machine learning for security and Harald is a master's student in our group as well and Martin is my supervisor.

So what's the idea of Poco? So as I said we don't do detection and I want to make it very clear. We rely on a vulnerability annotation made by a auditor already. So they write this description. I think I believe I found a vulnerability here and I believe this is the state it can be exploited and this is how you can verify it. And then it gives us also the smart contract project in which h the vulnerability exist. And then Poco as I mentioned is an agentic solution. So it has a react loop which basically means poco works autonomous autonomously with certain commands and then it decides what to do afterwards and we give a guidelines of how it should do it and what should be the expected output. So for example, Poco

here will immediately read the codebase, try to understand what are the dependencies of the contract and then once it finish reading the codebase, it will write a P that then it has a tool to compile the P and then to test and then if the test passes which we call it like all the assertions passes, it will output the PC exploit. But again we are not also assuming that it will be correct by default. So of course we always encourage auditors to don't trust to verify. So our idea is that the output of Poco will be verified by an auditor that will later will submit great reports. It will get great money and then the developers of the receiver team will be super happy. So the whole

idea of our work is that if we have better proof of concepts, we have happier auditors because they will know that they found a problem and they don't have to spend all this time that is taken to write the test because they know they already found a vulnerability. And with that we also have better code fixes because a a P it's a extremely powerful tool for the developer team to check that they are mitigating the exploit correctly. So a little bit on the architecture. So an identic framework means that you give AI access to certain tools. And here you have to be super careful. If you if you read the details on the paper, we explain what are the security measures you need to take. So for example, Poco

runs in a sandboxes environment where it won't have access to your secrets and so on. And it will it will give a set set list of tools that it can utilize. And here we have like three categories. So like the basics tools which are for codebased exploration, how to find the contracts, how to um how to find functions and so on, how to write and how to read and then planning tools which is internal of the tool to decide what steps to do next and what steps needs to be done in order to achieve the goal which is to create a proof of concept exploit that have test assertions that are delivered from the natural language description. And then the tools that we include at smart contract tools which are smart contract

compile and smart contract test. And just to be very concrete we are generating foundry test for this. And uh you see here at the bottom the task prom is create a vulnerability a vulnerability exposing proof of concept in forge h for the vulnerable contract at this bar at this path using the vulnerability description in two. So we never let the AI decide what's the problem. We ask them to follow the h annotations of the auditor and uh again we like being very concrete. So this is how poco works. You say uv run poco and then you call the the you give it the rp which is the rec path

and that's the smart contract with the problem and a is your annotation in a txt file and then you can choose the model. So we are we are mostly proposing the architecture to do it more that bounding ourselves to one model. So the agent architecture we created you can use it with different models according to whatever you want to uh use. [snorts] And uh yes so I tried to add a gift on the demo. I was a bit worried on the internet. So that's why it's a gift. So basically you will give the parameters to Poco and it will start by uh reading the contract. It will try to analyze if you saw maybe too fast. It went to a globe to find more about it. And now it's now let me check this other test

and it keeps operating. Now let me see how repayment works. And then it will eventually h say I already read what I need to and now let me write the test and it will execute it and then the expected pattern is forge compile for this and that it will only stop when foret actually passes. Let me see if the gif is working correctly. Yes. So then it writes and then it will test it. NCP, solidity, foundry, forge, compile and then test and so on. So okay, we say we love creating tools but we love creating tools that we can actually verify right.

So we are researchers and uh we will never blindly trust a process. I want to see okay you created this tool but then tell me how did you validate it? So for PC's there are we will say like two dimensions you always start with the basic quality right so what will be the basic quality for a P it compiles it contains assertions it's AI hallucinates so it's something that one should always verify it if you are waiting for a P it has to make sure that has any assert in between and does the assertion pass so that means we do forge compile and then we do forge test and then we do a grip on the code to check that there are assertions on And then the second which is the most

hard which is how do I evaluate the correctness of a proof of concept exploit right and of course here uh one can do manual validation but then the results will be tied to the experience of the authors which I would say is pretty fair but uh we really love having this h elegant oracles to validate it. So we said okay but what if we use the ground truth patch. So how does it work? uh previously we did um evaluation of code fixes um for smart contracts. So we say okay if I want to generate a automated code fix for a smart a piece of code on smart contracts I don't only want to know that it's still functional

I want to know that it mitigates the vulnerability that it originally had right but the problem was when we did that first paper la last year is that we can only have so many exploits for a patch right so maybe my patch was mitigating a few exploits but we still were a bit unsure of if it can stop all of them but now if you to the other way, right? I know there is a patch. I know that the patch has been accepted and the code has been deployed. So they they really took care of the vulnerability.

So if I have an exploit and I want to prove that the exploit is correct, if it's stopped by using the patch, then I know it's correct automatically. So that's how that's how we did the evaluation. So first we evaluate if it was wellformed, right? executable contains assertion and the assertions pass and then for correctness we execute the exploit but on the patch codebase and then if the exploit fails then we know that it's correct because the patch was accepted and it should stop all possible exploits and it gives us a stronger assumption. So in order to evaluate we created that data set called proof of patch when we go into vulnerability reports that have a hint

of the solution by for example a link to a PR a link to a commit and then we manually look into it and then we abstract the the patch from it. So I'm going to lie two months ago I was deep dive looking into code forina sherlock reports looking for this particularly so vulnerability reports that have a description ideally an impact and that I can find that somewhere in there they wrote this is the pull request that we utilize to uh address this vulnerability report and some of them of course will contain a proof concept that uh this is a a pre-tier one that we that we But not everything in our data set has it. But this is the the outcome that we

wanted to have. A proof of concept that sets the state of exploitation and then explains what's the test to do. And ultimately has an assertion that tells me this is how I prove that the proof of concept actually this is how I prove that the vulnerability actually exist. Yes. So here I put a a example of a proof concept generated by Poco. So it's it's quite verbose in the way that it um it summarizes the description of the auditor and then we have contract exploit is fixure in in this particular case it was a a private pool um that they wanted to demonstrate that you could get a flash loan with a very very

low fee that was incorrect according to the documentation. So uh you have the setup function that allows you to set the exploitation state and then the most important test where the test flash loan incorrectly scale and then it gives the steps of uh this is how the borrower only pay 25 way instead of 0.0025 and there was another economic impact of the vulnerability to be even stronger you really need to take care of this. So [laughter] we uh collect the results right across our data set and due to time we managed to get 23 of them and if you see that

they have these ids is because we did a overall scrapper of solid solid and we enumerate the the contracts and then we manually went through all of them. So we only managed to look in the first best 100 that we did according to some priorization. You can see the details on the paper. Uh [snorts] but from those we only got 23 and uh if you see on the first part of the table we have how many of them were well formed which meant again contains assertions compiles and the assertions pass and then how many of them were correct which means when we run them against the patch vulnerable code uh with the patch base h the exploit will stop and here the champion

sign means it's correct in meant that it was incorrect and IC was oh I'm sorry I in meant inconclusive which means that the patch was actually a breaking patch for example the parameters change so then the experiment is not executable anymore and IC meant that it was incorrect so out of these 23 vulnerability reports if we gather the results of Poco using those three models which are GLM 4.6 which is a open open source model open IO3 and clonet 4.5 for 22 of them uh it managed to create a well-formed PC and a correct one for 20 of them overall with this uh we can say that P

generation automatically can produce correct and well-formed exploits for 80% of the reports that we did um that we provided another way to evaluate them and that much research should be done in this area. With this, I thank you very much for your attention. [applause] >> Thank you, Sophia. Uh we have a few minutes for questions. So, please. Yeah, I I would like to ask how does Poco compare against using the cursor IDE to generate the proof of concepts with the same LLM?

>> You mean like uh you have cursor open and then you describe the vulnerability? >> I I just take the same file, the same txt file >> and say to cursor this is the description of the vulnerability. Write a test >> to that exploits the vulnerability. We didn't test it with the ID. >> Okay. Yeah. Because I do that when I do audit. So I wanted to know if it's this is better than >> Well, the the thing I'm I'm thinking right away is that it's not necessarily will understand how to test it right away. So like for example a problem a common problem it's the use of tools and if you write the test in on a certain format it will take some time for the agent to actually understand how to run

it. So then you lose a lot of context in that process. >> I mean in my experience it didn't happen but it may I don't know. >> Okay. Okay. >> But I use uh GPT5 instead of those. So maybe that's I have a weird context. I don't know. >> Thank you. >> Thank you for the question. >> Any other questions? >> Okay. If not, let's thank Sophia again.