Cobo Labs: A Review of Typical Security Incidents in the Cryptocurrency Industry in January

Author: Cobo Labs

This article is contributed by the Cobo blockchain security research team, whose members come from well-known security laboratories and have years of experience in cybersecurity and vulnerability discovery. They have assisted Google and Microsoft in handling high-risk vulnerabilities and have received acknowledgments from companies like Google and Microsoft. The team has achieved outstanding results in Microsoft's MSRC Most Valuable Security Researcher Top list. Currently, the team focuses on smart contract security, DeFi security, and other areas, researching and sharing cutting-edge blockchain security technologies.

Multichain Vulnerability

On January 18, the well-known cross-chain bridge Multichain (formerly Anyswap) discovered and fixed a significant vulnerability affecting six tokens: WETH, PERI, OMT, WBNB, MATIC, and AVAX. Users who had authorized the aforementioned tokens on the Multichain Router were affected, and attackers could directly exploit the vulnerability to transfer away the tokens authorized by users. According to the official announcement on the 19th, due to some users not revoking their authorizations in time, approximately 445 WETH was stolen by attackers.

The vulnerability occurred in the anySwapOutUnderlyingWithPermit function of the AnyswapV4Router contract, where the function did not validate the legality of the Token parameter, allowing attackers to pass in a forged Token contract to replace the original official AnyswapV1ERC20 Token.

On the other hand, token contracts like WETH did not implement the permit method but did implement the fallback function, so subsequent calls to permit would not revert, allowing the execution to continue successfully. This ultimately allowed attackers to steal the tokens that victims approved for the AnyswapV4Router contract.

Cobo Comment

For ordinary users, it is essential to pay special attention to the risks posed by ERC20 Infinite Approval. Authorizations should ensure that only the necessary amount of tokens is authorized, rather than using the default infinite approval, to avoid saving gas at the cost of losing principal. Existing infinite approvals should be revoked in a timely manner, and users can check their authorization status using Etherscan's tool at https://etherscan.io/tokenapprovalchecker.

Reference

https://github.com/W2Ning/AnyswapVulPoc

https://theblockbeats.info/news/28774

https://hackernoon.com/erc20-infinite-approval-a-battle-between-convenience-and-security-lk60350r

DEX Crosswise on BSC Attacked

On January 18, the DEX project Crosswise on BSC was attacked, resulting in a loss of approximately $300,000 and causing a flash crash in the CRSS Token price.

The issue arose because the setTrustedForwarder function of the MasterChef contract did not perform proper permission checks. When the attacker modified the TrustedForwarder, they could effectively forge msg.sender, thereby directly obtaining the owner permissions of MasterChef. They then used the owner permissions to call the set function, setting the strategy to the attacker's malicious parameter 0xccddce9f0e241a5ea0e76465c59e9f0c41727003. After modifying the strategy, they could withdraw a large amount of CRSS Token with a small deposit.

The official announcement also acknowledged that this vulnerability was too obvious, suggesting that the developers may have intended it. After an internal investigation, four developers were dismissed. A snapshot of the on-chain data has been taken, and a redeployment will follow. A comprehensive code audit has already begun on the official GitHub, and it is said that a joint audit with Certik will take place later.

Cobo Comment

This attack targeted the MasterChef contract and did not directly steal users' LP or CRSS tokens, but the significant price drop still caused actual losses for CRSS holders. The official documentation does not provide an audit report for the project, and this vulnerability is quite apparent; if it had undergone an audit by a security firm, it likely would have been exposed. Individual investors should remain cautious about projects that have not been audited.

Reference

https://twitter.com/peckshield/status/1483340900398895105

https://crosswise.medium.com/post-exploit-update-2a24c3370466

https://bscscan.com/address/0x70873211cb64c1d4ec027ea63a399a7d07c4085b#code

https://github.com/crosswise-finance/crosswise-code-review-1.1

Rari #90 or Float Protocol Pool Manipulated by Oracle Attack

On January 15, the RariCapital #90 pool, which is the Float Protocol pool, suffered an oracle manipulation attack.

This pool uses the Uniswap V3 FLOAT/USDC trading pair for pricing, and a few days before the attack, the liquidity in the FLOAT/USDC pool decreased (down to about ~$550k), providing an opportunity for attackers to conduct oracle manipulation attacks.

The attacker used 47 ETH (worth about $120k) to exchange USDC for FLOAT in the pool, causing the FLOAT price to rise. They then used FLOAT as collateral in the Rari #90 pool to borrow other assets for profit. The attack method was consistent with the Rari #23 pool Vesper Lend Beta attack that occurred in November 2021.

Cobo Comment

For some small tokens that cannot use ChainLink oracles for pricing, DeFi contracts typically use DEX for pricing. Currently, while UniswapV2/V3 delayed pricing can resist flash loan attacks, it cannot resist real large asset manipulation; and although the TWAP time-weighted mechanism can increase the difficulty of manipulation to some extent, it can only alleviate rather than eliminate the issue.

From a developer's perspective, it may be worth considering adding risk control code in contracts to check for malicious pricing. For ordinary users, it is essential to pay attention to related liquidity pools and guard against price manipulation risks.

Reference

https://twitter.com/FloatProtocol/status/1482184042850263042

https://medium.com/vesperfinance/on-the-vesper-lend-beta-rari-fuse-pool-23-exploit-9043ccd40ac9

DefiDollar Discovers Potential Attack

On January 8, DefiDollar Finance (@defidollar) tweeted that a potential vulnerability was discovered in the DUSD contract, which has been paused, ensuring all funds are safe. It is reported that this vulnerability may have been automatically detected using a blockchain monitoring system. The approach involves monitoring on-chain Tornado.Cash transfers to new addresses and the deployment of contracts (a typical preparatory action in many real attacks).

Further analysis of contracts and related transactions can reveal potential attack behaviors, and if issues are found, the relevant project parties will be notified immediately for prevention. Someone has already implemented a similar agent on Forta.

Cobo Comment

Project teams may consider similar approaches by monitoring new contracts on-chain and transactions in the memory pool. For suspicious contracts or transactions, static analysis or simulated execution can be conducted to check for adverse effects on the assets associated with their project contracts.

As blockchain offense and defense evolve, it is foreseeable that similar monitoring alert systems will become increasingly mature. Of course, attackers will also discover more ways to bypass monitoring. The ongoing confrontation between offense and defense in traditional security will continue to manifest in blockchain security.

Reference

https://twitter.com/AndreCronjeTech/status/1479778350084333574

https://connect.forta.network/agent/0x2fbec7dcd4eebf34c5b94d899109057eea3642a2400b7143e64873d453b7ba61

Rari Pool #19 Attack Fails

Well-known blockchain security white hat @samczsun issued a warning tweet regarding Rari #19 (Index Coop Pool), but the subsequent attack did not actually occur.

The attack method was similar to the previously mentioned Float Protocol Rari #90 oracle attack. The attacker exchanged about 300 ETH for BED on Uniswap V3, manipulating the token price. Since the Uniswap V2/V3 Oracle updates the token price only in the second block, the attacker was unable to complete the price manipulation within a single transaction, thus countering the flash loan attack.

When using real large funds for manipulation, the attacker would need to wait until the second block to see the price response. Due to the existence of TWAP, attackers typically need to wait a few more minutes for the price to become more apparent. For this attack, the attacker did indeed follow this approach.

However, awkwardly, a suspected arbitrage bot appeared in the second block, which immediately exchanged a large amount of BED for ETH, maintaining the original price stability. This prevented the attacker from continuing the attack and forced them to bear the losses from swap gas, fees, and slippage from large trades.

Cobo Comment

While Uniswap V2/V3 Oracle can resist flash loan attacks, it cannot directly counter large fund manipulation. Therefore, for trading pairs with lower liquidity, there remains a risk of oracle price manipulation.

From the attacker's perspective, conducting a manipulation attack on Uniswap V2/V3 Oracle requires a high attack cost and necessitates holding a significant portion of the target tokens in the manipulated pool; otherwise, the situation described above may occur, where other large holders of the target tokens arbitrage, ultimately resulting in a failed attack.

Reference

https://twitter.com/samczsun/status/1486243806739587076

OpenSea Frontend Vulnerability

@PeckShield reported that OpenSea may have a frontend issue, with users profiting 347 ETH from this problem. This vulnerability may be related to the issue disclosed by @yakirrotem.

The trading architecture of OpenSea is as follows:

• The seller initiates a listing (equivalent to a quote), at which point the user signs the quote data, indicating agreement to sell their NFT at the set price.

• This signed data is stored in OpenSea's off-chain database. When a buyer purchases the NFT on OpenSea, OpenSea verifies this signed data on-chain, and upon success, completes the NFT transfer, collecting a portion of the fees.

• Before the sale, the seller can also cancel the previous listing. A canceled listing will fail verification on-chain, thus not being sold.

The issue here is that OpenSea allows a new listing to be initiated without canceling the original listing (this issue has now been fixed). At this point, although the seller's old quote is no longer visible on the OpenSea UI, the old listing still exists and is valid.

Attackers can query the old listing at https://orders.rarible.com. Since OpenSea's listing does not have a transaction Nonce mechanism, the old listing remains valid. Attackers can directly purchase NFTs through the old listing and sell them at a new price. Due to the significant price fluctuations of NFTs, this method can yield substantial arbitrage profits.

For example, on January 24, a BAYC NFT was first bought on OpenSea for 0.77 ETH and then sold for 84.2 ETH.

Cobo Comment

Ordinary users are advised to log in to https://orders.rarible.com to check for any old listings and immediately cancel them. A more secure approach is to transfer the NFT to a new address.

Reference

https://twitter.com/PeckShieldAlert/status/1485547426467364864

https://twitter.com/yakirrotem/status/1485559864948629512

Metamask IP Leak Vulnerability

@alxlpsc disclosed on Medium that Metamask has a serious privacy leak issue. The vulnerability primarily exploits MetaMask's automatic loading of NFT image URLs. The basic attack idea is that attackers can set the URI of an NFT to a server URL they control.

They then transfer the NFT to the target account; when the user logs into Metamask, it automatically scans the NFTs owned by the account and initiates an HTTP request to the attacker's server; the attacker can then obtain the victim's IP information from the access logs.

Cobo Comment

The anonymity of blockchain primarily comes from the separation of on-chain addresses and off-chain identities. If on-chain addresses can confirm off-chain identities, it poses a serious threat in the blockchain context. In traditional security, leaking a host's IP is usually not considered a particularly severe issue (after all, a phishing message or email could achieve this), but in the blockchain world, which advocates anonymity, the importance of privacy escalates. It is believed that similar situations, where the severity of vulnerabilities varies due to different security contexts, will continue to emerge in the relatively new field of blockchain.

Reference

https://medium.com/@alxlpsc/critical-privacy-vulnerability-getting-exposed-by-metamask-693c63c2ce94

wxBTRFLY Vulnerability Disclosure and Fix

White hat hackers from @immunefi discovered a serious vulnerability in the wxBTRFLY Token contract. The transferFrom function in the contract did not correctly update the recipient's authorization and incorrectly updated msg.sender's authorization.

Although the vulnerability itself is serious, its cause is not complex (more like a developer's typo). Interestingly, the official fix approach was taken. Since the contract itself does not support upgrades, the contract code could not be directly updated; the contract does not support pausing, so there was no way to transfer user assets using a snapshot and migration. Ultimately, the official measure was to initiate an attack transaction themselves, transferring all assets of affected users to a multi-signature wallet. After deploying a new Token contract, these assets will be redistributed.

Cobo Comment

ERC20 Tokens already have relatively mature code templates, and wxBTRFLY encountered issues while rewriting transferFrom. This problem should have been easily discovered with comprehensive unit testing, indicating that the project team may have lacked a thorough testing process during development.

Reference

https://discord.com/invite/rpkPDR7pVV

https://twitter.com/redactedcartel/status/1482497468713611266?s=20

https://etherscan.io/tx/0xf0e4ccb4f88716fa5182da280abdb9ea10ec1c61cfc5bbe87e10bdde07c229d6

Qubit Cross-Chain Bridge Attacked

On January 28, the cross-chain bridge QBridge of the DeFi platform Qubit Finance on BSC was attacked, resulting in a loss of approximately $80 million.

A common implementation of cross-chain bridges involves collateralizing assets in the source chain's contract and emitting events. Listening nodes capture the events and call the cross-chain bridge contract on the target chain to mint an equivalent amount of assets. As long as an event occurs on the source chain, the cross-chain bridge system assumes there are cross-chain assets to be transferred.

However, if there is an issue with the code of the cross-chain bridge contract on the source chain, it may emit events without any assets being collateralized in the cross-chain bridge contract, creating a vulnerability that leads to incorrect minting of tokens on the target chain.

QBridge had such a problem. QBridge supports collateralizing both ETH and ERC20 tokens. Since Ethereum's ETH is the native token, it is handled by two separate code sets from ERC20 tokens. When collateralizing tokens on the source chain, the deposit method is called, and ETH should call the depositETH method during collateralization.

QBridge used the zero address as the identifier for ETH. However, the implementation lacked proper validation, causing the contract to still use the deposit method when handling ETH, effectively treating ETH as a token with a contract address of zero. When transferring using transferFrom, it is equivalent to calling a contract on the zero address.

In Ethereum's underlying design, making a contract call to an EOA address will default to success and not revert. Combining these conditions, the final situation is that although the attacker did not collateralize any assets on the source chain, they could still mint a large amount of qXETH on the target chain for profit.

Cobo Comment

Currently, the blockchain industry features multiple chains coexisting, and cross-chain bridges have become important infrastructure. Cross-chain bridges are inherently more complex than ordinary dapps due to the need for on-chain and off-chain coordination, making them more prone to issues. Additionally, cross-chain bridges typically collateralize large amounts of assets, and if they can be transferred illegally, the profits can be substantial. Various cross-chain bridge systems seem to have become key targets for attackers in recent months.