An Offensive Security View to Cross Chain Bridge Security

Transcript

Can you hear me? Yeah, great. Yeah, today's topic is offensive security review to cross-chain bridge security. But before I introduce myself, I want to talk about numbers. Since 2022, more than 2.5 billion dollar have been stolen from the cross-chain bridges. Not from the finance, from wallets directly from the bridges. And you can think that those cross bridges are the bank of bank of web 3 ecosystem.

And they can they run with the mixed codes, servers, and humans. And the most interesting part is the most bridge hacks were not caused by the smart contract uh vulnerabilities. It's happened somewhere else. In APIs, in the validator operators, and uh network infrastructure, and what we call web 2.5 area. It's a gray zone between where web 2 meets web 3.

And I'm AJ. I work in Hacken since uh 3 years now, and I have been working in this area for about 9 years. And in my daily work, I I test the system that I mentioned before that stays gray zone area. Uh like the mobile applications, web applications, browser extensions, desktop applications, source code analysis, um including the gaming system. And at Hacken, we also conduct uh smart contract audits, uh layer one security, including we have bug bounty programs.

And here's what we will cover today. We will start with basics, like how bridge actually work and what's inside it, why architecture matters, and what each one means for the security. And here, there's three questions we should ask. First one is the how does a bridge work? The the other one is the what's the off-chain layer and what's the web 2.5? Let's imagine two isolated silent. And left side is a Bitcoin and right side is the Ethereum.

And they have each one has own rules, own protocols. They don't communicate each other. They don't interact with each other. They there is no native connection between them, right? So, the question is how do you move your assets? How do you do move your value one to another? So, that's the where bridge came in. Most of the common mechanism is lock and mint. Say you want to use your Bitcoin on the Ethereum island.

Uh you wrapped you you sent your Bitcoin to the bridge and bridge locks it and no one can touch it. And you can use your Bitcoin as the wrapped wrapped coin, wrapped token in the Ethereum island just like any other user. And when you want to go back, you do it reverse. You wrapped your Bitcoin and it get automatically burned. The lock side opens and uh your Bitcoin is back. Now, look at the bottom of the picture.

Who actually approves the lock? Who actually approves the burn? Who decides that the message coming from one chain is valid before the another chain accepts on it? You know? It's the validators, it's the API, the network infrastructure, the private keys. So, that's why we called web 2.5. Not fully decentralized like web 3 and not it's not the traditional web 2.

It's somewhere between them and they carrying the risk from one world to another. And this bring us to most important point of the section. Because the weakest point is the validators. They lives in the web 2.5 area. They can be manipulated. They can be tricked. They can be taken down. So, they can be compromised. So and every major hacks we have seen so far like Ronin, like Harmony Horizon, um didn't happen the on-chain side. The on-chain side was fine, but the

off-chain layer was broke. But not every bridge works the same way. Look at the table. There are four different models and there are four different trust assumptions. First one is canonical. It trust the chain itself. Minimal 2.5 attack surface, but the speed is real slow. The other one is the validator. It trusts human and keys and minimal web 2 Sorry, it's high web 2.5 attack surface, but it's also very fast.

The other one is the proof base. It trusts mathematics and the ZK proof. Uh low 2.5 attack surface, but it's really slow and expensive. By the way, the industry is moving here, but not just fast enough. The other one is the liquidity. It trusts layer and attack surface is medium to high and it's really fast and user-friendly. So, at the end of today, the pattern is clear. Three out of four models have web 2.5 exposure.

Proof base is still evolving, but until that changes, billions of uh dollars keep flowing through the off-chain sites. Now, let's see the what happens when attacker actually find it. Uh I believe you already know that attack the the Ronin attack. It's conducted by the Lazarus Group. If they spread fishing attack developer targeted via uh fake job offers and the private key extract extracted from the local machines.

And uh as a result, 625 billion has gone and the chain never knew that. The other one is the Harmony Horizon. Um same result, but different path. Uh server infrastructure compromised directly and they only need two keys and uh 100 million has gone. The other one is Shelly Hult. Actually, this one is the most smartest hack I have ever seen so far.

Um It's a self-spreading worm and the story behind that, the attackers uh hacked NPM validators. And they and they and then they upload their backdoors to the trusted packages. So, as a developer, when you run the NPM comment, it's uh automatically your the the worm in your machine. So, yeah, you you were already hacked. And the interesting part is it's affected almost three layers, like web 3 area, web 2 area, web 2.5 area. In web 2 side, cloud server was compromised and in web 3 side, the validator key, the

environment files, the credentials was taken from the developer's local machine. >> [snorts] >> And the web 3 side, the attackers used the stolen credentials and they upload the fake version of the trusted Chrome extensions. Uh and users who logged in, uh their wallet data was stolen silently. And it's also it's nearly affected 20 million users right now and the effect is still going on. Like I heard yesterday that two uh Axios version was affected from them.

The fix is come uh the same day, but if you are using the older versions or just be careful about and aware of it. And let's map the attack surface schematically. There are five issue here and each one is positioning on the off-chain side, but they are also affected on-chain side directly. First issue is the cross-chain message spoofing. In here, every chain has a fundamental question that needs to be answered.

The question is did the lock actually happen on the other chain? Because an attacker sends the crafted bridge messages and the chain accept these assets without a valid transaction on on on source chain side. And look at the attack flow. Attacker submits the crafted uh bridge messages. Backend accepts it message this message as valid. And transaction, there is no cryptographic commitment trying to this message to a real on chain event. So there is no signature verification.

And as a result meet executed on and you gave unauthorized assets. This is the basic request. You can see. These are the our main playground. Endpoint headers and the functions. And look at the TX hash. It's fabricated not it was ever locked in the Ethereum side. And there's a signature verification but the field exists but it never checks the what's inside it. So as a result 1 million wrapped token minted for nothing. Just a message here said that trust me.

And the the other issue sorry. And here's something worth the pausing on. Let's say smart contract is perfectly written and and and the signature verification is solid. Does it mean you are safe? No. The answer is no because the attacker doesn't have go through the legitimate flow. They go directly through the API. They craft a message and the API passes through the layer and the layer passes the smart contract and the smart contract assumes that the this message is valid and the signature

is valid and you automatically got approved. So the main issue main problem is that there is no defense in depth mechanism. So every layer needs own control. So smart contract doing its job doesn't mean that the API layer is doing its job. So web 2.5 is just the additional attack surface so you can bypass on the on chain layer. And but the other main problem is here the there's there's a disconnect between the on chain and off chain side.

So the teams working on these parts needs to be more aligned more aware like what each side is doing. And it's really easy to prevent but that's why this kind of issue becomes more possible today. The other one is the replay attack. Replay attack is basically when someone takes a valid transaction and just sends this over and over again. The system keeps paying out every time and it happens because bridge doesn't track the what's what's already proceed.

So it treats the same request. It's like a it's a new new each time let's say. So this is a let's let's walk through this. This is a simple request and response. The real claim exists. The attacker doesn't create a fake one. Just duplicate the same request. Same TX hash. Same signature. Same amount. Same amount can amount field can be changed by the by the way. And sends it again and the bridge gets it and checks the signature is valid.

Checks the amount is valid. But it's never asked did I already proceed this before? So there is no nonce here. There's no tracking in here. So it pays out again and again. Same transaction and second payout and third payout. The fix is actually really simple in here. Every claim should be tied to a unique identifier like the nonce like TX hash like the registry or the message ID. So in short replay protection must be enforced to the bridge logic level.

So this one is different from everything we have seen so far. Let's say you you logged in the some of Jack's platform. And each platforms gives you a signs you an ID. And imagine your user ID is one. When you leave your own profile you can able to see the your personal details like the user ID username KYC status or the sub accounts. But the problem is here when you change your user ID one to two you can able to observe the others users data.

And it means that you can effectively enumerate all the users data stored in the system. So this is you you have only read access but this is what we called as the vertical leader scenarios. And there's also horizontal scenarios but in horizontal scenarios you can able to modify the other users data. The other issue is the unauthorized universal transfer.

Let's say the attacker is using their own wallet session. So the authorization header is complete completely belongs to the attacker. However in the transfer request they have set the from account field to the victim ID victim's wallet address. And in as a result they simply reuse the wallet address. They were able to observe in the IDOR issues. The core misconfiguration here the system only checks the whether the wallet is exist but never check never checks never verifies the who

actually belongs to. Because of that you can you can change the wallet address here. You can take the funds others users wallets. So the authentication and the authorization are two different things. Authentication answers who are you and authorization answer what are you allowed to do. In this scenario the authorization header is valid but it never asked the who who belongs that authorization header.

And the other one is the social engineering attack. This attack is become very popular lately. The attackers group reach out to developers on LinkedIn with our fake job offers. And the conversation feels natural. The interviews and technical talks everything looks professional. But then comes the technical challenge. They sent you a coding task but hidden inside the coding task is a back door. So while you are working on this challenge the attacker already has access to your machine and quite stealing everything in your local.

And what makes this especially dangerous it's it's how they target it. They first they profiling the persons users and they build the whole approach around that one person. And like whoever the most likely have the validator keys on their machine they target that person. And once you download task locally and start solving the challenge you got automatically hacked.

And last one is the it's mostly related to web 2 infrastructure but it's directly affect the web 3 area. On July 2024 most of the several D5 protocols were affected with DNS hijacking attacks. The bridge code was clean. There is no issue in the on chain and off chain logic. However the attackers came from the off chain side. The domain register account has no factor authentication. So the attackers runs a simple DNS lookup command and with with one command they can able to observe the provider

region name space register and there's no DNS sec in here. And the attacker gets into register account like credential stuffing brute forcing or two factor two factor authentication bypass. It depends of the system and the attacker's mind. And they change the DNS record. And at the end of the day the site looks identical. Same logo. Same UI. Same colors but the approve button calls the smart contract attacker's calls attacker's smart contract. So when

you click the approve button and you confirm they you just gave you an access to the attacker. So it means that your your old tokens gone forever. The attacker drains able to all the users wallet in the system. So thank you for listening to me today. >> [applause] >> We can take we can take [clears throat] questions.

I think that's all. >> Okay, thank you. Thank you, everyone.