Common Vulnerabilities in Bridges

Transcript

we good to go lovely all right very last Talk of the day welcome everyone uh hope there's still a little bit of room left in your brains for a little bit more information uh what I'm going to be doing today is common vulnerabilities and bridges now there's a lot and lot of bridges in the D5 world and having reviewed I I don't know how many countless Bridges uh I'm here to give you some advice on what not to do so who are we uh I work for Sigma Prime uh we're blockchain security firm uh we've done a lot of bridges extensive extensive uh decentralized technology all up and down the chain uh we also run Lighthouse that is one of the consensus lay clients for ethereum but I'm not going to spend too much time on us or me

security assessments manager because it's only a short talk and I want to give you get into Bridges so uh I hope everyone here knows how Bridge works but this is very very brief what we do firstly chain a someone needs to transfer some funds into the bridge you get a message and potentially an arbitrary number of tokens depending on the bridge something happens offchain their oracles or or trusted nodes or whatever is doing it they record all your unchain transactions on chain a they're going to submit some sort of trusted route onto chain B then as you as a user you make a proof on on chain B and you can therefore submit it and receive your tokens on the other side of the bridge some interesting points to

note on this is that most bridges that we review are going to be lock release Bridges which means chain a when you transfer your tokens in they all get stored in the bridge means huge Target for attackers because we're can have tens of millions hundreds of millions of dollars stored up in this one contract now the most simple attack is a replay attack uh once you execute a message on chain B you should only be able to do this once almost everyone does this but they use a nons uh that's the most simple replay protection what it does is when you execute your message the nons is registered and you can't execute that message again now however some people like to take really big nones U 256 and cast them into un 32s to use them inside of a Merkel tree and

then they register this un uh 256 as used however this is going to have a lot of issues cuz if you take a you 256 and then you only use 32 bits of that in a proof there's a whole bunch of extra 200 plus bits that an attacker can play around with uh this happened to a client and that's why I said don't cast them into the tree because they did this and it opened them up to a replay attack where an attacker could have claimed all of the funds in the bridge luckily it was a white hack and they reported to a bug Bounty and they'll paid out I think a million dollars or something for this bug so be very careful with your nonsense make sure you cast them properly and finally re-entrancy uh this is really important with nonces nons uh

State modification you want to use some reentrancy to prevent the nonsense being reused before um they're recorded lovely this this is a bit of a uh an interesting topic Bridges with unrestricted external calls it's a security user experience trade-off that unfortunately way too many people take the user experience tradeoff and I'm going to tell you why that's a bad idea and I I want you to not use unrestricted external calls so this little code snippet uh the the function marked unsafe don't put unsafe functions in your live smart contracts that's also a bad idea but this unsafe function it takes the message and it will send uh arbitrary data uh it looks like I've

actually copied it wrong it's meant to use a low-level call and it'll call an arbitrary address with anything and what happens when you make an arbitrary call to a contract from your bridge is you can call any token address any arc2 token address you want so if you're making an unrestricted uh call and someone decides oh I I want to transfer X number of RVA tokens to my address they could do so and this actually happens on the Arbitron Bridge today I went and checked ether scan before I got here and there's someone doing ex exactly this it's a unrestricted call from Arbitron it allows you to call any address with any call data and what they've done is every time uh an amount of tokens gets stuck in the arbitr

bridge in a contract where there's not really meant to be tokens they'll drain those tokens immediately using uh arbitrary unrestricted external calls now the other reason I'm bringing this up is a lot of contracts have only bridge if you have an only Bridge modifier and anyone's allowed to call this well you're going to be in a world of hurt when someone deliberately calls uh your contract with an unrestricted call nice next call the joys of erc20 all right esc20 tokens can be a pain I'm sure we've all seen the uh weird esc20 GitHub page being audited there's so many painful uh esc20 token implementations that aren't

genuine not going to dive into those you should all know those by now but when we do something like this from a bridge we have a batch of tokens they're really vulnerable to a denial of service attack where you can stop someone's message being executed by just having one malicious token in there that causes a revert and sometimes it doesn't even have to be a malicious token if if one of the tokens is paused there happens to be one a blacklisted address in there then the enti message can't execute because you've got one dodgy token now decimals decimals are a pain there's some really interesting cases where you have tokens on one chain tokens on another chain and they have different decimals in each chain usdc

and usdt are both examples of this they have six decimal places on ethereum Main net and 18 everywhere else in the world so what happened uh I've noticed one Bridge did have this sometime ago they patched it before they went live luckily but they just assume that the decimals were same on both Sid of the bridge so if you transfers tokens one way then transfer back you would have increased your balance by a factor of 10 to the 12 last thing uh unbounded looping if you've got a number of tokens make sure you cap it if you have any number of tokens uses too much gas you break following gas gas into resources now return uh return gas bombs are absolute pain in the ass when you're calling unrestricted uh functions and

even restricted if they have returned data because the main issue with this is when you have a batch of transactions often you're uh executing as an oracle you're executing the entire messages for everyone rather than letting them execute their own messages and if one malicious contract in there decides to use use a return gas bomb they can drain the entire uh transaction gas balance and then Oracle transactions will fail so be very careful when you call any external address to make sure they can't give you a return gas bomb or just spend the gas themselves now calculating fees can be quite challenging uh some l2s have fees for the gas and then they also

have their extra L1 fees as well so when you're calculating fees you have to be really careful to get an exact exactly right otherwise someone's going to make transactions that spend way more gas than they're paying for and then you will lose out as the bridge operator then finally the last one is quite an interesting one uh ZK evm chains often have a limited number of instructions that can be called so what that means is say the add instruction you want to add to to numbers that can only be called say thousand times over an entire block even or a transaction sometimes depending on the chain now if you make an any external call they can use up all 1,000 of these ad instructions and therefore the next

message in the batch can't be executed you could do that from any external call whether it's tokens you're a malicious token whether you can be the receiver anyone in a batch can consume all of your ZK resources lovely now trusted Roots I I did mention this a little bit earlier but be very careful of your indexes these can often be used as nonsters uh don't cost them and and make sure they're accurate there's an interesting case in open zeppin implantation that if you provide an index bigger than the size of the tree they will just kind of ignore that uh they will only use the index a number of bits for the same length as your proof so if your proof is

uh 10 elements long they'll only read the first 10 bits of your index and the remaining bits can be whatever you want this is a good way to apply by some replay attacks then next up we have hashing if you ever have any data in your message that is not hashed and verified it could be changed uh this happens a lot when people add new fields at the end and they're not thinking they don't include it in the message hash these sorts of things and then all of a sudden you have fields that manipulable uh if these are token addresses or amounts or anything like that then someone's going to steal all your funds now lastly this one's kind of a challenging one uh it consensus and I mentioned before that we needed to get a trusted route from chain a onto chain B

and how to do that is a rather complicated one a lot of people use multi- sigs they use some sort of Byzantine fault tolerance n ofm but all of these are vulnerable to something that Heidi was just referring to and that is offchain and multisig attacks uh we've seen the Ronin Bridge we've seen a number of other Bridges where people have gone offchain directly to the multi and create their own fake trusted routs or do any sort of upgrade and we'll steal your entire Bridge deposit cool this is quick summary if you want to take a photo all of this we hopefully work to you as a checklist if you can remember what I've said here today and this is the end welcome you

made it all the way through