The $7.5M Sandwich Bot Hack: What Agent Transaction Security Requires

Transcript

[music] Everybody, thank you so much for coming. Um, yeah, so a little bit about myself. Um, I've been working in theorem space for about six years. Uh, contributor at the build guild for a long time and also developer relations engineer at the graph. Uh about a year ago, I I got on a mission to solve some of the security problems that we're seeing uh specifically with AI agents uh and also with key management, right? How agents actually manage keys. So uh we're going to be diving into uh specifically about the the sandwichbot attack and also if we have time I'll do a little demo to show off how you could maybe do something a little differently with uh

some of some of what we built. So I mean the the issue is real. I think everybody knows that. I don't really need to dive too much into it. But we know there's lots of hacks going on. Um crypto is a target, right? Um because of the decentralized nature. Um hopefully it doesn't go out again. Uh and I think most importantly right now it takes about 27 seconds for someone to steal a credential, a private key, API key or something like that and use it, right? uh which this has dropped drastically and it's getting faster and faster for attackers to uh use something uh to its advantage and we're seeing an increase in attacks right um the last

year we've seen a lot of different um uh attacks that have happened most recently the railway breach which over $370,000 was drained from private keys that were being stored on railway um they even though they were encrypted on railway they were stored in you know their their uh private key infrastructure uh sorry not in private infrastructure but just in their like um environment variables and uh this was uh uh obviously not good. So uh let's talk a little bit about the sandwichbot hack and what happened. Um who here knows Jared from Subway or knows who he is a little bit, right? So I think some of you might understand what what a frontr run attack is, but uh is it keep cutting out by the way?

>> Maybe we just go directly to HDMI because I have HDMI. What's on the other side? Okay, there we go. Sorry about that, guys. Uh, but the general idea is that um the idea is that you want to frontr run some kind of large transaction, right? The larger the transaction, the more slippage uh the easier it is for an attacker to kind of squeeze in and basically inflate the price of the asset and then uh immediately sell and pocket

the difference. This is so weird. Let me just try one thing real quick too. Yeah. Uh, I do. Yeah, they should be on there. Yeah, I was going to see if maybe I could optimize it. Maybe we could try it and then if it does it again, we can switch. Oh, okay.

So then do I still control it with this? Okay, just hit play to go forward. Yeah. Okay, so we Where were we? Sorry about this, guys. Yeah. So, basically, uh, sandwich attack is really just coming in and trying to, uh, get the difference, uh, of what the, you know, the the user is and try to try to get in and pay extra gas to essentially steal, uh, any kind of, uh, difference. Oh, perfect. Thank you. Um, so Jared from Subway specifically has been running this for a long time, since about 2023. Uh, and it cost traders an estimated about $60 million per year uh, at its peak. uh and it's the single largest gas spender on the entire

network. So he's basically uh is sending as much uh gas as he can to get in and and do these sandwich attacks. Um and it's tuned to be fast, right? We need to to operate quickly. So if we look here at the the chart, uh this is kind of a telling chart and you can see here in uh the middle of June or towards the end of June, uh something drastic happened with the account, right? We we also see this weird spiky thing which I don't know what that 40 million spike is but um probably some kind of uh uh yeah atomic swap transaction or something like that but generally speaking on the 21st uh something bad happened and so that was $7.5 million right and u what this was basically that happened is there was a number of fake ERC20 contracts that were

deployed and then those uh ERC20 contracts were also seated into actually fresh liquidity pools with planted price imbalances that made it look very attractive for Jared from Subway to uh you know intervene with those uh um contracts. And so the bot scanner saw this as an opportunity for arbitrage and essentially it uh approved like approved the maximum amount of tokens to get the maximum amount of uh extraction. And uh these basically sat and piled up right across all of the contracts without him understanding and knowing what was going on. Um, and then each particular contract essentially, I'm sure you guys have seen this, you get some airdrop

token on your phone and you go to try to swap it for USDC or sell it and you cannot. And that's essentially what happens is it's a it's a fake version of the standard USDC or WET or USDT token, but it doesn't have a a a transfer from only for the um uh owner of the contract, right? So this uh assets will sit in there and then the owner is able to extract all the value, right? Uh and so this was one tripwire transaction which called all of the transfer from uh uh functions inside of every single contract and drained all $7.5 million.

And I think what was most important is the the stable coin this they were instantly taken from stable coins into ETH so that the assets couldn't be frozen either, right? And so, you know, if it would have been on, you know, uh, some of the standard stable simple coin contracts, uh, just like the Binance hack, they were able to freeze some of the assets and recover some stuff. Uh, and then all this was funneled into tornado cache. And so since then, nothing has been recovered. Uh, which is very sad, unfortunate. Depending on how you feel about Jared from Subway, it it goes both ways. But, uh, obviously, uh, it's pretty tragic.

So, what actually happened? Um there's a com couple common patterns that I've been seeing for agents that are specifically vulnerable. And you know, not that uh Jared from Subway runs an AI agent. He might run a script, but it's automated, right? Whether it's AI or whether it's a script that's running. The the general idea is a lot of people are keeping uh raw keys inside of environment variables, right? This is a a common issue. Um, these show up in context windows on AI, like if your AI accidentally sends it off to OpenAI or Gemini or something like that, uh, they're logged. Um, and, uh, one particular leak, there's no recovery, right? Um, and then the other common thing is these unvalid execution, right?

Um, a perfectly secured key can basically sign a transaction that it shouldn't really be able to sign. uh and it basically can be fooled into doing something by either reading a skill that is corrupted or uh reading a tool lookup if it's AI that maybe tricks it into approving a contract um and you have no verification and this can be a huge issue. So, uh Jared's keys were never really stolen. Uh his bot basically signed exactly what the attacker wanted it to. That's I guess that's one caveat of this talk is that he remained in custody of the keys and the issue wasn't with the keys, it was with the contracts.

Um so what are some of the defenses that we can uh think about? Uh one is you can simulate every transaction uh before signing. Uh who here uh uses Tenderly? Tenderly. Okay. So Tenderly is great. If you're not familiar with Tenderly, they provide transaction simulation. And uh one of the things that we've built into one claw is that you can simulate transactions and you can also simulate bundled transactions. And we'll get to why that's important here in a little bit. Um but the the general idea is that you are running a dry run against the transaction that takes tens of milliseconds, right? Um which is a very cheap consideration uh to losing $7.5 million. Um, and then this kind of uh

guarantees that you're going to be able to know that your full swap is going to go through and there's no loss, right? Permanent loss. The other is uh doing deny by default, right? Um, so whether it's token approvals or EIP712 type data, the idea is to block black, blacklist this, blacklist this, sorry. uh and only explicitly allow on known tokens and also known addresses, right? There's a lot of um you know, depending on what you're trying to do with a bot. If you're trying to do DeFi, there's a general probably idea that you know what kind of contracts you're going to interact with. So, you should kind of create some guardrails around the addresses that you want to allow on. You should also have value caps, whether

it's daily or transaction limits. Um and these should be out of the agents or out of the scripts. uh capability to alter, right? Because the attacker, if it's on the machine, it's going to be able to alter that. And so, you should have a separate kind of authorization flow that's human-based that you're controlling all this stuff. Um, and then you can basically approvals like when you get an approval, a lot of people just say unlimited approval. Uh if you go to I forget the the app that will let you scan your wallet and tell you like how many approvals you have. Uh there's a good chance your wallet probably has a lot of unlimited approvals that are not necessary. Um and you should consider removing those or only approving up to a certain amount that makes sense for your

um uh for your transactions. Um so one so what is one clause? So when I first started building oneclaw I was I had built spritz.hat chat, which is a decentralized chat application. And I wanted to give every user a personal assistant, give their agent a wallet. And I started to realize that uh to trust agents with with wallets with like secret information is is is a real challenge, right? And so we wanted to build infrastructure that is secure by design that uses hardware security modules, multi-party computation and trusted execution environments to completely isolate what the agent needs to do inside of the TE. So um the idea

is that we have high security standards and when you're using oneclaw, you inherit all of the security architecture that we've been building for the last year. Um and you can kind of guarantee that your agent is going to be able to operate within its uh within the policies that you set. Uh so what what you do with one clause is you can store the keys uh or or generate the keys inside the trusted execution environment and store them inside of a a hardware security module and we can split that key up across multiple cloud providers and you can also custody a key of your own. So we support multi-party computation up to four parts or you can do two of two if you want to maintain your your key and you register an agent with high security limitations like only allowing to

interact with certain contracts only allowing to uh make certain types of contracts u or types of signatures. um and not allowing the agent to actually see the raw key data itself and instead the agent gets a scoped key that it can use to in send an intent into one claw and this way the transaction runs govern. Uh so in the case of one claw we um inspect the call data and the EIP712 data and decode it before any transaction is signed. We also do inspect multicalls and safe bundles. We also do um uh have separate policies for approvals, type data and raw signing,

right? Uh and the allow rules match uh exactly what needs to happen on the chain. And we have a known token registry which is I think very useful for the the case for Jared from Subway is he would have been able to query the the known token and know exactly that he was interacting with the official USDC contract or USDT contract. Uh we also support address allow lists which we could specify hey if it's only interacting with say unis swap or whatever you can uh inter choose what contracts you want it to allow with and then you could also create transaction limits. So on a per transaction or even a daily limit uh and also gas budgets.

So there's a lot of like fine grain access control you get and again the agent never has to have a private key and it just can operate within the bounds of of the policy. Uh so if we look at the same attack we played against guardrails like oneclaw you know in the case of Jared we the grant bought it uh approved granted approvals on 66 contracts that nobody had vetted. Uh it also signed at full speed with no validation. Right. And it had no caps. There were pretty much uh wild wild west is trying to get as much extractable value as possible. Um but what it did do is it guarded an agent u what what sorry what one cloud could do is it would guard against uh these unknown approvals these unknown contracts. Uh we would we maintain a

list of all known um contracts that are valid and verifiable. Um and we can do this the simulation and I'm going to try to do a demo here in a second. And uh you also can uh create these per transaction and daily cap daily cap uh rules. So for for what we do, we think and this is same thing that you guys should think about when you're building your applications. Uh we live in a great time where people can build very quickly with AI. Um and it's getting more and more important as you guys have seen in the news every week there's some kind of hack or some kind of supply chain attack. And so these are some of the things that we think about when it comes to security. We always focus on multi-party computation and we do all the ceremony of the key construction

inside of the trusted execution environment. [snorts] Um, and we also have a vault that allows you to um uh sign and and and create um stoages for keys and and whatnot. And uh we also have what's called the shroud which is a trusted execution environment that inspects the LLM traffic as well. uh we provide all the permissions and trace backs and uh we also think about things like impossible travel like what happens when uh your user all of a sudden appears in another country. Uh what happens when you uh have a um a situation where something is trying to meet access. We have what's something called honeypotss which is really cool.

So really cool stuff. And so uh let's just try to do a demo real quick if that's okay. Can I switch back to my computer? I just want to show uh what what's cool about our infrastructure is we have a platform API. Can we switch back to the computer? Uh we have a platform API that lets you build very quickly on one claw. So I I built this with clawed code in like 5 minutes which is really really awesome.

um we live in a great time again as I said but what's great is I inherited all the security that I had already built over the last year right so I knew instantly so we have this example all right you're let's pretend your agent is trying to get a tip about some kind of new token that launched we have two different uh paths we have the happy and the sad okay so we'll go with the sad first so in this case we have two oneclaw wallets one with exactly no policies raw signing enabled wild wild west do what you want. And then we have another one that has full guardrail controls. So we will run first the standard one. Let's hope it works. Hope my internet connection is working. If not, I will connect to my phone.

Let me do here. All right, let's try this one more time. Here we go. All right, so first I'm going to run the one with a honeypot. So, what we basically have deployed is a fake honeypot and a fake fake uh liquidity pool. [snorts] That's weird. Hold on. Let me make sure it's running.

should work. I don't know why it's not working. Okay, here we go. So, this is a wallet with no guardrails. We basically um found this token. We went ahead and bought the token, but and we approved the transaction to spend and then we tried to sell the tokens and it came back trading not enabled, right? And so this would be a typical kind of honeypot token that you would probably get air dropped on your phone um and just think it's a normal token. You buy more because the price is really high, but in turn you can't sell any of it, right?

Only the owner can withdraw. Then we run the same thing with one claw here. And what's different? Again, it's a similar scenario as what Jared went through. Uh but we're going to check to make sure that uh the wallet's within policy. We're gonna simulate the actual transaction to see if the it's a honeypot, right? And so we're using Tenderly behind the hood to do that. We can see here that the honeybot was detected and [snorts] then the agent walks away, doesn't make the transaction. These are all real transactions as well. Um, and then we do the same thing to try to do things like uh send to a different address, um, trying to uh abuse the policy, trying to go over the spend cap. Uh and then you can see here where we did an

actual real uh valid transaction and everything went through where we bought it. We bought a vetted token and we were able to swap that and sell it back to ETH with no problem. And so the thing that makes this possible is essentially here the um uh the configuration guardrails the policy where we create uh what allowed chains are allowed, what transaction uh addresses are allowed, what uh transaction types are allowed, what the max transaction per day and per uh um transaction is and uh requiring approvals and then denying um uh or sorry denying on a failure. Right? So very very fine grain multiple steps that you can configure uh with one claw. So

yeah, thanks so much guys and I'd love to answer any questions you guys have. [applause] >> Beautiful. Thank you Kevin. That was great. That was great. Just before we get into the questions, the websites are revoke.cash or approved.zone if you need to revoke your unlimited approvals. Okay, opening up to everyone for questions. Just hold the mic up to your mouth. >> Yeah. So u isn't it like um correct me if I'm wrong but isn't it just basic opse basically having like basic guardrails or daily limits or like some kind of authorization or the agent not being able to see your private key.

These are aren't these just basic obsc or I'm missing something bigger here. >> Yeah. No, I think you're right. The I think the difference is that we just doing it within infrastructure that's trusted, right? Um things we we're using hardware security modules which is physical hardware and we're using trusted execution environments which which are also physical hardware. So it goes a little bit more into like actual hardware security but yeah it is obstac as well. Yeah. >> And a small small followup. So in the so when you simulate in the tenderly will there be a false positive where the transaction could have been while you're simulating it could have been a positive outcome but it simulated a negative outcome. So you will you be missing out on those transactions?

>> Uh well it depends on what how you're looking back at the transaction. In the case of one claw, we just see if anything failed or reverted and then we would notify you and then you could well we would notify the agent and then it could deny or whatever the policy is set. Um but I guess it depend on the contract. Obviously there might be some new attack that is not configured by tenderly. Uh but at least you have that extra value um or extra check. >> All right. Thank you. Nice job. >> Thank you. Any more questions? Yes.

Is this more for companies uh or for like personal use? Do you have bring your own key? Uh is everything configurable? Like for example, if I want to turn off the IP address protection, can I do that? Can I make um you know, if I use it for myself, can I turn open claw into like zero defenses if I want to? >> Yeah. So there's a few questions there. Is it for uh companies or for individuals? So we have a free tier that you can actually do for free. Uh you can bring your own key. Uh I think one of the other questions was can you like limit to zero guardrails on openclaw?

Yes, we have a opencloud plugin. We have a hermes agent integration. Uh we support any agent harness. So it actually is very very seamless for AI. You can give it to muse grobbot dots whatever and it'll work. Um and that's the value right is like providing any harness uh and those those guards around that. Yeah. So please try it out. >> No that's great. I was actually looking for this earlier today and a little bit last week. So nice. All right. Cool. >> Nice throw. Any more questions? [music]