Sebastian Banescu - Drained Before any Code Exploit: The Non-Code Risks of Web3

Transcript

Thanks for everyone uh that joined this early  talk. Um today I'm going to be talking about um you know things that get you hacked before  the act like that lead to a hack before you're actually exploited. And for that we're going to  address the three big elephants in the room. Um these are the three elephants. The big one I think  the biggest one is operational security. And that has to do with people, right? People, humans are  some of the weakest links. Everyone knows that. Uh but not just the human itself. Of course, it's the  devices that they have that they bring to work.

It's sort of the bring your own device policy. in  pretty much every web free company and people mix personal with work rellated information on  their devices. This is this leads to issues um especially when they also use those devices  to sign important transactions that move a lot of value. The second elephant in the room is  vibe coding. And I just want to, you know, preface that with saying I'm not against using  AI to code, but there's a difference between vibe coding and using AI properly and we're going  to discuss that. And the third elephant um that I think was already pretty nicely addressed in the  previous presentation um is AI audits. And again,

I'm not against using AI for audits. I think  it's a great compliment, but um they shouldn't be fully like humans shouldn't be fully replaced.  So with that, let's jump in to the first elephant, which is OBSC. As I mentioned, it's about people  and devices. So of course with people everyone knows the the social engineering attacks have been  around since forever like even before the internet people were calling someone up and pretending  to be someone else. Now with the internet it's getting more and more complex with social media  interactions uh on serious platforms like LinkedIn uh or on less serious platforms. people are  getting business on that those platforms and

of course scammers are pretending to be people  that they're not and uh exploiting key actors in certain organizations. Now, this combined with the  fact that some people use social media and so on uh on their work laptops and sometimes they  download things um that they shouldn't on on devices where they have keys uh amplifies this  issue. And um you know this together with the fact that there are specific admin paths in every  decentralized application also leads to damage and compromise. So, let's look at, you know, a real  attack chain. This is something that you might be familiar with, but I'm not sure if it's, you know,  um, clear to everyone. Most defenses, you know,

they they try to break one of these these links  here. So, the first step that an attacker would do is called OSENT, which is basically gathering  intelligence about their target. So, they pick, let's say, a project. I'm going to have the the  drift hack as a use case after this. But let's say they pick a project, right? Um and they  figure out who are some of the key players, where are they going to the next conference, the  next event, where do they hang out in their free time, how can I get to interact with them, what  do they like, uh what do they dislike? Um and so on. That's that's Osit, right? They just gather  intelligence pretty passively most of the time.

And based on that intelligence, they decide  when to act and performed the social engineering attack. The next step, which is either a message  on LinkedIn, an email, um a telegram message, or even a phone call. And if you know the the  target bites, they're in. If they don't if they don't bite, they try another way, right? It's not  like they're going to give up after the first try. You have very wellfunded state actors like the  Lazarus group who are not just going to give up after a first try. And I'm sure many of you  have been targeted multiple times by this group because they're pretty much after everyone.  After they manage to compromise someone via

social engineering, they get to this point, the  endpoint compromise. And the endpoint is a device basically a device that you have either your phone  or a laptop or something else. Maybe it's a VM on AWS or something. Who knows? Whatever they they  can get their hands on. And once they get their hands on it, they figure out what this device is  being used for, what information it's storing, and if they can maybe take over that account and  horizontally escalate in your organization or maybe even vertically escalate to hire a higher  admin. And uh once the account is taken over, if that device has keys, they will steal the keys,  drain wallets or even you know treasury wallets,

not just personal wallets. and they will abuse any  privileges that that account has in terms of like especially if it's an admin account they will you  know maybe even try to let's say they compromise a developer then they use that developer's account  to contact the CEO and ask the CEO for something using that developer's account so that's even  harder for the CEO to distinguish from an external um attacker that is trying to do social  engineering so imagine this chain applied in parallel to multiple uh employees of the same  organization, right? And sometimes, you know, when they're maybe doing the account takeover,  uh they take over someone's account and then they try to socially engineer someone else in  that organization, right? Which makes it even

harder. And at the end, the last step is, you  know, they really strike and they drain some account. It could be a personal wallet. It  could be a treasury wallet and so on. Now, as I mentioned, we're looking at the drift  hack. This is a project uh which is not um on the EVM chains. It's a Solana project that got  exploited um I think it was end of March, but um it was a big hack. It was somewhere  around 200 million uh dollars worth of assets. And what was astonishing about this  hack was that it was very well planned and it um basically lasted for more than half a year.  The attackers met their victims at a conference

um at a well-known conference in Singapore. They  shook hands and they presented themselves as a potential customer and integrator and they said uh  we want we we love your project. We want to build some we're building something that you know  we can integrate with you. We want to deploy funds in your project. And they actually ended  up after a couple of months deploying funds. So, as far as we know, the attacker here is a  legitimate business partner. They deployed 1 million worth worth of assets into Drift and  now they have like a good ongoing relationship, right? Every project wants to grow their TVL. And  at some point, the attacker basically compromised

one of the signers by sending them a code repo  for something that they were cooking and they just wanted to hear their the opinion of someone  from Drift if it's okay with them, right? So, they sent them a repo saying, "Hey, just check this  out. I just want to get like a quick, you know, um, approval from your side. and they opened the  the repo that had the malicious script in it. uh and they clicked I trust this repo and the  malicious script was executed that compromised the signer's machine and later uh the the that  signer was asked to do a signature but we all know I mean probably everyone has experienced this on  hardware wallets when you get something to sign it

asks you to do a blind signature and then you look  at the message and it's all hex code you can't make anything out of it right and that's that's  the point where you know due to not sufficiently performant UX people just sign it right they're  just like okay I'm going to I don't know how how can I tell this apart from anything else they  sign it and that gives more leverage that gave more leverage in this case to the attacker and  that combined you know with uh nonsis on Solana which you know basically um allowed the attacker  to delay the attack and not attack immediately.

Then they realized you know we can escalate  quickly from this point and at the point in time where the exploit was performed and the funds  were transferred um there were no effective breaks circuit breakers cancellation mechanisms to  stop that transfer. And making it even worse, after they detected using their monitoring  system and others notified them about this, um the response that should have come from stable  coin issuers such as USDC lagged for hours and hours on end until the attackers managed to  actually get the funds out um and they were no longer freezable. Um, yeah, we need do need to  give props to USDT here because they did manage

to freeze a part of the funds that were stolen,  but not everyone acts as quickly as they do. So, that's just one use case, one example of, you  know, um, very sophisticated hack that took over 6 months um, to execute, not to plan, to execute,  right? Um so in terms of hacks sophistication of code and and the attacker basically figuring out  very difficult code patterns that's not the only problem. Obsec is something which in essence is  not rocket science but I think we talked about this during uh the panel yesterday. You know  people are lazy so it's hard to get right. Um,

so you're you're going to get and you probably do  get this on a daily basis. You have either fake VCs that want to fund your project or recruiters  promising you, you know, 10x uh your salary for, I don't know, clean take bringing coffee or  cleaning something. Um, you have journalists that want to interview because your project  is so cool. Um, and all of these, you know, might be potential attackers and you just, you  know, might not suspect it because you think like, ah, oh, someone likes my project, someone  wants to, you know, do something about it. And, um, they don't necessarily strike immediately. So,  they won't just, you know, some of them do, but,

um, some of them wait for the right time. So, they  set up a call with you in a week or two because they're also very busy attacking other people.  Um, and they, you know, when you get on the call, they're like, "Oh my god, Google Meet doesn't  work in my country. Can you please download this because it's much better?" Um, or things  like that, right? And uh they definitely also, you know, using that osin step that I mentioned  before, they figure out where you're traveling or when you're traveling and they also try to  strike at those times when you're less vigilant, right? Um and the outcome is of course, you know,  you just need to download one file and execute it.

Um and that becomes the incident. So, one other  thing that I wanted to touch upon here because a lot of people I think when the when the drift hack  came out, one of the most common response that I've seen on X is people talking about why did  they just have a two out of three or I don't know three out of five multisig, right? And the point  is that this threshold, you know, it's a number. The higher the number, the in theory, the higher  the number, the better the security. However, the problem is that if you don't have a good  process behind that uh multi- signature wallet where you know people are not rushed, they don't  share devices for signing and for coding and you

don't have a proper review of what they're signing  and they're just signing something blind and they cannot really make out what they're signing. And  then if they cannot make out or if if something looks fishy, they cannot escalate to someone else  to figure out what this is then that is not a proper multisig setup, right? So I think everyone  is working hard to create better UX for multi-IG users and we've seen this is possible like one  one like one of the first um applications I would say or or use cases where I saw finally you know  a proper multi-IG message was this um Ethereum DAO fund. they have this funding round and and  they had, you know, like users needed to to use

their hardware wallet to sign um in order to get  some voting tokens and so on and it was finally a proper message that you could see on your multi-  on your on your hardware wallet as well, right? So, it was like, oh, this is this is possible.  It's it's just that you know many applications don't bother creating those messages that look  well you know you could read them on your hardware wallet display. It's possible it's difficult but  definitely doable and more people should do that. And I think there's after these hacks there's  way more effort put into creating better UX.

The fastest way to lose money. That's  that's one of my favorite slides. So, you know, whenever you're in an organization,  you have a multi-IG wallet and someone out of the blue while you're traveling maybe or you're  under pressure due to some deadline to just say, "Hey, just sign this quickly because I need it  for whatever, you know, it's it's super urgent, the CEO will be super pissed if you don't do  this." That's, you know, that's uh a basically a a stored loss event. Um because you know you  should never sign something that you've not been properly briefed on before and uh don't trust that  someone's going to get upset because someone else says so. So rule number one this blind side uh  signing is definitely operational debt right and

um it's um you know uh incident waiting to happen.  The second rule is that um unreadable payloads are should be treated as suspicious always and  you should always ask if someone sends you a transaction that you want to sign is like how can  I verify this right and um whenever there's like pressure it's like oh don't don't don't worry  about it it's good you know that's that's when the the quality of the review process matters the  most And now on to the second elephant. Um, if you remember this was about the free elephants. The  second elephant is vibe coding. And I want to make this distinction between using AI to code which  is totally fine. The what what what I call vibe

coding in this presentation is building something  using AI that you do not understand. You do not understand the code. You see how it works. You  try it out, you do smoke tests manually, but if you look into the code, it looks just unreadable  and you're like, I have no idea how this actually works. And I've seen I've I've heard a lot of uh,  you know, stories about this. So, this is this basically breaks it up into what good AI assisted  engineering means and vibe coding. In both cases, the speed goes up, right? That's why people are  using this because they want to ship quickly. But the big difference is that in the good engineering  practice, the engineer still understands what the

code is doing, right? And they take ownership  of that code and they don't just say, "Oh, it's not my fault. Claude wrote it." Right? Like it not  you were using Claude, so you wrote it. Right? Um, you don't you can't blame an AI. Um, you should  take ownership of it, right? And you should be able to explain what Claude wrote because you  prompted Claude to write that code. If you can't do that and you're still confident about the code  even though you don't understand how it works, that's that's vibe coding. Just wanted to make  this distinction. The big problem there is that you can't properly secure something that you  don't understand. So mature teams that use AI to write code, they could always answer these four  questions, right? What where does the value move

in my code? What are the critical paths? What  are the assumptions that really matter and who can stop like which role can stop a certain  attack or a transfer at which time? Right? If you just, you know, yolo it, Vibe code, you  hear things like, "Oh my god, awesome. It's finally compiled. No more errors. All the tests  pass. Let's ship it. We'll clean it up later." And this happens a lot um in hackathons,  right? Because people are under pressure. They want to ship something really quickly. The  big problem there is that temporary code built during hackathons has this very annoying habit  of becoming permanent and being able to hold value after a few months. You know, if you have a  very successful hackathon project, it's going to,

you know, hold real value as sooner than you think  because people like it. They they want to use it. It promises high yield maybe. And that's all MVP  debt or hackathon debt that all founders promise themselves that they will fix. But all the time or  not all the time but most of the time that cleanup sprint never comes or it comes much later than the  actual value arrives in their application and when they're actually targeted by attackers. And now  the third elephant is AI audits. And again, I want to preface this. This is not an anti-AI talk. I'm  actually like very much proAI. I think pretty much no one does full manual audits nowadays. Everyone  uses an AI assisted audit. So, it's a great tool,

but it shouldn't be a full substitute of a human  audit, right? Um, I totally understand why why founders love AI audits, pure AI audits, because  they're super fast, very cheap, close to zero, right? And instant, right? You don't have to  wait a long time for them. So founders are already under pressure to ship fast. You know,  we just talked about that with vibe coding and the market is moving. They want to be the first  mover. And when you go at the end of that develop long development cycle and you want to launch  it and you ask an auditor, hey, how much does it cost and when can you start? And they say, well,  it's going to cost six figures and we can start

in two months. You're like, oh my god, you know,  we can't do that. Uh, that's that's way too late. So this AI pure AI audit that that what I mean  here is just someone writes a prompt find all the bugs in this code and they attach the zip that you  know is um it sounds modern sounds inevitable but we're not there yet and there's this hidden cost  that such a review gives you a false confidence if the AI is not able to find something or it finds  some things that are obviously false positives due to some you know um glitch. It gives you  you know um this confidence to deploy on mainet uh which is totally you know should be totally  avoided. Um most of the time you know the those

those super cheap audits they end up being a very  expensive mistake. So founders in the beginning when they're just starting they want to optimize  their costs but um the important thing to keep in mind is that this this cheap review given to you  by an LLM model which you know everyone has access to these days is going to maybe come back and bite  you. Um a real audit is probably more expensive. It takes more time but it can actually influence  launch decisions say hey you guys are not ready to launch yet. I we have you know unfortunately  had situations with customers where exactly this happened. They came to us it was too expensive for  them. They decided just to do an an AI scan using

you know what state-of-the-art meant at that point  in time and they launched and they got hacked. Now I'm not saying this will always happen. Sometimes  you know uh the code is actually very properly written but in some cases it's not and you  know false negatives that are missed basically vulnerabilities that are missed by the AI could  end up costing you the entire project and all the hard work that you've put into it. Now AI is very  good at some things and you know I'm not claiming to be an expert on AI but it's really good even  for us auditors to get a fast summary about the project quickly ramp up on it um you know using  AI has reduced ramp up time significantly and it's

also improved the quality of ramp up significantly  because before if you got a a repo and no document presentation, you were basically learning about  you were reverse engineering the code as you were looking through it line by line. Nowadays, you  could still put the code into an AI model and it will tell you what the code does before you  actually jump and read the code line by line. That that's a a tremendous benefit. AI is very  good at spotting existing patterns of course and I think like it also goes a bit beyond that  with these new frontier models it can also reason um especially if the code base is relatively  small. I think the issue becomes with if the

context gets larger and larger, the codebase  gets larger and larger, things will definitely be missed. But it's also great for developers in  order to increase their test coverage to to write some really cool edge case tests and, you know,  basically just improving their posture overall. Humans, I think, are still better at holding  the entire messy system with all the context, maybe from like the BD guy and the PM and all the  all the people they talk to on the kickoff call or even, you know, in in real life interactions  in their head and um you know, figuring out what matters to that project and what doesn't, right?  they're they're not going to dwell on something

like oh the admin can change one parameter which  I've heard from someone uh at this conference like you know things are being reported by LLMs like  oh if the admin can change a significant parameter that can you know cause a lot of damage that's  reported as a critical but of course you know um in some cases where the admin actually is  properly secured has decent opsec that is not a critical Humans are also very you know they have  this gut feeling of this doesn't seem right right I think I don't know if AI is there yet right I  don't know if we can say AI has a gut feeling but um they can you know feel that something's wrong  even before they spotted the bug and you know the line of code which is vulnerable and um you know I  think the the business logic bugs the subtle bugs

the the attack chains are still something that  you know some humans are able to find I think also AI I can find some of them. But basically the  the answer is a combination between the two. Not replacing humans with AI or just doing uh pure  human audit. It's a combination. So you should do AI assisted audits and also combine them with  advanced testing methodologies with such some of them are indicated here. So fuzzing is a very  successful testing methodology that has been used for decades uh by large enterprises to find  really important bugs and they're also being used by web free products or projects to find important  bugs that humans miss because it just pounds the

system with like millions or billions of possible  inputs that would be inhumanly feasible u to do manually. Um and then you have formal methods.  I think formal verification is something which doesn't always fit with u the project that you  might have or it only fits for some functions that make sense. Form of verification has this issue  of um you know combinatorial explosion if the code has a lot of loops and branches and therefore  it typically works for code that either has a bounded number of iterations or no iterations  maybe heavy math that is something that where formal verification shines. In other cases, you  always have to bound the loops which might limit

the you know real world use of that code right  if you say I can only do five loop iterations you know the vulnerability might appear only  at iteration number 42 and one other thing that I want to sort of like emphasize having a human  auditor is is definitely better than just doing uh AI but sometimes I think, you know, like we at  Adiver Labs think that having two human auditors actually even better because sometimes auditors  have a bad day or they have like something in their lives. They maybe they're sick, maybe  their, you know, cat is sick or who knows, right? And it's very difficult to detect that.  and auditors maybe sometimes typically don't

admit that I've had a bad day and I you know I  couldn't really work on the the audit. So having two people is great because you have this, you  know, um self or like or like peer check and you see like if one auditor is able to find a dozen  findings before the other has found anything, there's something up, right? You should check with  the other one to see if something's going on. and and we've had these situations in in our audits  and this is one way we've been able to detect that something is wrong. I think if there were always  just one auditor, you you wouldn't be able to to see if there's a difference and therefore you  would say, okay, you know, this guy did his best,

but maybe his best was not at his best, right? He  was not in a in a good condition to do the audit. So make sure you know my my advice is make sure  you follow the four eyes security principle and you have like at least two auditors on your on  your audits. In conclusion, I want to talk about responsible security. So it's not just about  auditing. You should also make sure you have opse right make sure your code is secure but also  your ops should be secure. Make sure when you're launching everything has been fixed and verified  by someone independently, not just that you got some issues and you fix them and no one actually  verified if the fix maybe introduced other issues.

Once you've launched, of course, my recommendation  is to also have a bug bounty program, also to have real-time monitoring of issues and not just  monitoring, but also an incident response plan such that if an alert comes from the monitoring  system, you know exactly who needs to do what and not just for code issues, but also for ops issues.  Here's a very short pre-launch checklist. So if the answer is vague to any of these questions,  you're maybe a bit you're launching a bit too early, right? So try to understand and and explain  how the value flows for your system, the key invariance, weird edge cases, where funds move.  Right? This this is important with respect to the

code. But then also with respect to your audit,  make sure that there was a manual review combined with AI and that there was ideally more than one  reviewer. There was more than just an AI scan done via the frontier models and the fixes that  were implemented after the audit were verified. Um, finally for the operational side, make  sure that you know you would be able to pause or upgrade something in case a vulnerability  is discovered after launch. And then make sure you have someone on duty to respond to alerts. So  there's, you know, companies like ours that offer, I mean, we we are starting to offer that, but like  there are companies that offer um 247 monitoring

and they're able to, you know, immediately respond  and start a war room if something happens. and um you know have this incident response plan even  for issues like duress where you know maybe some of the key players are kidnapped that happens  very often in France around Paris. Um yeah, I think the the key takeaways from this talk  are um the opposite of security is actually false confidence and this is very often given by  AI in this day and age. So you know weak OPSSEAC is is is is problematic. Just fully relying  on vibe coding or AI scans and not doing a proper audit is also problematic. And that's  it. Sorry for being over time. I don't know.