EVM-to-EVM chain bridges: The Good, The Bad, and The Ugly - Martin Derka

okay awesome so once again thank you very much for the introduction uh my name is martin i'm a senior research engineer at quan stamp and uh this talk is based on a joint research with my two amazing colleagues martin ed and alex and we will be talking about bridge hacks so the very first slide doesn't require too much comments throughout 2021 and 2022 bridge hacks costed us 1.75 billion dollars so uh if you thought that the flash loan exploits of defy where bat this is i guess the definition of pure evil uh so let's take a look at what a bridge actually is when users are bridging assets from one chain onto another it's sort of kind of magical right i have some eath and i'm going to ethereum maynet i'm going to you know somehow send it to the bridge and suddenly it shows up on another chain but that's actually not true there is no such thing as ethically showing up on another chain because eath is the mainnet asset right so it cannot just like make it over so what really happens is that when i'm bridging assets i am locking them on ethereum mainnet in a smart contract that is called the custodian or i will be referring to as the custodian and then there is some off-chain component it's a active agent that is watching what eth was locked in the custodian and then it's talking to another smart contract on a different chain the target chain uh which i will be calling the debt issuer and this debt issuer is going to issue to me some tokens that are representing the debts that a custodian has towards me when i want to bridge my assets back i go to the debt issuer i burn the debt tokens again the communicator component is watching it and it will instruct the custodian to release my original assets back to me on the mainnet okay so this is how bridges work if you think about the system uh in general we are actually talking about two main components here right we have a pair of smart contracts it's the asset custodian on one chain and the debt issuer on the other chain and then the communicator is nothing else but actually an oracle right because it's watching the state of the world somewhere and that it's talking to some chain telling it hey this person you know did something in the world so this is how we will be thinking about it all these components can be attacked as i will show you i'm going to give you an examples of bridge hacks that happened throughout 2021 i will be giving you an example of an attack on the debt issuer on the custodian on the communicator then i will be talking a lot a little bit about a different type of attack that also involves a bridge but it will actually be an attack on the token interface and then if i have time i will play a profit and i will show you an attack that didn't happen yet but in my opinion it's just a matter of time before it does so let's hop into it first we will talk about the debt issuer so the debt issuer is that smart contract that sits on that other chain right and it's issuing the debt tokens that i can later redeem for the original assets so if i am an attacker my main goal would be to convince this debt issuer that it should issue to me debt tokens quite arbitrarily and one possible route how i can do that would be to convince the debt issuer to bypass the signature verification from the communicator because uh when the communicator instructs the debt issuer that it should issue to me those debt tokens uh that instruction is nothing else but uh a smart contract method call right and in this particular hack that i am referencing this smart contract method call would be accepting some data that's who logged their assets on the main chain and how much they locked in which means how much they should be receiving on this other chain and what was also present there in that particular hack that i'm referencing was a reference to another smart contract that this debt issuer could use to confirm the authenticity of this instruction meaning that this uh instruction was actually signed by the communicator so somewhere there in the system we had this component the signature verification contract the debt issuer would say hey i just you know received this message is this really true like was it issued by a valid communicator and this smart contract would say yes it was correctly signed or not so what the attacker did to exploit such a situation was that they first deployed a fake signature verification contract which was very simple it would just say everything is valid man you know we are good and then the attacker sent a transaction to the debt issuer referencing this fake signature verification contract and the data saying hey i should be issued so many in so many debt tokens and the fake verification contract did exactly what it was made to do it said yes this is valid and uh therefore the debt issuer was able and did issue the attacker bunch of debt tokens that they would again bridge back to the main net and exit the whole system with lots of lots of profit so this is how you can attack a debt issuer let's take a look at the custodian so the custodian is that smart contract where i am locking the native eath right or some native assets so when i want them to be released back to me depending on this on how this whole complex system is developed the custodian usually expects some kind of a proof that i burnt my debt tokens and will not use them again right so the attacker's vector here would be to craft proofs that would pass this verification process by custodian and in fact in the hack that i am referencing there was a bug there was a flaw in the proof verification process which enabled the attackers to do so the proof verification process was simply ignoring certain parts of the proof which allowed the attacker to modify certain bytes in that byte string and produce more and more and more proofs that were valid for releasing assets by the custodian so if we look take a look at the schematic we have the attacker the attacker started by depositing assets into the custodian which led to the attacker being issued some debt tokens on the alternate chain then they would take those debt tokens and they would burn them which led to the debt issuer providing a valid proof that they burned some debt tokens right and so then the attacker took those proofs and submitted them to custodian that was all honest but then they took that one proof and started modifying those bytes that uh were being ignored during the verification process producing different proofs that were still passing their verification sending them to the custodian and exiting with more and more money that actually didn't belong to them so that's an attack on custodian now i want to talk about attacks on the communicator so that's that like off-chain component that has some privileges to instruct the debt issuer to issue debt tokens and to instruct the custodian to release assets back to users right so what we want to do in here is to fool the communicator to actually send messages and instructions to these two other elements based on some data that are not true so in fact we are polluting the data source of the oracle right because this is an oracle and what happened in this very particular attack that i'm going to reference i actually really like it because it's very clever uh we had a communicator that was watching the custodian right and when the communicator is watching the custodian it actually means that the communicator is parsing all the transactions that go to the custodian and out of those transactions is cherry picking the deposit meth the deposit events that are being emitted during the deposit so what the attacker did here was that they deployed a malicious contract which made the deposits to the custodian so that was the transaction that the communicator detected but on top of just uh depositing into custodian it also emitted whole bunch of events that had exactly the same format as the events that the custodian was emitting so same name same parameters you know i deposited eth without actually depositing it at all so then the communicator detected this transaction it passed out all those deposit events from the transaction but only one of them was honest the rest were fake events and it would just issue a whole bunch of tokens based on those fake events so this was our attack on the communicator so all the attacks that i have just now referenced they were just an example of a few you know throughout the course of the past year we had many many many more uh the one thing that they had in common was that the damaged party there was the bridge right it was the assets that were locked in the custodian that eventually ended up with the attacker what i'm going to talk about now is an attack where the damaged individuals are actually the users of bridges so if you are on crypto twitter every once in a while you can like see this message hey if you have approved erc20 tokens to this particular bridge you should go ahead and immediately revoke your approvals right and all these uh messages they insinuate that there's something wrong that that bridge can like take away your money right uh but they never tell you what is wrong and why that actually is and how it how it can even happen so now i'm going to explain to you how this can actually happen so imagine that you are a user and you want to use a bridge with your erc20 tokens for example you want to transfer dye from one network onto another network right so what needs to happen for this uh transfer to work you first have to go to the bridge or to the token actually and approve the bridge so that it's capable of calling the method transfer from and withdraw tokens from your account and because gas is expensive most of front ends these days will ask you to provide an infinite approval for the bridge to be able to withdraw tokens right and then you go again and issue another transaction which will actually instruct the bridge to withdraw those tokens and it will do that it will log them in custodian and issue them on a different account but bridges they're actually very complex components they cannot only just bridge assets that would be you know a little bit too simple what they can do is much more for example they can perform some cross chain uh con smart contract calls and you know various other things right and uh there are various ways of implementing these additional features and one of ways is uh providing the bridge smart contract with kind of a generic method here i have called it execute that just accept some byte string some call data byte string and what the bridge smart contract will do with this buy string it will parse out uh what it should be doing so what smart contract it should be calling what method in that smart contract it should be calling and what parameters it should pass into this uh method call so what an attacker can do they can actually instruct the bridge to talk to your token smart contract so that would be the die smart contract to call method transfer from with your wallet's address the bridge as the destination right and with the amount that of tokens that it should withdraw so the bridge will do that because it has infinite approval from you to use your tokens it will just be able to withdraw as many tokens as you own uh it will lock them in itself then it will see oh yeah the attacker was actually able to make a valid deposit i have the tokens right they are here so it will talk to the other chain and it will issue you the depth tokens on the other chain you are out of tokens the attacker has the tokens on the other chain they can bridge them back they're gone so uh you can prevent that from happening to you by revoking approvals uh therefore you see on twitter those messages that you should be revoking approvals that's one way how this can happen there is actually also another way which i will also talk about which is based on a feature called permit so permits are actually not part of the erc20 standard but it's sort of an extension where permit it's essentially a signed message it's a message that you have signed with a private key with your private key and you have given it to somebody and they can present this message to any kind of smart contract to prove that they have authorization to spend your tokens so the intention how this would be used would look somewhat like that uh i give permit to somebody that somebody that caller will go to a different smart contract and say hey i have permit from martin to spend his tokens so the smart contract is going to take this permit it's going to talk to that particular token contract that implements the permit function and it's going to double check that this permit was properly signed and that it's valid so it will call function permit which should return true if if sorry which should not revert if the permit is valid and revert if that permit is not valid or if permit function is not implemented at all and then if the smart contract sees that the permit is valid it can redeem the permit for an infinite approval and then it can use transfer from to withdraw martin's tokens right so this can again be exploited in the connection with bridges if your token that you are trying to bridge is implemented a little bit unfortunately because there are tokens that do not implement the permit function but on the other hand they have non-reverting fallback function right so fallback function is that catch all function that is getting called when you are trying to invoke a function that is not implemented so again assume that you are an honest user you have you know bridged your unfortunately implemented token that has this non-reverted follow-back function through a bridge which allows uh features where users can deposit tokens via the permit procedure so you have provided infinite approval bridged your tokens into another chain and now attacker comes and calls this bridge and provides it with a permit it provides it with a permit that is garbage it's just like you know bunch of bytes it it's not even properly signed whatever so this bridge is going to take that permit it's going to talk to that unfortunately implemented uh smart contract of the token that has that non-reverted fallback function but doesn't implement permit and it's going to check by calling permit whether this uh this uh permit is valid and guess what that non-ver non-reverting fallback function actually does not revert so it is going to assume that this garbage permit is a valid permit then it's going to try to redeem that permit with the token contract for you know infinite approval and guess what that method for redeeming the permit for infinite approval is not implemented so it's going to go to the fallback which is not going to revert right so it's still assuming that everything is good and then it's going to call transfer from and it's going to withdraw uh your tokens so this is how you will again lose and you can save yourself by revoking approvals to the bridges so all of these attacks happened in the past sometimes even repeatedly now i will be talking about something that didn't happen in the past so i said before that communicator is an oracle right it's reading some state of the world from somewhere and it's projecting it on some chain maybe on that side chain maybe back on the main net it doesn't really matter so in the real world when we have oracles uh usually the state of the real world doesn't change right if i crash my car it's crashed there's no way to undo it but when you're reading state of the world from blockchains you actually have to care about finality right there is always a chance that a longer chain is going to appear and roll something back that's why when you interact with centralized exchanges in other systems you have to wait for 6 12 32 blocks before that system will do something so imagine this i will launch a 51 attack on a source network you can think about ethereum net but you can also think about a different network with some weaker security guarantees then i am going to take a substantial amount of assets and i'm going to lock it in the custodian that will yield me some debt tokens on the side chain that i'm going to take those tokens from that other chain i'm going to go i'm going to bridge them back and the custodian will release back to me the assets that i have deposited and then i will roll back that first transaction i will unwind this 51 attack in a very specific way that cancels that deposit transaction so the bridge will never have received the cast assets in the custodian but it will have released to me uh the assets that it held so that you know can cost a lot of money now you can come back to me and say well but 51 attack that's very expensive according to crypto 51. app uh one hour of a 51 attack costs 1.5 million dollars bridges usually hold much more than that uh and in fact we have fast bridges where you know one hour is kind of an overkill you will be done in less than you know 15 minutes or so so that's the prophecy i believe that it will happen one day in summary uh i'm running out of time so we have identified whole bunch of things that can raw that can go wrong with bridges they are really complex i have roughly 20 of them in here and because i don't have time i will be happy to talk to you about them in the kwan stem booth that we have upstairs at the location p25 it's across from across the like alley from beanbags on the fourth floor so uh yeah please feel free to drop by quan step is also hiring so if you like digging into smart contract or blockchain systems exploiting them looking for exploits please talk to us as well and yeah thank you for your attention