Not Quite Water Under The Bridge: Review Of Cross-chain Bridge Hacks - Sebastian Banescu

production uh this uh talk is uh put together by some of my amazing colleagues listed here and i'm just sort of distributing the knowledge so a bit about myself i've been working in uh security since 2011 held various roles at various companies and i've been in the uh blockchain smart contract auditing scene since uh 2018 and it's been a hell of a ride um who i work for uh i work for quan stamp which is the company the logo there in the middle uh we're one of the leaders in smart contract and blockchain security we've secured more than 200 billion in assets and smart contracts we have a lot of clients a lot of revenue

and most importantly we're hiring so stick around until my last slide that one has a very interesting piece of information on it so why is this talk relevant there's been a bunch of bridge hacks over the past year so just in 2022 alone there's been more than uh one billion worth of crypto assets stolen from such systems here are at least just a few of them the ones with the ones which are like most important and we're going go go through more details as to why these kind of things happen and why this kind of thing is so hard to get right from a security perspective so here's a bridge it's pretty simple like you'd say like

why why the heck is this thing so hard to get right you have an actor on the left side you have a smart contract system like ethereum that it interacts with and it basically wants to send assets to a different chain and on the other end this actor or someone else might want to receive those assets denominated in something else on the other chain now this is like the essence of it the going into a bit more detail you see like when someone deposits like this actor on the left deposits maybe some ether it interacts with a smart contract called the custodian and there's a communicator in the middle which is an off-chain component it could be a traditional whatever

server application that is watching what is happening on the chain once it sees that someone has deposited funds in this contract it initiates a debt issuance call to the debt issuer contract on a different chain and this depth issuer here on the right hand side it means some tokens which should be the equivalent of the ether that the first actor put in right so again pretty simple the opposite path so starting from right to left the actor wants to redeem back the ether deposited after having used it for some purpose so it burns these tokens that it got called ac eth it sends them to this debt issuer contract the communicator is also watching the debt issuer

and when it sees that someone has burned these tokens it initiates the fund release on the custodian side so the actor should receive the corresponding amount of eth on the ethereum side so this is depositing and withdrawing now you notice from the previous slides the bridge structure contains like three main components two contracts which are the asset custodian the data source and the depth issuer oracle contract here and a communicator which is an offline off chain component which we call the oracle and there's therefore a huge attack surface when it comes to like the web free space so you have the custodian the depth issuer the communicator any interfaces that they use and the network

itself they could all be subject to attacks and in the next slides we're going to go through examples of attacks for each of these layers and bear in mind that some of these attacks i won't name names because it's not professional but some of them are referring to the hacks that happen in the in the past the ones that are on the one of the previous slides so for the custodian we have something which is called the call relay attack and here depending on the bridge you might have this asset custody smart contract which is accessible by some privileged addresses because they need to manage them somehow and maybe maximize the the profit of the project or

something so what the attacker goal in this case was was to take over this asset custody contract and be able to take funds out of it so the way in which they want they did that was that there was this function that was in the ascity asset custody smart contract called change custody address there at the arrow at the bottom and this function should not be callable from the outside so there should be some access control in place that prevents anyone from calling it but what the attack or like what any user would have would be allowed to do was that they were allowed to call functions of this form right there was a function name

three parameters two byte strings and one unsigned integer on 64 bit so this was something that was deemed allowable from the access control policy because there were just one or two functions which were fine to be called by anyone now the nasty part is that the attacker found a way found a hash collision on some random name that they put together using this signature here so they just randomly compiled a function name and some parameter values which had a hash collision with this function name the way in which this contract in the middle here works this cross chain communication contract it whenever it says call this function it basically hashes the signature and looks it up in a hash table

and due to this hash collision it was the attacker was able to figure out okay if i have this function well it's just a random name there but x x one two three and some parameter values is going to have a hash collision and i'm gonna be able to call this um function which i'm not supposed to call and change the owner of the asset custody to my own address and then i can just take the funds out so yeah that's that's one of the attacks moving on to another attack transaction replay it's again on the custodian and um depending on again the custodian the the bridge that is implementing you need to present proofs

when withdrawing assets so this kind of markle proofs they get issued so let's let's go step by step the first step is that you deposit an asset to the custodian and in the second step the debt issuer sends you the debt token we've seen that on the uh original slide with depositing then withdrawing you do burning the debt token to the debt issuer and in this case the debt issuer gives you a proof that you can then go and send to the custodian and say here's the proof give me my money give me my tokens the the mistake in this case was that the verification of the proof uh didn't take into account one of the

fields so the attacker was able to change one of the fields and resend the proof again and again it was a valid proof but it was different from the previous ones so for each replay the attacker got the same amount until it drained the custodian going on to the depth issuer so in case of the depth issuer the attacker goal would be to bypass the signature verification right and arbitrarily mint these tokens right so the attacker what what they did in this case it was again a very specific implementation of a bridge which received as an input parameter over here not sure you see my mouse yeah it received the signature verification contract address right so this was an input

parameter but it should have been pretty fixed but this is the way in which the system worked they were just receiving this as an input parameter and of course this signature verification contract was unique it was a trusted component what the attacker did they deployed a fake verification contract and they passed that as an input parameter so this fake verification contract said it's always good whatever you do you pass the signature verification and this way the attacker was able to basically initiate these kind of withdrawals without or like this disminting without deposits without actually um depositing any money in the custodian moving on to the communicator layer there the attacker has the goal of tricking

the communicator into forwarding invalid messages and minting tokens so for this particular attack the communicator was watching the custodian and was watching if someone deposits funds in the custodian there's an event which is emitted i'm going to check how much i should emit i'm going to check the address of the custodian is correct unfortunately for multiple withdrawals or like yeah for multiple it was looking only at the first event for the address of the contract which emitted it what an attacker did was they deployed a malicious contract which emits the same events it look the events look the same except for the fact that it's emitted by a different address the problem with the communicator it was

only checking the address of the first event and then only looking for the other events that came afterwards so the attacker basically issued a bunch of fake events from these from this malicious contract and was able to uh drain yeah basically get a bunch of funds that they were not entitled to moving on to the interface level here there's a bunch of attacks which we're going to look on the first is you have this situation where a legitimate user here at the bottom has approved a contract to allow them to to basically um execute some some kind of function call for a particular token and this is quite broad so what an attacker did there was that

they just crafted out of this execute call data generic function they just crafted okay transfer from user to me right so they were able just to easily craft this function call inside of the call data which led to of the legitimate users tokens being transferred to the attacker so the attacker could do this for multiple users who have approved um their wallet uh this this interface spending money from or funds from their wallet in a similar attack where again the user has approved a third-party contract for allowing people to deposit with permission basically here you're allowing someone to spend money in your name it should only be meant for tokens which implement this feature but there are

tokens which do not implement this feature and do not give any warning as to the fact that this function called failed so if someone calls this function deposit with permit into this contract it's just not going to say anything it's not going to return anything and the error was in this third-party contract where they did not check the return value so they didn't check that the return value is explicitly successful they just assumed that if it doesn't complain then it's successful right so missing uh return value validation and this way the attacker was just able to say like hey i'm going to deposit all of these funds from the legitimate user into my account and that's how they got away

with all the funds from legitimate users who approved finally the network layer this is something that hasn't yet happened but might happen in the future there is this thing called the 51 attack which allows you to reorganize blocks and what you can do is launch such an attack on a level one chain then you deposit assets to that custodian contract and you receive the debt token afterwards you take that debt token and withdraw those funds out of an exchange or something you withdraw them transform them into fiat or dollars or whatever and finally you cancel that deposit transaction in step two because you now can reorganize the chain right and depending on how long these steps this withdrawal process

takes you could afford to pay for such an attack because one hour of such a 51 attack on the ethereum main net is somewhere between 1.5 and 2 million if there are sufficient funds an attacker might be incentivized to actually pay this for a certain amount of hours depending on how fast the bridge enables someone to transfer funds to deposit and withdraw so in summary there's a lot of bad things that could happen with bridges we saw things on the custodian layer we saw things on the depth issuer layer i'm not going to go into all of these but basically you might have recognized that these are not totally different from your classical security mistakes like missing

input validation not checking return values and so on right the communicator layer is this off-chain component which is basically watching and triggering smart contracts on both sides and there's a many things that could go wrong we only went into one or two things in this presentation but there's a longer list and probably it's not exhaustive there's the interface where basically it's not necessarily bridge specific but there's a lot of things that could go wrong with allowing people to deposit in someone else's name or allowing external contract calls and then finally the network layer there's the 51 attack but there could be other problems as well finally just want to say we're hiring we offer great packages and if you're

interested in this kind of stuff finding bugs and smart contracts we'd be happy to to get in touch with you thanks so much [Applause] so do we have any questions for sebastian that we have a runner coming forward so it looks like a lot of stuff you mentioned is like you said input validation stuff like that that could be remediated with like good programming practices um is my assumption correct that if you do all these correct then the problem is the custodian and you there's no way to do that one trustless because it is off chain so can we ever get rid of and not the communicator because that is option is there ever way to make that component

trustless as well or will that always be a linchpin in the entire setup how and there's no way to secure it even if all the rest is perfect yeah that's a very good question thanks so this architecture which we've mainly looked at during this talk is something which is being used generally right now there are projects out there which are taking a totally different approach they don't use this architecture they use something else where they don't have this kind of trusted off-chain component and well those kind of things are not yet in production but they are working towards a solution which does not does not have this kind of um trusted third party which is off chain all right

if you want we could i can give you more more details uh in the break and another question if i may um sure for example in in terms of web applications we have stuff like ports rig academy do you have equivalents for like if you want to learn about smart contract blockchain is there any like playgrounds that are easy to get into for someone that is not familiar yet totally yeah there are multiple actually there's things like um well i'll call them offline ctfs because they are always going on right you just have like a playground where there are some contracts that you can just exploit toy contracts and there's like multiple um difficulty challenges right and

there's like things like you know damn vulnerable linux sure yeah there's something like that for smart contracts or google damn vulnerable ethereum or yeah then damn vulnerable defy it's called yeah yeah so um there's there's all these kind of things and also there are training programs free of charge because there's so much interest in um getting more security experts in this field that people are no longer charging for training everything is sponsored by all these projects which have suffered such hacks and and like the amount that they need to sponsor these academies is nothing compared to the amount that they could lose so everything is like sort of free of charge so you can pick it up really

easily okay thanks thank you please come up with your question

hello uh for someone that is completely new to this type of hacking i have a question how much of hacking smart contracts and and blockchain and cryptos is about actually cryptography and how much is about more of these type of logic books that's a good question um i think probably more than 95 percent is about this okay and probably like five percent is about the crypto because um the actual cryptography which is being used that is being actively researched by um many research groups at top universities and and many of the world's leading cryptographers so the actual hash functions encryption um proofs and so on everything is based on many many years of research from

universities and now we're just like working at implementing applications on top of that okay so we can say something like if you'll invest more time there learning about solidity you are uh doing a very better investment that by learning i don't know cryptology something like that um depends right um if you're a brilliant cryptographer and you might invent something amazing i'm not then it might be worth doing that but i think like if you don't want to do that then definitely learning something like the solidity or other programming languages being used for smart contracts is a very good return on investment okay thank you thank you

any other questions

uh yeah so i have a bit of a controversial question so your company is like doing these audits for the contracts so you're making money by doing the audits and stuff but like i've read this idea that it's something like a bit like a reverse but bounty scheme because in the end there is an incentive for you to keep like some kind of bug in the contract and then in a blackhead form exploited so you know what i mean yeah i do i do totally and so it gets philosophical in everything but like you're part of the industry and what is your thinking about this how this could improve in a way where it's better for everyone

like your auditors can do your job others can do their job and everybody can trust the thing in the end yeah no that's a very good question thanks so i think it's always this kind of trust issue when you're working with a security service provider it's not specific to the space it could be like when you're pen testing a web application right for any company right you might withhold some kind of attack that you can then use to exploit of course like maybe in web 2 the damage you do is not directly financial but it's reputation damage or so on but basically the idea is that what we're doing if we were doing that if we were would

be withholding and exploiting there would be a huge reputation damage to the company itself and it would cease to exist right we are well in relative terms a young company like we've been around for five years and we have a reputation for being one of the best so if you have a like the longer your time span is and just keep in mind the oldest auditing companies in this space are like five six years old so there's no uh there's no others which are like have been around for longer doing this specific thing there's been there's companies who have pivoted from doing traditional security to smart contract audits and they have been around for longer they

have a longer track record but definitely this kind of track record and knowing that the company has been around for longer helps with this kind of trust issue because if let's say you somehow manage to um trick someone in trusting you and you do this kind of thing you you withhold an export you exploit it probably in a few months to a year your company is no longer going to be trusted by anyone because your audits always get hacked you know what i mean so that's what i think the way to balance this

okay any other questions okay i have a curiosity question so suppose i wanted to exchange a large sum of money and i knew it was going to be a cross blockchain kind of exchange um should i just avoid that altogether or what can i do as a consumer of this entire process definitely get advice from professionals and don't just do it um sort of on your own because there are way more problems sort of attacks economic attacks that someone could use to do an arbitrage on something that you're doing right so if you're exchanging one token for another you have a lot of parameters which might be like the margin that you're willing to lose in the exchange and if

you don't properly set that margin you might end up being arbitraged by there's an army of bots out there just looking for these kind of opportunities so definitely ask someone for these kind of settings right and then like this is in addition to all the security issues that might be there right so i'm not saying there are definitely ways to do that i've done well i don't i didn't transfer large sums of money but i've done that myself with no let's say issues afterwards right so it's possible but you really need to to uh be careful because like we've just presented let's say i don't know six seven hacks but keep in mind there are like dozens

and dozens of bridges and some of them have never been hacked yeah exchanges exchanges on their set themselves are bridges as well they're just a different type of bridge they're not from chain to chain they're from bank account to chain super any other questions then all right thank you so much sebastian thank you