Not Quite Water Under the Bridge: Review of Cross-Chain Bridge Hacks

Transcript

hi everyone my name is John gorsny I'm a head of L2 scaling at quantstamp so I'm interested in all things scaling I apologize for the bait and switch um there was some last minute change up for um who's presenting and what we're presenting um in terms of Quant stamp here at this conference so I know your promised discussions about Flash loans and my apologies I'm not going to talk to you about that today um it's time to talk to you about bridges which is um kind of nice because you saw one of the hacks actually in the last presentation whether or not it was sort of addressed as one um so my apologies if for the bait and switch once again so this is some work we've been particularly interested in a bunch of us here at Quantum have worked on this and you may have seen this at other uh

conferences but uh it's a talk that's going to go over a bunch of hacks that have happened um in Bridges bridges are our super critical component of most of our multi-chain ecosystem these days and this you know talk is particularly relevant because they keep getting hacked um there's a lot of money here at lost or possibly at risk or that was at risk for a lot of these Bridge components and so understanding what went wrong can help us prevent these things from going wrong again the second time the third time etc etc um so obviously yeah lots of money in play here for these these Bridges and um a lot of different ways to sort of um exploit and attack them and we're going to go over some of those in this talk

so first we should all be on the same page as to what a bridge is a bridge essentially is just a way to get assets digital assets typically cryptocurrencies or you see 20 tokens et cetera Etc from one blockchain to another blockchain um you know you might have Bitcoin you might want it on ethereum so you can earn some nice defy yields on it or you might want to take your whatever coin onto whatever roll up so that you don't pay as much in gas fees or um you know any number of use cases you can consider bridging nfts or even cross-train calls and all sorts of things like this and so essentially we're going to be talking about the ethereum ecosystem here because it's the most sort of familiar one I think for a lot of us and it's the most General in the sense of

good support for smart contracts that we've all talked about and we're going to talk about bridging assets between ethereum and some other chain we're just going to call it another chain we're focusing on the bridge not the chain itself so it doesn't particularly matter how do Bridges work well they can't move an asset strictly speaking right uh on either on ethereum is not the same as an ether on say arbitrum they're going to be similar they're going to behave similarly but they're not strictly speaking the same uh ether belongs on ethereum and so you might wrap it to bring it onto a roll-up or onto another blockchain or wherever you want to put it right that might be a centralized exchange might be somewhere you're rooting it somewhere and so how does this work well Bridges typically have

three main components they have a custody system which is on ether which will take your or sorry on ethereum which will take your ether and lock it up and then there'll be some Communicator aspect which is an off-chain protocol typically or piece of code that runs watching ethereum says oh look someone put money in into this custom uh custody smart contract let me make it somewhere else and it's that sort of making of the second part that makes these um additionally sort of susceptible to attacks and vulnerabilities and what what it does is it creates some representation of that asset right and so when I say ether is not the same on arbitrum as it is on ethereum technically speaking that might be true but you know the representation should be more or less the same or you know on

any other roll up or any other system where you want to treat ether as ether and so what we'll do is we'll have this Communicator system watch the custody contract which is also a nice Target for a lot of people with a lot of bad intent because they can just you know look at that and say oh there's a whole lot of ether in there let me see if I can get it out um then we'll see the the communicator which is an off-chain protocol because it needs to talk between two chains which is something ethereum currently cannot do uh relay this message to the other chain and say well actually someone over there locked up some ether so let's create some new version of ether over here for this person on the other end and you know ideally that is a standard that as well sort of accepted

on that other chain you don't want every Bridge coming up with its own version of eth for example because then trading each becomes an annoyance and there's Arbitrage issues and you know technically there's more contracts you may have to deal with et cetera et cetera but essentially you have this this process of I deposit somewhere some system offline off chain does something and the other chain then gets a message from that off chain system and mince me some digital asset that is representative of the one I locked up to withdraw from a bridge system you sort of go the opposite right if you're taking money or eth off of um arbitrary and you're trying to bring it back to to ethereum you do the the opposite process you deposit in the custody on the

um the chain that you put your assets onto is the other chain the roll up Etc and you might not be locking it out because if it's an asset that's actually native to ethereum you might be burning it to sort of release it back into the wild on on ether but essentially the process is reversed you do something on one chain some off-chain system watches both chains picks up the signal and relays that signal so that's what what a bridge does in general so more or less just trying to get things across so we can use them in different situations for different use cases and so the structure really boils down to three things two sets of smart contracts one on each chain and this cross-chain component that relays messages between them because currently they can't natively do that at least not on ethereum maybe other chains support

native crosstrained communication ethereum doesn't and so as a result you can attack every single one of these and turns out most of the time every single one of these has been attacked um we're also going to talk about some specific cases like the network itself can you try to do something with ethereum if there's time I don't think we'll have time uh and some some things like the interfaces of specific things you're trying to transfer so in particular this interface actually covers the attack that was discussed in the last um Talk where the permit is just a fallback that doesn't revert because you can you know trick the bridge into making that call for you and you see all the funds as was sort of discussed okay that's a that's a mouthful there's a lot let me try to slow down a little bit and

let's go through at least one or two of them in great detail I definitely have more than I have time to present so if you have questions please ask me and similarly if you wanted to hear about Flash loans but you're disappointed I'm not talking about it please ask me at the end all right so what's the first one well here we're gonna try to attack the custodian so this is the Smart contract that lies on your layer one chain that you sort of initiate initially had the assets on so ethereum in most cases and we're going to say how can we sort of get this to change um well one way to attack it is to look at a lot of these Bridges and say well although the custodian is the key component in this bridge usually what they will do to sort of modularize the

system is say well I have a custodian responsible for taking funds and the interface for for users and with other smart contracts for composability but you know if I'm locking up funds let's put that into a vault contract that's just beside my custodian contract and this way as long as the Vault never does anything wrong all of our funds are totally fine and the Vault will be managed by someone else and so you know I don't have to worry about the security of the custodian necessarily as much because maybe the the Vault itself is responsible for this and if something goes wrong I can blame the Vault operator um the difficulty here is well what happens if something goes wrong with that that Vault operator right can we change the Vault operator and so this is an attack that did actually happen I'm not going

to name names and say you know who it was um but at some point this clever attack was pulled off and so what happens is you have this custodian contract which is the one that does the cost chain calls Etc and if you were to deposit something into it it would put that into a vault and that Vault would have a special admin an owner a privileged address that is responsible for possibly managing that especially helpful if your Bridge does stuff like invests in defy while it's sitting around I'm not sure that that's what's going on here but you know it's a plausible use case and so one way you might want to try to trick this is to to trick the bridge into giving you rights for that privileged operator at access uh on that vault which would be really bad because

then you can just do anything you want on on the vault and so how can we actually do that well we can maybe be clever if the bridge is got some some issues and um if the bridge is sufficiently Advanced you're you're also able to make cross-chain function or cross-chain function calls yeah so I can call a function on arbitrum with a transaction through ethereum maybe on on some particular bridge I'm not sure that's the case and I'm not saying this is an arbitrum issue uh but basically any Bridge from any one chain to the other can can receive as input um a function that I want to be called as soon as my assets are transferred to the other end and so I get to specify

whatever it is because I might be able to say immediately put into a D5 protocol and I get to arbitrarily choose what this comes up uh this is because it's necessary to be called to be able to call anything and so what I can do then is I Can Be Clever uh what if the function I want to call is the function change privileged address uh you know in in general not an issue maybe I own some smart contract on the rollout that I'm using or the other blockchain or whatever and I want to change the privilege address I'm allowed to do that um cool so I'm going to do this and I encode this in in standard ethereum ways which is to take a hash into truncate most of it just keep the first couple of bytes around and it's going to call on

some contract I don't really care which one in this case if I'm being malicious because what I'm actually going to try to do is now take this message which will have been relayed onto my other chain and now been signed by that change operator as a legitimate call and I'm just going to replay this on the layer one so what happens is now I apply that sort of oh I I solve this transaction occur on on the other roll up and it was done by the privileged operator of that roll up or of the layer one that's bridge two or whatever and pass that information back to the custodian contract and so now from the custodian contract point of view someone who had the right permissions actually you know signed off on the permission to give me privileged access to the Vault

and boom it's done um so this was a little bit clever because a you need to find a function that matches correctly to sort of handle some specific cases but because of how ethereum encodes function calls it wasn't particularly problematic and it could be done and this did happen another similar related attack is to sort of say well if people are signing off on cool things can I modify those cool things in such a way that I can use them twice or three times or as many times as I want and turns out yes sometimes you can there was another incident where someone came up with this whole process you know the Ridge across and ridge back by burning and the burning happened with a proof of burn that in some cases on the source blockchain so where the custodian asset

is uh some bytes of the proof were just not checked and when bytes and proof aren't checked you can fill in whatever you want and Replay that message over and over again so instead of making a single withdrawal people were able to withdraw several times obviously a problem because one proof should be one withdrawal problem okay so those are two two attacks that actually happened um on custodians so this is the the layer one sort of ethereum end of things but we can Target these other issues as well uh one way that might be feasible to do this is to say well I want to Mint whatever I can on the other chain because if I can mint arbitrarily on my destination blockchain then you know as long as it's a legitimate minting I can

just legitimately transfer it back and there's no no issues so I'm just going to trick it trick the system into minting as much ether as I can on whatever system I'm talking about and this has happened unfortunately it could happen so what we want to do is we want to make sure that the debt issuer gets tricked and so how are we going to do it this time well here what we're going to do is we're going to look into the dead issuer and say well how does a debt issuer actually work well in some cases maybe the verification Logic for issuing some type of debt differs from other types of debt so in particular the logic to verify that I've locked up ether might be different from the logic required to sign off on me depositing I don't know yawn coin whatever you want

right your own stuff and if it's a decentralized bridge you might be able to Plug and Play This any way you want you might want to be able to say the bridge will support arbitrary erc20 tokens or whatever so anyone can plug in these verifier systems and so the debt issuer on the other side will be configured in such a way that when it wants to sign off or check that a message has been signed that oh yeah you can mint this this debt wherever you are um you know there might be a way to add those sort of publicly and that may be a feature not a bug but if I put in a contract that's sort of clever and again there's a lot of details missing from this because I definitely cannot go through everything in 20 minutes for any one attack let

alone several um if I put in a contract on the other end of that bridge it just says any signature is good you always mint stuff well I'm pretty happy because now if I can get the the debt issuer to call my verification contract which allows me to say anything is true then cool I'll just mint whatever I want um and so that's exactly what happened in one situation here and that's kind of clever and for an example because I am running out of time and uh yeah I think what we can do for the last one is is this is the one I want to talk about yeah the last one I want to talk about is attacking the communicator which is sort of maybe the most straightforward in a lot of ways because it's not a smart contract you sort of expect it to have issues that are more

traditional of like a web 2 system you might be able to attack it with pen testing flaws and things like this right it's not a smart contract it might be a closed system that you don't have no actually in info on how it works because it's not a smart contract but um the key takeaway here is that a communicator because it talks to different chains and reads from off chain to right to the other chain right so if I'm bridging from ethereum to I don't know Bitcoin um you know it's got a read data from ethereum that Bitcoin doesn't have and essentially it's an oracle on that that chain and once things are oracles we use our polluting oracles until we have better oracles and certainly what you can do is you can pollute them with the minimal amount of effort in some cases um because of how technically

challenging it is to do some things on ethereum in particular on ethereum it's really annoying from a technical point of view to read events emitted during transactions not saying it can't be done but you know it's it's non-trivial there's not just the cause of read events or at least at the time when this was going on certainly wasn't the case and so to understand what events are admitted during a transaction uh say outside of ether's gain or in your own custom stuff you have to do some math people don't like doing math and so what a surprise people got it wrong and so what what happens here is the communicator works by saying oh there's an event emitted on ethereum the yawning deposited ether Jan gets to Mint ether over there cool what I can also do

though is make my own smart contract that calls the smart contract and it just submits that same event with the same name and the same address 20 more times and the communicator will actually say Well it has this event and it's interacted with my smart contract so it's Gotta Beyond depositing 21 times and now I get to Mint 21 times on the exit side of the chain and then I Bridge it back naturally and I get all my money which is kind of cool this was a really clever attack um but yeah it's a way to trick the stuff other things you can do if you are very malicious and clever uh you can attack the interface of the thing you're trying to bridge uh where to solve this with the permit function on erc20s so if you

have a fallback it always fails this can be definitely a problem these two slides are meant to talk to you about when you should revoke approvals because every time a bridge hat goes on the first thing you hear on on Twitter is revoke approvals and no one really tells you why unfortunately due to time constraints I'm not going to tell you why either but if you ever see it you definitely can uh and and it's because of attacks like this the one that was thought talked about the last slide saves me some time where the fallback just never fails which is kind of nice and um I think that's yeah this one so we can go over it again just very very quickly uh basically what you do is you realize that if the function never fails and it's the bridge calling the function it's actually the bridge during the

stealing and so you can just sort of rely on the fact that the function never reverts and the user already approved the bridge to take those funds and then the bridge takes the fun and even if you're not personally gaining you're certainly shaking confidence in the entire system and the bridge and you're doing a lot of damage to a lot of people it's really kind of annoying other erc20 issues do exist um uh but we don't have time to go into them and if we had lots of time we could also talk about the potentials of like problematic big picture attacks like well what happens if I Bridge things and then my layer one has a reorg and what is the cost and penalties of actually doing that the time this was written it might have only taken about a million dollars to rent ether or rent enough

mining power in ethereum to roll back and reorganize layer one but if you're already done the bridge on the other end of course you know maybe I'm bridging seven million that isn't supposed to be mine and then I just roll it back and now I have you know seven million minus one or whatever um these are also possible thankfully this one has not happened yet and I'm hoping it never will and um there's some mitigations in summary a lot can go wrong I'm running out of time uh so a lot can go wrong if you have any specific questions or you have a bridge concern please talk to me or anyone at quantsnip and um yeah thank you [Applause]