Web3 exploits: a shift from smart contract bugs to Web2-style attacks? KenanBešić @k_besic

Transcript

Uh my name is Emily. I'm one of the co-founders of Chain Security and the head of sales. So I'm not technical and so then I brought someone more technical than me, Kenan, who's also a partner at Chain Security and a senior blockchain security engineer. Um today we're going to be talking about hacks. Of course, you know, we're a security company. Um, and specifically we'd like to talk about the ZK Sync hack, the Bybit hack, and also a potential trend of of hacks not being smart contract hacks anymore, uh, but actually being kind of more web two type of attacks, more fishing, social engineering, and in the end, the key compromise is kind of a web two attack, right? It's just stealing information

from a person. Um, so this is kind of what we're going to be talking about today with the help of Kenan. So, let's get started. Um, Kenan, can you tell us uh kind of briefly what happened with the ZKYNC hack? So, first of all, hello guys. Um, with the ZK sync hack, essentially tokens were minted uh by an attacker which took over um safe wallet and then he was able to execute the privileged transactions and the main reason for the attack was essentially a loss of keys. However, this now happened is still unclear, I think.

And probably it was fishing or something else. And essentially what they did is they took this safe wallet, they initiated the transaction, they used the airdrop contracts to mint the remainder tokens that ZKYNC allowed to mint by governance. They minted it to their own address and they essentially profited, I think, by $5 million. So that's essentially it. Um, it was a setup with a multisig governing those contracts. And this multisig wasn't really a multisig. It was a one out of one safe wallet. So, it was one address that controlled the funds. So,

it was quite easy to pull off if you have the keys to one address, you can still control this multi6. So, it was essentially not too much like crazy effort to put in. Of course, you need to get the private keys. However, what's interesting is actually also that this address hasn't been really active. So, it hasn't probably used any protocols. So, there seems like it's also hard to fish this address because it hasn't interacted too much with the chain. So, yeah, I think that's it.

Um, so it sounds like would have been difficult to know about this address, would have been difficult to to target this specific attack and could it have been an inside job? Well, it can always be an inside job, right? You never know. But I expect people to do in their companies to do some KYC on their employees typically. So even if it's an inside job, you can track trace back who set up this wallet internally who decided to um be the signer and then it's like one person so you can easily follow their tracks. But you can also then investigate to see if this person

actually did something. Um, but apparently I think from the ZKYNC blog or one exp post they actually I think did this investigation and it came forth apparently that it wasn't an inside job but of course it could have been an inside job. We've seen so many rugs. We've seen so many weird things in this industry. So it's possible but in this case personally I doubt it. And how come these these tokens weren't minted? Was the caseync waiting for another stage of the airrop or how come these were not minted? So the typical

procedure is that you set up like these miracle trees and then you can prove basically that you have an allocation and what this contract essentially did is you as a user were eligible you were notified on X then you could check your wallet whether you're eligible and then you have the claim and the claim period I think started in 24 2024 and it ended somewhere in January 2025 or February. February and for some reason like people do not claim maybe they don't use um ZK sync anymore or they don't use um crypto anymore. Maybe they lost too much

money and stopped using everything. So some people just didn't claim their tokens and eventually once the deadline ended nobody could mint tokens besides this particular this particular governance address that had the right to with or mint everything that was unminted by the users that should have been minting something and was there so basically um like January February uh we realized that the the deadline has passed for people to mint these tokens. Was there something ZK could have done with these tokens or were these tokens basically never going

to be minted unless the hacker came in? Those tokens could have been minted by this particular address, but this particular employee was leaving ZKYNC in September, I think, but I'm not sure about that anymore. So, nobody had control over this address. So that was one of the first mistakes probably to not check whether you still have control over important contracts. So they didn't have the control over the contract. So that wasn't good when this employee was leaving for example in banking. I have friends in banking of course in Zurich.

But typically you know who has what privileges for customer accounts and so on. So this makes also sense for multi contracts and multiC signers that you keep track. Uh this is everything what this person can do. So once this person leaves our company we revoke those rights. And here I don't know if it was a multisig more than a monosig, right? I mean not really best practices either. Yes. For some reason they in this case didn't set it up. I checked on chain like their other multis or their uh safe wallets. In those cases, I think they have a four out of seven, which is quite acceptable. But for the airdrop

contracts, something probably went wrong in the processes. And that's highlights important of importance of processes that we have checklists uh that we follow. We validate each other. Not that we don't trust each other, but still it's better to validate. But there could have been other measures taken because there is also the ZK sync token contract and uh in this contract you can define access control which is then governed by the actual multisync of the security council of Zikync and this wait the security council is that a real thing that exists or you or you said or you say there should be a security

council I think there exists one uh it's um the ad like they were the ones also negotiating with the attacker. So, and also they can assign roles particularly on the token contract and they could have just revoked the role of the mentor contract that this mentor contract can be hacked but cannot mint, right? That could have been a possibility if they never intended to do anything with the remaining remaining token. So, there is a pending access control which is also not cleaned up. So it's also for smart contracts in that regard important that sometimes you need to clean up your state. You need to check what you have,

what privileges certain addresses have and then just filter through and revoke those excesses. Thank you. Uh I'd love to hear more about kind of also the process of negotiating with the hacker, recovering the funds and so on. But I think now you already started on the kind of best practices and lessons learned. Um so there is one of course not having a one signer but having more signers. Um and so checking also who has these privileges with the smart contracts and and kind of trying to keep that up to date. Um what are some other lessons learned you know that we could share with the audience here based on this? I think the most important thing is to keep uh once you set something up,

don't trust your former self. Also, validate yourself. Um because this was probably just a simple mistake. Um monitor your contracts, which is really important. How how should you monitor your contracts? Some people use um custom tooling, some people like write their own scripts, some people use existing platforms. There is also platforms that uh you can define also smart contracts that on under certain conditions you can actually trigger certain action so that something is prevented if they see a transaction happening they try to frontr run it. So there is a few things uh monitoring tools out there but of course um yeah I think that's the most

important thing you need to set you have to have a good setup which is a good multisig pro best practice is typically that you use separate EOAs so that for each multisig which is important that you typically have a separate EOA which you don't use to interact with anything because you don't want to get fished on this particular address and then what you would want to do is optimally you would isolate maybe if it's a very important uh multisc you can isolate have a separate machine also to to just do transactions. So that's also a possibility. It depends on what you're doing

and the level of funds of course that are at risk by a mistake. So there should be proper risk ail evaluation as other industries do. So we should always keep an eye open for possible attack vectors and the funds at risk and the importance of the given governance contracts. Don't trust yourself, don't trust your colleagues. Have a multisig with different doas and if you have a lot of funds having an isolated machine to interact with it. Um, sounds good. Now, they recovered the funds. How does that work? To recover the funds, who

negotiates with hackers? What is the process for this? How do they first get in touch? How does that work? Well, should I speak from personal experience? No, just joking. We're white hats only. Thank you. Of course. Uh, um, yeah, typically I'm not too much involved in this, of course. Uh but how it looks like is there when such an emergency happens typically a war room is formed. You ask trusted parties to join your war room like who likes you.

Yes. They would be I think there are very trusted individuals that have a reputation of being morally good if we can define this in this area. um that they have been consistent in their behavior these individuals. So u you would contact SEAL which is a go-to option. You would contact other partners of yours. You would contact maybe individuals that you know are very trustworthy and then people first try to figure out what happened. They try to block everything that they can block.

Sometimes nothing can be blocked and in at some point you try to reach out to the hacker and then you try to communicate on X on different platforms and typically they also send an onchain message which is basically just a zero transfer or zero a call with no value with some string encoded there so that the attacker can decode depending on the attacker 's preferences, he will use something he or she. Yeah, he or she. He or she, of course. Um, but the attacker then can decipher and can or just simply read and decide whether they want to do it or

not. And maybe the reason to do it is that often when you do certain things, you leave still traces. The internet is not at all anonymous. you've maybe checked the documentation of a platform that tracks your IP address. You didn't use like very um sophisticated anonymization. So you maybe just use your regular IP to read the docs of this protocol and maybe the IP address was locked. So um and then you can trace it back to the IP which is not easy at all to do but often times you can onchain figure out which address funded your address that or which address funded the attacker's address. So you follow the

funds and then you at some point see a transfer from a centralized exchange if they didn't do it properly in that regard and then you can collaborate with the exchange to figure out uh who initiated this transfer. Often times this also leads to interesting results where you can find out who the attacker is. And of course if you show the attacker to some degree that you are on his toes that puts them a lot of pressure on them because they're criminals in that sense and you're offering them then the chance with your messages which you send often times multiple times, right? just to

ensure that you reach them. You put pressure on them and eventually they return hopefully the funds which is not always the case because North Korea doesn't care about your threats because yeah, you don't have any legislation with them. So it doesn't always work. Sometimes people think also that they are smarter than other people, but there is always some guy that is smarter that can figure out who you are. Uh but sometimes there is not. So they are also sometimes willing to take the risk.

And so sometimes you can kind of turn this into like oh you found an exploit that's great you can keep 10% as a bounty and give us 90%. Is that what happened in this case or did they return 100% of the funds? I think they returned. Oh, essentially what they did, they minted the ZK token. They swapped to ETH. If I recall correctly, they bridged to different chains to some degree, I think. And this indicates that they initially plan to keep the funds for themselves, but maybe they saw the offer of taking the funds legally, which of course depends again on the legislation where

you're at. Um and then they returned the ETH according to the terms and conditions that were laid out by ZK sync. Probably they had some consulting with experts there. So I think my personal belief is they probably wanted to keep the funds and then realized the other thing is a better deal. And how how do they know? I mean, come on, ZK sync. They get the funds back and then they still sue them and then they still do an investigation. I mean, it's not because you give part of it back that what if I rob a bank and then I'm like, "Oh, actually, I'm giving the money back. I'm still going to going to go to prison, right? How does that work

there? I'm no expert to be honest." But I don't know. It's it is hard because again, it's always different legislations where you're uh operating at. So probably in the US if you do something in the US it's different than you when when you do it in Dubai and it's then different than when you do it in Australia. So it's very hard to say what legislation applies to be honest. So probably you could still sue them but if you as a protocol would sue them it would set a precedent where you show that you don't keep your promises. On one hand it's very bad marketing. On the other hand, it's actually also good for your protocol that you recover all

funds. So, it's a difficult decision to make probably in terms of legal also marketing and reputation. Thank you. Very interesting. Um, should we cover more things on ZK sync or is it okay to move to by bit? I think we can move on. Do you guys have some questions about the ZK sync hack before we move to by bit? I think we talked about it for a very long time. Okay, so the Bit hack, what happened? Well, 1.4 or 5 billion were stolen, which is incredible. This is probably also the biggest highest in human history, I assume. So, I've never heard of such something of this size. Um, I

think the Ronin hack was previously the biggest one, but I'm not sure. So what happened is it was a very sophisticated attack, a state sponsored attack by North Korea, by the Lazarus group which is their experts and they did essentially hack not directly also by bit but they did the regular web two attack where they took over uh the AWS instance of safe wallet and then they did some things there to show the on the front end that you're signing something but actually you'll be signing something differently and and I'm sorry the attack vector was through AWS. I I

think one developer installed a malicious docker container. So he was fished by a website. I think it was get stock price something and he installed something which he shouldn't have installed and ultimately this led to his machine being compromised. Eventually this led then to their instance being compromised which then led to the signers of uh by bit seeing wrong stuff on the safe global front end which then led to them signing stuff which they did not double check. So they did blind signing and this led them to 1.5 billions lost. Okay. Okay. So first it was a safe developer that was fished

then that allowed them the ladders to uh have this impact on the safe infrastructure which then had the impact on and what do you mean when you say the blind sign? I mean what was the message that was shown? Was there something different or or was it I mean because you say the interface of safe was also uh attacked right exploited. Yes, exactly. Uh the interface of safe was exploited. So that's again this trust assumption that people have. What do you trust? We trust the safe front end to some degree but this isn't sufficient.

So if safe was to turn malicious very unlikely uh they could again present you wrong data which you would then of course not like the stuff that you see on your hardware wallet looks differently but if you just look at the safe website then you see something and then you just press the button and everything goes boom and that's the essential thing. So you see actually what you want, what they want you to see, what you expected to see on the website, but actually what you see then on your hardware wallet is something else.

Um, and so but then it wasn't really a fault of bit, right? If they saw they saw what they expected to see, what what should they have done to prevent this on the BBIT level? Should they or could they? Yes. Uh, that's a very good question. they could have um this is exactly that you should remove the trust of the safe wallet website. You should use it as it is meant to be but there is other tools um which can validate your safe transactions for you. Um there is a few ones that recently popped up or became more popular. You can write your

own tooling which is always good. So you trust your own code the most probably. But if you use multiple tools to check whether something is correctly displayed on safe website and uh then you're already making good progress. So you should use multiple tools to validate your transactions. You should also check what you are actually signing. So the thing that you see on your hardware wallet, this is the thing that you're signing. You should really understand what this is and what it means. So you should then check this against the front end then. Okay. So we need to have different tools. Are there some tools that you see people using that that are trusted? Some kind of offtheshelf tool that people could use here. Yes. I think year has their own um safe tooling um year finance. Uh so on their GitHub I

don't know what it is ex or I haven't checked it out. There is also from um what does this tag? It's PCA Versace on X. uh he has his own tool which is very cool. It's very minimal. It just uses bash I think and that's all that it needs. There is also one from open zeppelin uh save utils which can help you to identify like inconsistencies. So you should probably just use all of them or write your own tooling just to ensure that because the likelihood of one thing getting attacked is let's say 10%. But uh then the likelihood of both getting

attacked just decreases and then the attack likelihood of three um things that you use being attacked at once. For you specifically, it's um incredibly low. So it's uh then it's a crazy attack that you cannot prevent. But in general, you should use multiple tools to not have this single point of failure. Mhm. But I mean, okay, for a 1.5 billion transaction, that's maybe something else. But for people who like have to manage payroll with crypto, you have to do a lot of transactions, pay their suppliers, they have to make 10 transactions a day. Uh is it realistic to use these three tools or I mean how how can you do it in a way that also

matches your your business requirements? Okay, that's a very good question. And often times what I would also personally do is for important stuff that is not immediate, right? Sometimes these payments you can organize them one day earlier, you can put them behind the time lock. So you just you send the transaction and then you recheck later on or somebody else cross- checks what you put in. So you have a 24-hour delay of being actually able to execute the transaction. That always helps because you can also um if you did not do simulations beforehand, you can still do while the transaction is pending, you can still do your simulations, but you should simulate. Uh this is there is

also tooling like tenderly for example that you can use that you should do. You should probably use depending on the severity probably use two things to validate that no front end has been compromised. But if it's small transactions around $1 uh or $10 if it's just for coffee or something, yeah, you just risk it, right? But for payroll, it depends on how much is controlled by this address because what the buy bit wallet did is actually prepare the a transaction that wasn't I think too big and then if you sign the wrong thing you can just simply drain everything. So it's very hard to

say what the best business practices is but there is I think also this website which offers checklists how to multisync I think or multisc how to I'm not sure anymore but people will find it somehow with how to multise and there is checklist for that uh depending on the severity and I would probably say when you see your transaction validate that it matches at least at least what you see on the front end.

Interesting. Um so going back to how could we have prevented this? Uh so I think on on the bad bit side we kind of covered it. Um now on the safe side, what could they have done to prevent uh kind of their attack vector? Difficult to say. I think regular checks, uh, regular trainings, um, separate machines they could have used, but that's hard to say. Um, ah, thank you. How are we on time?

You let us know if we need to stop talking cuz I think we're going to be talking for 2 hours here. I have a lot of questions. And guys, feel free if you have any questions, you can raise your hand. And I'm very happy to have also your participation and discuss the topics you're interested in. Um okay. Yeah. For so for safe very difficulty it's fishing right. So it's training it's it's a lot of different things. It's compar compartmentmentalization. Um yeah. So that's that's quite difficult. Um and I think it's also very interesting what you said that even if you make a small transaction uh you can you have to consider it or you can have to consider the risk level. uh basically everything that's in the wallet. Uh and I think that's that's a very good point. Now,

$1.5 billion. Uh where is this money? How do you even spend a billion and a half? How do you launder a billion and a half? This is crazy. How do you do that? I would know how to spend it, but how to launder it, I'm no expert, but I can um like from observations, how they do it is they distribute it to multiple addresses. they start mixing the funds and with tornado cash or yeah I don't know if they in this instance use tornado cash because eventually it also gets very hard right to launder because you have such a big sum of money and the security of such mixers is only to some degree or this privacy is somewhat only guaranteed if you use it very carefully.

If you're the one that deposited 100 million, right, and you withdraw the next day 100 million, it's very likely that you're this particular person. It's incredibly likely because nobody deposits 100 million. So, it's a very slow process. You shuffle around, but very cool people online figure still figure out where those funds went and that's an incredible skill to have and they follow then the money. they probably do some analysis on the likelihoods which addresses are involved and yeah it's it's I don't think it's a simple process they have very elaborate schemes where they also used multiple chains they started using multiple

chains and some other chains which made basically all of their profit from um trades on their chains for the tokens. So yeah, it's very hard to do, but somehow they manage, but people still find out. Do we have any hopes to recover part of these funds or or like you said, it's North Korea, they don't care. They don't care about investigations. You can't pressure them, so they're not going to give it back. I don't think you can. Um, probably only if you can exercise a really big amount of pressure. But putting pressure on somebody that has nukes, right? It's not it's not easy. Um but or you do a

counterattack that's also of course like you can try to attack them but they're very isolated so probably it's also hard to attack them in that regard but not sure about that. But I wouldn't expect the funds to be recovered. Okay. And so right away the narrative was that it was the North Koreans. How do we know it was them? Can we know for sure actually that it's them? I think Zack XPTt on X he's like the probably one of the most famous um launching SL. um he figured out he he was able to connect how they like they

he tracked the funds and he was able to connect one address I think to another hack. So the funds of another hack went to partially to one address and he was able to connect that both hack initiators transferred funds to one address. So he was able to connect that it's actually proof that it's the North Koreans. Interesting. Um I think I'm out of questions for the by bit hack. Is there something else you'd like to to say?

Maybe some more concrete, you know, best practices that people could use to avoid this or did we already cover it? I think we covered most. So I would recommend checking out the website that I mentioned that it was shown up for a second. I would also in general recommend that maybe not all signers of a multisc go to a conference. It's it's the same as with your private keys, right? If you catch five people and you have all five private keys, then again, you're screwed. Be very cautious. Be very paranoid. Don't trust anyone. Don't trust yourself. And yeah, be as paranoid as possible. If you can do as much as you

can, it's worth uh the time to ensure that everything is as safe as possible. Of course, at some point somebody will get hacked again, but then we can at least say that we that we tried. Sounds like fun. Um, do we have any questions from the audience about the BBIT hack? Otherwise, we would move on to another topic and the last one, I promise. All right. Um, yeah, just quickly, um, so on Twitter, I see more and more people talking about hacks, about fishing, about social engineering, and really these more web two type of attacks. And I wonder if there's maybe a trend of more attacks like this, or

maybe I'm just more sensitive to it, or maybe people feel more free to talk about it. What do you think it is? I think it's not a trend, but it feels like smart contracts are getting more secure in general. There is le fewer smart contract attacks, but also I think the North Koreans realize that it's just simpler to do these kind of attacks or maybe it's not, but uh they maybe realize that. But I also have this general feeling that people are communicating much more about it. They're sharing their experiences, which is really nice. And I feel like we've seen now so many attacks, so many high impact attacks over the last few years that people finally woke up realizing that yes, everything is cool. We have

cool smart contracts. They are very secure, but um they're finally woken up to realize, hey, there is still the old side of things which we also need to do on the standards that we require, which we currently probably still don't do. Interesting. Thank you so much. Um, I think we're gonna be done. I think we're out of time. One last thing, final words you want to leave the audience with. Be paranoid. And thank you. Thank you so much, guys. Have a nice day.