Breaking Bridges - An Incomplete Sampler of Bridges Hacks

Transcript

right hi so uh so the previous talks discuss how bridges can be defended and those are great talks so um I'm going to talk about how a Bridges how bridges break just to add some color to it understand how it can happen so I'm not going to talk much about how bridges work because this was already covered I just mentioned that every bridge in every bridge there is someone moving information from one chain to the other and guarantees its correctness by some mechanism so uh let's talk about how it breaks it took in the past couple of years we've seen many Bridge hacks and it and the reason is always that information

that the wrong information was conveyed to one of the chains so the reason can be um the reasons can be split to a few categories one could be insufficient or improper validation either insufficient or just relying on relying on some Source such as another smart contract without understanding its full implications another one is another common one is malleable proofs meaning that the messages can be replayed that there was a correct message but it is played more than once and then there's a making wrong assumptions about one or more Network

and of course finally there's the uh there's the good old key compromise or validator compromise so what happens when a bridge breaks the obvious answer is funds get stolen user funds investor funds depending on the model but there's more to it for example for example if assets get minted on one side without assets locked on the other one and the bridge goes out of balance if you have interesting implications on collateralized protocols and it gets even more interesting when it when it comes to a message Bridges like Nomad because then the because then

other protocols can use it in order to can use it to communicate cross-chain for example to have cross chain governance where a contract can be upgraded on one chain through a vote on another chain and in such case if the bridge breaks then then entire protocols can get hijacked so let's go through a few a few examples we start with a with a trivial one so lifina li-fi is uh it's a bridge aggregator and as such it lets the user it lets the user select which select the path select a route

technically that the user gets to a gets to the side which contract we which function in which contract gets called the the user controls the call data and the target for a for li-fi and it's mentoring it's meant to call Bridges but what if it calls a different contact for example what if it calls what if it calls a token contract an erc20 contract and tells you to transfer assets from the bridge itself so this is exactly what happened here [Music] and so that was a relatively simple attack another interesting example was a multi-chain or formerly called the any

swap in any swap tokens get tokens get wrapped on the way in and unwrapped on the way out and the wrap token happens to support the permit method in order to in order to facilitate single transaction net transfers so the contract expects to get expects to get a token that supports permit and permit is uh and permittation is supposed to reject is defined that it will always reject um always revert on a if the signature is bad if essential is incorrect so it should be safe

but note that the user is the one providing the token address so the user could deploy a contract where um deploy a contract that returns a token with no permit support and why would that be bad so we said that uh permit should revert but the permit should revert but it but if it's not defined if permit is not defined in the contract then the result is undefined and if it happens to be uh also if it if the contract happens to have a fallback function that does not revert then permit actually always

succeeds it becomes a no-op and it turns out that there are some popular tokens that satisfy this requirements such as wrapped if anything now we can see that the user also controls the from address so the user can decide which address to use and if it happens to be an address that previously approved the such token in order to use a life in order to use any swap then the contract can can withdraw can withdraw any number of tokens from this address and that's what happened here thank you

so in this example we saw we saw Reliance on uh we saw a lands on an external contract for checking for the truth and it was actually a user provided contract which is generally a bad idea okay nobody is a particularly interesting example because as I said it's an optimistic bridge for passing General messages not just tokens so it allows the so it allows cross-chain communication for protocols that use it such as governance messages and of course the transfer of assets and the way it works is it has validators it has validators who attest

for American Roots a cross chain and then the user proves they proves the message against against such a milk root so in July this year the Nomad contracts underwent an update before that they actually had a correct they actually had a correct check that that wouldn't be vulnerable they checked for a they checked if the hash existed and if the hash If the message doesn't exist then the result would be zero and the process would fail after the upgrade in July it became possible to call acceptable route with zero

and if we look at acceptable route we see that we see that it doesn't check for zero all it checks is that the entry exists meaning that it has time a non-zero time and here's how the contract was initialized so after the upgrade they call this initialize and and it seems that they passed zero so zero so zero was inserted to confirm at and now it has a non-zero time it has one what this means is that any message can any message can now be processed without proving it yeah so now it's uh so now it's possible

to fake messages and what happened during the what happened during the attack so the attackers started using such messages yeah started using such messages in order to move funds to it without fans from the bridge and this is a but in but uh what's interesting is that instead of just doing it through flashbots and trying to drain it as soon as possible the attacker actually used the public main pool and started which which means that Mev Bots automatically started they started sniping this transaction and replicating it am so so all of a sudden thousands of addresses are withdrawing from the

bridge and most of them are automated Bots so this makes it quite difficult to know which one is the attacker and which ones are automated Bots I don't know if that was uh then if if that was what the attacker meant to do but the result is quite interesting so the reasons here where uh first of all the separation the needless in my opinion separation between uh between proving and processing and then an upgrade that created insufficient validation and finally and finally a wrong initialization calling the initializer with the bed parameter now it's interesting to note that the

bug in the new code was not exploitable in itself and adding 0 also is not exploitable in itself what happened here is uh the combination of the combination of both made it it's what made the attack possible and curiously this is not mentioned in any of the postmodiums I've seen I think it's a it's an interesting combination right now with the help of optimism I'd like to demonstrate two types of two types of network level risks the bridges have to live with so one of them is a great bug reported

by Sarah to optimism um we can see that when a bridge when a bridge makes assumptions about the network and then and then something breaks the network level the bridge has no way to defend itself so optimism and optimism used to have so optimism is based on a Geth on the Geth ethereum client with some modifications one of the modifications used to be that the representation of ether was not as a part of the account but as an ELC 20 contract and then all of them and then all the op codes were modified to were modified to use this representation well all except one self-destruct so

when a contract self-destructs the last act the last Act is to move the funds to move the ether to another account and they move the fund but they didn't but they didn't zero the balance in the in the destroyed account so this means that after a self-destruct the funds exist twice once in the destructive contract and the other is in the is in the others where it's sent to now if the contact was created using the create to op code then it's possible to recreate it's possible to recreate the contract so an attacker could repeatedly create the contract and destroy it thus minting an unlimited amount of l2a ether

so in this in this example we see that the basic Assumption of no double spend was broken and it means that that every bridge would be exposed to such a to such attack with all of the assets first of all the entire the entire ether Supply on layer one in all the bridges would have been stolen by transferring a lot of L to if out and then the attacker will probably keep keep minting I keep minting more L to if in order to use it to buy all the tokens from all the dexes on the network on the L2 Network and send it all out for the bridge so luckily no damage done it was

reported by saurik and fixed by optimism immediately now a another kind of another kind of risk is related to consensus to assumptions about consensus it was previously mentioned here that um uh that consensus behaves differently on different networks and in particular on optimistic rollups so Bridges have to assume finality within a relatively short time it differs between Bridges but at some point they need to decide that something is final and release assets on the other side and on optimistic Roll-Ups the transactions are submitted by a sequencer the state transitions are

submitted by sequencer and what stops the sequencer from cheating from submitting from submitting a wrong State transitions is the fraud proofs of fault proofs so and therefore there's a seven days window uh to uh to to prove that and in case of a fraud proof or Fort proof it causes a it causes a reorg can be a long-term reorg where the transaction where the bed State transition gets reverted so a bug in the proof system could cause a selective reorg up to seven days in the past and since Bridges assume a faster finality

it can be it can be quite disastrous for a bridge so uh so I found so in ovm1 in optimism's first implementation I found a number of such bugs each of them allowed me to edit to edit the result of a ton of a past transaction I submitted up to seven days back foreign makes a makes it possible to grab all the assets from all the bridges up to the up to some multiplier on the liquidity that the attacker can bring because and then this multiplier can be

quite big actually um I'll show why so what the attacker would first do is send send a lot of send as much if as the attacker can get into the network then transfer it back out through all of the bridges and later possibly much later the attacker would the attacker would they would revert these transactions using a malicious fraud proof so now the attacker basically double spend the attacker now has the L1 is released by The Bridges but also has the L2 if again and the bridges have nothing now at that point the attacker at that point the attacker could amplify the attack by uh by front running all the trades that

happened on the network in the past seven days since the attacker now has the benefit of hindsight knowing about price changes and only the attacker gets to gets to use this Arbitrage and perform trades so that's why that's why the multiplier can be quite big so anyway I reported this to optimism they they immediately turned off fraud proofs and then and then started working on ovm2 so ovm1 has long been deprecated since and ovm2 is much better so no damage done but the assumption but the Assumption remains risky and not just for this

network for any network so this is not unique to it you're not unique to optimism Bridges basically have no way to defend themselves against long-term reorg they need to be aware aware of it and try to mitigate the risk to the best they can now here's an interesting case this is something that wasn't in production so I'll be through my arbitrum is an optimistic roll up and shortly before production I found an interesting bug in the code that is worth looking at the reason it's worth looking at is that it's the opposite situation one where a canonical bridge when one of the bridge is the one breaking the assumption

so the the message Bridge had an interesting property when sending a message from a layer 1 to layer 2 from a certain address uh the transaction it would create a transaction it would create a direct call from the same address on layer 2. and noted the code the coding these two addresses the coding's two contracts is not necessarily identical because if they were created using the create op code using the same deployment key and the same nonce then they would have the same address despite having different code so this enables the this enables an attacker to create a legitimate a legitimately looking D5 project on layer 2 wait until it accumulates in enough

assets and then and only then deploy a simple proxy on layer 1 and use this proxy to a rug pull all the assets to pull all the assets from the um from the contract so this broke another basic Assumption of another basic assumption from Smart contracts that a conduct should never make calls that do not appear in its code so anyway I'll be doing this I'll be to discover this while I was researching the bug and it was actually fixed in the repo on the day I wrote the report so that happens too but it's still a nice demonstration of how a bridge can break assumptions and

what will be the consequences and last I want to briefly look at the running so so running is uh so one in a is not a smart contract Bridge it's a trusted centralized Bridge based on a multi-sig and so in this case there was no attack on the smart contract it was simply um it was simply a multi-sig of supposedly 5 out of nine and the attacker managed to take control of five of five validator Keys four of them were four of them were managed by the same entity and were just stolen by good old email phishing and the fifth one was in the

fifth one was a validator that had an open developer API that shouldn't have existed in production and allowed signing anything so this goes to show us that not every not every bridge attack is a web free attack not everyone eaten it could be just a good old key compromise just a bad Key Management bad devops so this is something also to keep in mind so what so what can we learn from this there's a there's a lot that Bridges can do in order to be safer to be more secure but the previous stocks already covered that so uh so I'm going to bring

the point of view of the user the market forgets really fast and that's a problem you can uh you can always as a bridge you can just Rebrand and you're good to go and so until until all of us users start demanding until we wake up and demand that uh that Bridges be accountable accountable for their security we're going to see more bridges get hacked so as a user I would as users I would urge you first of all if a bridge if a bridge hasn't been audited on the latest version and including the initial the initialization on chain then it should not be used don't use that bridge

and if it if the bridge is a multi-sig then if the bridge is a multi-stick breed then it's not even a web free project it's just a trusted server so certainly please don't don't use this well so uh so as the users so users should just take control and decide and decide carefully which Bridges do you not only based on fees but based on security right thank you [Applause]