Don't Burn your Bridges: Protecting Bridges from Most Recent Hacks with Alex Murashkin

talk about bridges than another Alex who is going to start a session on how to not burn your Bridges protecting from Bridges from the most recent hacks and Alex is from Quant stamp he lives in Dubai if you guys are based in Dubai you can find him there and he started working in this space in 2017 and I'm sure other security rules before that so Alex will hand it off to you so you have your maximum time hello everyone well I'm Alex murushkin I'm head of infrastructure at one stem so um yeah Bridges continue to be a Hot Topic with nearly half of all G5 exploits being related to Bridges even nowadays according to token terminal last year alone British hacks led to more than 2 billion dollars worth of assets lost and if we consider the total value lost since the start of the bull market this number exceeds 2.5 billion dollars uh this work is an extension of an earlier work by my colleagues and myself we recently published a paper called not quite water under the bridge review of cross Chain Bridge hacks uh my co-workers did presentations on a similar Topic at least Denver last year is Portland also other venues also my co-worker Martin gave a version of this talk at defy Denver as well in this work we mostly focus on 2022 basically hacks or exploits that happened throughout last year but first we introduced some Concepts Bridge is a software application that is used to move assets from one chain to another essentially if an actor on the left hand side wants to move East into another chain Bridges will be facilitating this transition while we say that assets are moved from one chain to another in actuality assets are usually locked on one chain and then on another chain there is another version of that asset that is being minted by a component that we all call the debt issue uh whereas the original assets will be normally held in what we call the custodian and at the same time I mean Communicator is usually an off-chain component that facilitates the interaction between the custodian and that issue with roles happen in a similar way so the actor on the right hand side expresses interest in burning some of the debt tokens some version of it on that other chain and that issue sends a message to the custodian through the communicator so that the custodian can release the assets if the proper approves are in place now let's move on to exploits and attacks in 2022 there has been plenty of attacks on Bridges most of them were successful from a perspective of the attacker as here you can see that the attackers are widespread the attacks are widespread throughout the year and the total loss here is more than 2 billion and what we are going to do now is we are going we'll go over each attack uh one by one so that we can understand exactly what happened and how we can learn from that and the reasons attack um I saw widespread widespread is because bridges are such a complex such complex systems usually so such systems they have lots of uh points or failure and even though we discussed just the custodian that is sure and Communicator those three components but there's actually more than that the system boundary doesn't end there we have the we have the token interfaces related to assets erc20 interfaces there isn't there could be Network level attacks such as 51 attacks on each side of the bridge and also there is a front-end possibility of an exploit somewhere in the front end right so it's possible to trick users into using the invalid incorrect a substitute of contract rather than the real actual Bridge and we'll be using this smaller diagram on the right hand side to classify the attacks so the first attack was actually a good news because it was averted in January 2022 the token interface and custodian kind of parts of the bridge system were involved in the attack what happened was that users who interacted with the bridge approved the bridge to spend certain tokens on behalf of the bridge and some users of course it's very easy to make a mistake and to the infinite approval so that it's it pretty much grants a lot of access to a page and the attacker was able to exploit a smart contract error related to inputs validation and call the token contracts on behalf of the bridge therefore they can take in the assets that belong to the user Another January attack involving the custodian was related to exploiting Quality deposits logic in a small contract essentially accordion deposits in the bridge contract without providing is that that is backing this uh deposit was possible and therefore was exploited by an attacker so that's kind of another smart contract related issue the months after that this time it was that issue that was the focus of the attack so signature verification the target chain contains an issue a bug and an attacker was able to falsify the input account that was not properly validated which is out at in in a loss of loss of funds so the root cause here is also a smart contract error and in this case specifically it was a duplicated function in the Target chains ecosystem uh the next attack of February was also related to the custodian and similar to the second attack he was related to an issue in the deposit logic so unfortunately wrapped in a wrapped assets were processed differently and they were not um yeah the the fact of the deposit was not properly determined therefore the root cause here we also did identify as an issue in a smart contract more specifically in a deposit logic and yeah it was also related to the custodian component of the bridge in March there was a different attack this time surprisingly it did not involve a smart contract issue this time it was a private Keys being being compromised what was the the root cause so according to um what we were able to read about this attack was that the attacker managed to get access to four nodes and an ability to get one extra signature from adao which is outed in essentially controlling the basically the consensus mechanism of the of the nodes and being able to having the ability to withdraw the funds uh and in this case allegedly that the keys we acquired through a phishing attempt another attack involving compromised private Keys happened in June as well where the attacker got access to two private keys and the the vote had the vote was basically two out of five signatures required and in this case the exploit also was was possible since the threshold was of the multistick was reached and finally another attack evolving compromise private keys it was related to essentially the tools that allow you to generate a vanity address and in this case it was pretty much not that difficult to predict that a certain projects would use use a tool and therefore it was possible to essentially figure out the admin account of of the given project so here is a root cause we also did we also this there's a compromised private key the next attack from August last year it was involved in the custodian as well so in this case it was basically an upgrade that introduced an issue which allowed a special trusted route to be authorized and in this case the flood logic allowed to pass a signature validation algorithm and yeah unfortunately this enabled token transfer and unlocking in this case we also list a smart contact error as a root cause and more specifically the an issue with proof validation and finally the October attack last year involved in a custodian it's pretty much it was possible for an attacker to be registered as a bridge relayer and be able to essentially provide Forge proofs of deposit and which also in turn allows transfer and unlock of the tokens and here in the root Quest we also regard as a smart contract error and more specifically wrong proof validation so what can we learn from from this so out of nine attacks that we considered that we managed to find the information regarding in 2022 eight of the attacks related to the custodian which is not surprising because custodians are essentially highly pods where all the original assets are locked in and of course it will be very tempting for an attacker to try to find ways to access that High new pod six of the attacks were related to Smart contracts smart contract errors which is also not too surprising but at the same time what was interesting is that three attacks exploited compromised private keys so what it means is that even if you have Smart contracts in order it's still possible that if you don't manage your infrastructure well if you don't manage if you don't follow best practices for keeping private Keys then you might be under attack as well uh so two attacks involved the wrong proof validation it's not significant considered the whole kind of the whole set of attacks we uh we considered however it also means that if there is a weak spot and smart contract validation then that could be a proof validation also we saw attacks involving token interfaces maybe not necessarily directly but kind of rather indirectly involving for example transfer from methods or for example permit function so there are some attacks in the past actually in 2021 that involved a token interface but last year we only considered one that I presented at the at the beginning the one that the one that was averted so how do we mitigate the attacks right so first of all even before you're deployed uh your Bridge or smart contract uh the important part is considering how you generate the keys uh for the deployer or for admin accounts so the suggestion here is to never use a known tool or known method for generating private keys and also trying to make it so that there's maybe there is no access to Internet on the machine that you're generating that you're using to generate the private keys so just for additional security second item there is making sure that you handle all possible Corner cases in smart contracts not just smart contacts actually because most of the communicators are off-chain components and there could be some cases missed there as well so making sure that the poison logic is really hack proof in that case using best practices for securing private keys so definitely that's that's an important consideration that also involves Web 2.0 security uh having higher thresholds for multi CX that is something that is something easy to enable but at the same time we have seen the case when the multi-sig essentially allowed two out of five to to sign and therefore to to succeed the attack then number five recommendation here is avoid centralization of power in a contract so we saw the previous talk where I would another Alex talked about essentially a decentralized Bridges and I think that's something to be considered as well so what can happen in centralized Bridges is that you are given too much power so the admins of the contract are given too much power and they can withdraw all the assets at once if you absolutely have to use that kind of version that approach what should be considered is some time log for withdrawals or having some kind of multi-stage approvals in order to get the the assets out or what we've seen in some bridges they essentially treat small Energy deposits very differently and with robots as well which also makes sense because you probably need a higher threshold for or for high higher value with roles number six here is carefully checking if Legacy or test only functionality is disabled in the production system this this is more related to general based coding and deployment practices not necessarily related to Smart contracts or to a blockchain applications however in blockchain applications this becomes particularly important because you can't always upgrade the code and disable that functionality and it's always very difficult to to track if something if some part of the code was executed without you knowing that number seven here is remaining aware that assets functionality such as transfer from and permit exists and not all erc20 compatible contracts implement this functionality in the same way right there could be some variations Samuel C20 contracts have a fallback functions function some of them do not have that so definitely something to be aware in order to uh design the beach very well you need to make sure that it works for all possible weird cases of assets or maybe being able to White list or remove from consideration assets that are not compatible and finally of course regular Web 2.0 security it's always going to be important so definitely something to consider whenever you're building a bridge especially for the communicator component because it's essentially a regular off-chain component that needs to be properly secured this brings me to the end of the presentation uh thanks a lot for coming thanks a lot for listening please drop by our booth it's really nice as you can see from here but yeah and if you have any questions feel free to reach out I'll be here after the talk thank you so much [Music]