Achieving interoperability in the blockchain space requires the presence of blockchain bridges, which play a crucial role. Consequently, prioritizing the security of these bridges becomes essential. Let’s discuss this in our blog.
Weaknesses in bridge security often involve inadequate on-chain and off-chain validation, improper management of native tokens, and misconfigurations. To ensure robust verification logic, thoroughly testing the bridge against various attack vectors is advisable.
Enabling interactions between two blockchains, a blockchain bridge serves as a protocol facilitating seamless connectivity. Suppose you possess Bitcoin but desire to engage in DeFi operations on the Ethereum network. In such a scenario, a blockchain bridge empowers you to partake in these activities without liquidating your Bitcoin holdings.
Blockchain bridges operate by implementing diverse on-chain and off-chain validation mechanisms critical to achieving interoperability in the blockchain realm. Consequently, they exhibit distinct vulnerabilities concerning security.
According to industry estimates, bridge attacks resulted in approximately 1.3 billion USD in losses in 2022, constituting 36% of the total losses incurred that year. These attacks primarily target cross-chain applications, as bridges, often implemented as smart contracts, tend to accumulate significant tokens while transferring them between chains. Consequently, bridges become alluring targets for hackers due to their substantial value.
Moreover, blockchain bridges encompass numerous components, presenting a substantial attack surface. Malicious actors are keenly motivated to exploit vulnerabilities within these bridges to siphon off significant funds.
To bolster the security of bridges, it is crucial to have a comprehensive understanding of the common vulnerabilities that can arise in their design. Before their launch, it is advisable to subject bridges to thorough testing to identify and address these vulnerabilities. These security risks can be categorized into distinct areas.
The emphasis on on-chain validation is minimized for certain bridges, particularly those tailored for specific decentralized applications (DApps). These bridges rely on a centralized backend to execute fundamental operations such as minting, burning, and token transfers. Meanwhile, the validation processes are conducted off-chain.
Conversely, other bridges utilize smart contracts to validate messages and perform verifications on-chain. When a user initiates a fund deposit into a chain, the smart contract generates a signed message and includes the signature within the transaction.
This signature serves as evidence of the deposit and is subsequently employed to authenticate the user's withdrawal request on the target chain. This robust process mitigates potential security attacks, including replay attacks and forged deposit records.
Nevertheless, if a vulnerability is present during the on-chain validation phase, an attacker can exploit it to inflict significant harm. As an illustration, in the case of a bridge utilizing a Merkle tree for transaction record validation, an attacker could fabricate forged proofs. This malicious action would enable them to circumvent proof validation and illicitly mint new tokens into their account, exploiting the weakness within the validation process.
Incorporating so-called "wrapped tokens" is a common strategy employed by certain bridges. As an illustration, when a user transfers DAI from the Ethereum blockchain to the BNB Chain, their DAI holdings are withdrawn from the Ethereum contract, and an equivalent amount of wrapped DAI is subsequently generated on the BNB Chain.
However, if the validation of this transaction is insufficient, it opens the door for potential attackers to exploit the system. By deploying a malicious contract and manipulating its function, these attackers can divert the wrapped tokens from the bridge to an unintended address.
To execute such an attack successfully, the perpetrators rely on victims approving the bridge contract, permitting the transfer of tokens via the "transferFrom" function. This enables them to drain assets from the bridge contract.
Regrettably, this situation is further exacerbated by the practice employed by many bridges, which involves requesting infinite token approval from users of decentralized applications. While this approach may reduce gas fees, it introduces additional risks by allowing a smart contract to access unlimited tokens from a user's wallet. Exploiting the absence of adequate validation and the excessive approval granted, attackers can siphon tokens from unsuspecting users to themselves.
In some bridge systems, the off-chain backend server plays a critical role in verifying the legitimacy of messages sent from the blockchain. In this instance, we’re focusing on the verification of deposit transactions.
A blockchain bridge with off-chain validation works as follows:
The backend server must ensure that the deposit transaction it processes has occurred and was not forged. This backend server determines whether a user can withdraw tokens on the target chain and is a high-value target for attackers.
The backend server needs to validate the structure of the transaction’s emitted event and the contract address that emitted the event. If the latter is neglected, an attacker could deploy a malicious contract to forge a deposit event with the same structure as a legitimate deposit event.
If the backend server does not verify which address emitted the event, it would consider this a valid transaction and sign the message. The attacker could then send the transaction hash to the backend, bypassing verification and allowing them to withdraw the tokens from the target chain.
Different approaches are employed by bridges when dealing with native tokens and utility tokens. In the case of the Ethereum network, the native token is ETH, while most utility tokens conform to the ERC-20 standard. Users must initially deposit ETH into the bridge contract to transfer it to another chain. This is achieved by attaching the ETH to the transaction and retrieving the amount from the "msg.value" field.
Depositing ERC-20 tokens differs significantly from depositing ETH. For ERC-20 token deposits, users need to grant permission to the bridge contract to spend their tokens. Once the tokens are deposited, the contract will either burn the user's tokens using the "burnFrom()" function or transfer the tokens to the contract using the "transferFrom()" function.
There are different approaches to distinguish between the two scenarios. One method uses an if-else statement within the same function, while another utilizes separate functions for each scenario. Refraining from attempting to deposit ETH using the ERC-20 deposit function is crucial, as it can result in the loss of funds.
When handling ERC-20 deposit requests, users typically provide the token address as input to the deposit function. However, this poses a risk as untrusted external calls can occur during the transaction. To mitigate this risk, a common practice is implementing a whitelist that includes only the bridge-supported tokens. By allowing only whitelisted addresses to be passed as arguments, external calls are prevented since the project team has already filtered the token addresses.
Nevertheless, challenges can arise when bridges handle cross-chain transfers of native tokens, as native tokens do not possess addresses. Instead, a zero address (0x000...0) represents the native token. This can be problematic because passing the zero address to the function can bypass the whitelist verification, even if implemented incorrectly.
In cases where the bridge contract calls "transferFrom" to transfer user assets to the contract, an external call to the zero address will return false since the zero address does not have a "transferFrom" function implemented. However, if the contract does not handle the return value appropriately, the transaction may still occur without transferring any tokens to the contract. This allows attackers to execute transactions without transferring tokens to the contract.
The responsibility of whitelisting or blacklisting tokens and addresses, assigning or changing signers, and other critical configurations in most blockchain bridges lies with a privileged role. Accurate configuration is essential, as even minor oversights can have significant consequences.
An attacker exploited a misconfiguration to bypass transfer record verification. The project team implemented a protocol upgrade that involved modifying a variable. This variable represented the default value of the trusted message. This change resulted in automatically proven messages, enabling the attacker to submit any message and pass verification.
Addressing the security challenges in an interconnected blockchain ecosystem requires understanding the four common bridge vulnerabilities discussed earlier. Each vulnerability presents its considerations, and there is no one-size-fits-all solution.
When establishing error-free verification processes, providing generic guidelines is difficult due to the varying verification requirements of each bridge. The most effective strategy involves comprehensive testing to identify and mitigate potential attack vectors while ensuring the integrity of the verification logic. In conclusion, rigorous testing against potential attacks and a focused approach to addressing the prevalent security vulnerabilities in bridges are vital for maintaining a secure environment.
Cross-chain bridges have long been a target for attackers due to their considerable worth. Builders may lower the danger of the severe cyberattacks that have afflicted bridges over the past several years by doing extensive pre-deployment testing and participating in third-party audits. Bridges are essential in a world of several chains, but when developing and constructing a Web3 infrastructure, security must come first.
