Cobo Labs is the largest cryptocurrency custody platform in the Asia Pacific and the cryptocurrency research laboratory of Cobo, the most popular financial management service provider for institutions.
We focus on innovative projects, cutting-edge encrypted digital technology, global market compliance trends, market fundamentals and volatility factors; aiming to help market participants and cryptocurrency enthusiasts lower the cognitive threshold for entering the market.
This article was contributed by the Cobo blockchain security research team. The team members are from well-known security laboratories. They have many years of experience in network security and vulnerability mining. They have assisted Google and Microsoft in dealing with high-risk vulnerabilities, and have been thanked by Google, Microsoft and other manufacturers. Achieved excellent results in Microsoft MSRC Top List of Most Valuable Security Researcher. The team is currently focusing on smart contract security, DeFi security, etc., researching and sharing cutting-edge blockchain security technologies.
We also hope that lifelong iterative learners who have research spirit and scientific methodology in the field of encrypted digital currency can join us and export thinking insights and research views to the industry!
text
Cross-chain bridge Multichain vulnerability
On January 18, the well-known cross-chain bridge Multichain (formerly Anyswap) discovered and fixed a vulnerability that had an important impact on 6 tokens including WETH, PERI, OMT, WBNB, MATIC, and AVAX. All users who have authorized the above-mentioned tokens on Multichain Router are affected, and attackers can directly take advantage of the loopholes to transfer away the tokens authorized by users. According to the official announcement on the 19th, because some users did not cancel the authorization in time, about 445 WETH were stolen by the attacker.
text
Cobo Comment
text
Reference
https://github.com/W2Ning/Anyswap_Vul_Poc
https://theblockbeats.info/news/28774
https://hackernoon.com/erc20-infinite-approval-a-battle-between-convenience-and-security-lk60350r
text
text
The problem is that the setTrustedForwarder function of the MasterChef contract does not perform permission verification correctly. After the attacker modifies TrustedForwarder, he can forge the effect of msg.sender, so as to directly obtain the owner authority of MasterChef. Then use the owner privilege to call the set function to set the strategy as the attackers malicious parameter 0xccddce9f0e241a5ea0e76465c59e9f0c41727003. After modifying the strategy, a large amount of CRSS Token can be withdrawn with a small amount of deposit to make a profit.
The official announcement also admitted that this vulnerability was too obvious, and it seemed that the developers did it intentionally. After an internal investigation, 4 developers were fired. At present, a snapshot of the data on the chain has been taken, and it will be redeployed later. The overall code audit has already started on the official git, and it is said that it will cooperate with Certik to conduct the audit later.
Cobo Comment
text
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 Float Protocol Pool suffers oracle manipulation attack
On January 15th, Pool No. 90 on RariCapital, namely the Float Protocol pool, suffered an oracle manipulation attack.
The pool uses the Uniswap V3 FLOAT/USDC trading pair to quote, and a few days before the attack, the liquidity in the FLOAT/USDC pool dropped (only ~$550k left), and the low liquidity gave the attackers the opportunity to manipulate the oracle chance of attack. The attacker used 47 ETH (worth about $120k) to exchange USDC for FLOAT in the pool, causing the quotation of FLOAT to increase. Then use FLOAT to mortgage to the Rari #90 pool to lend other assets to realize profit. The attack method is consistent with the Rari #23 pool Vesper Lend Beta attack that occurred in November 2021.
Cobo Comment
text
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 loophole was found in the DUSD contract, the contract has been suspended, and all funds are safe. It is claimed that the vulnerability may have been discovered automatically using a blockchain monitoring system. The idea is to monitor the transfer of Tornado.Cash to a new address on the chain and deploy the contract (this is a typical initial preparation behavior in many real attacks). Further through the analysis of contracts and related transactions, potential attacks are discovered, and when problems are found, relevant project parties will be notified immediately for prevention. Someone has implemented a similar Agent on Forta.
Cobo Comment
text
Reference
https://twitter.com/AndreCronjeTech/status/1479778350084333574
https://connect.forta.network/agent/0x2fbec7dcd4eebf34c5b94d899109057eea3642a2400b7143e64873d453b7ba61
Rari pool #19 attack failed
The well-known blockchain security white hat @samczsun issued an early warning tweet against Rari #19 (Index Coop Pool), but the subsequent attack did not actually occur.
The attack method is similar to the aforementioned Float Protocol Rari #90 oracle attack. The attacker converted about 300 ETH into BED in Uniswap V3 to manipulate the currency price. Since the Uniswap V2/V3 Oracle will update the currency price only in the second block, the attacker cannot complete the manipulation of the currency price in one transaction, thus resisting flash loan attacks. When using real large funds for manipulation, the attacker needs to wait until at least the second block to see the reaction of the currency price. Because of the TWAP, the attacker usually has to wait a few minutes longer for the coin price to become more apparent. For this attack, the attackers did exactly that. However, it is embarrassing that a suspected arbitrage robot appeared in the second block. This address immediately converted a large amount of BED into ETH in the second block, maintaining the stability of the original currency price. This makes it impossible for the attacker to continue the attack, and also bears the loss of swap gas, handling fees, and slippage of large orders.
Cobo Comment
text
Reference
https://twitter.com/samczsun/status/1486243806739587076
text
@PeckShield posted that OpenSea may have a front-end problem, and some users took advantage of this problem to make a profit of 347 ETH. This vulnerability may be related to the issue disclosed by @yakirrotem.
OpenSeas transaction structure is:
When the seller initiates a listing (equivalent to a quotation), the user will sign the quotation data and agree to sell their NFT at the set price.
This signature data will be stored in OpenSeas off-chain database. When the buyer purchases the NFT on OpenSea, OpenSea will upload the signature data to the chain for verification. After passing the NFT transfer, OpenSea will also charge a part of the handling fee.
Before selling, the seller can also cancel the previous listing, and the canceled listing will fail to be verified on the chain, so it will not be sold.
The problem here is that OpenSea allows listings to be launched again without canceling the original listing (this problem has been fixed now). At this time, although the sellers old quotation is no longer visible on the OpenSea UI, the old listing still exists and is valid. An attacker can look up old listings at https://orders.rarible.com. Since OpenSeas listing does not have a transaction Nonce mechanism, the old listing is still valid. Attackers can directly buy NFTs through old listings and sell them at new prices. Due to the sharp price fluctuations of NFT, huge arbitrage can be achieved in this way.
https://etherscan.io/token/0xbc4ca0eda7647a8ab7c2061c2e118a18a936f13d?a=9991#inventory is an example: On January 24, BAYC’s NFT was first bought at 0.77 ETH on OpenSea, and then sold at 84.2 ETH.
Cobo Comment
text
Reference
https://twitter.com/PeckShieldAlert/status/1485547426467364864
https://twitter.com/yakirrotem/status/1485559864948629512
Metamask leaks personal IP vulnerability
@alxlpsc disclosed on medium that Metamask has a serious privacy breach. The vulnerability mainly uses MetaMask to automatically load the NFT image URL. Basic attack idea: The attacker can set the URI of the NFT to a server URL that he can control, and transfer the NFT to the target account; when the user logs in to Metamask, Metamask will automatically scan the NFT owned by the account and initiate a link to Attackers servers HTTP request; the attacker can get the victims IP information from the access log.
Cobo Comment
text
Reference
https://medium.com/@alxlpsc/critical-privacy-vulnerability-getting-exposed-by-metamask-693c63c2ce94
wxBTRFLY Vulnerability Disclosure and Fixes
White hat hackers from @immunefi discovered a serious vulnerability in the wxBTRFLY Token contract. The transferFrom function in the contract does not update the authorization of recipient correctly, and it will update the authorization of msg.sender incorrectly.
Although the vulnerability itself is serious, the cause is not complicated (more like a developers clerical error), and the more interesting thing is the official repair method. Since the contract itself does not support upgrades, the contract code cannot be directly updated; the contract does not support suspension, so there is no way to transfer user assets by snapshot + migration. The final official measure was to launch an attack transaction by itself, transferring the assets of all users affected by the vulnerability to a multi-signature wallet. It will be distributed after the new Token contract is deployed later.
Cobo Comment
text
Reference
https://discord.com/invite/rpkPDR7pVV
https://twitter.com/redactedcartel/status/1482497468713611266?s=20
https://etherscan.io/tx/0xf0e4ccb4f88716fa5182da280abdb9ea10ec1c61cfc5bbe87e10bdde07c229d6
Qubit cross-chain bridge was attacked
On January 28, the cross-chain bridge QBridge of the DeFi platform Qubit Finance on BSC was attacked, causing a loss of about 80 million US dollars.
A common implementation form of cross-chain bridges is to mortgage assets in the contract of the source chain and emit events. The listening node captures the event, initiates a call to the cross-chain bridge contract of the target chain, and mint equivalent assets. As long as there is an event on the source chain, the cross-chain bridge system will consider that there are cross-chain assets that need to be transferred. However, if there is a problem with the code of the cross-chain bridge contract on the source chain, there may be a situation where no assets are mortgaged into the cross-chain bridge contract but the event is still emitted, resulting in loopholes and resulting in the wrong issuance of tokens on the target chain.
QBridge has such a problem. QBridge supports mortgage ETH and ERC20 Token two types of assets. Since Ethereums ETH is used as a native token, it is handled by two separate codes from ERC20Token. When mortgaging Token in the source chain, the deposit method will be called, and ETH should call the depositETH method when mortgaging. QBridge uses the zero address as the identity of ETH. However, there is no perfect verification in the implementation, so the contract still uses the deposit method when processing ETH, which is equivalent to treating ETH as a Token whose contract address is zero. Using transferFrom when transferring money is equivalent to making a contract call to zero address. In terms of the underlying design of Ethereum, initiating a contract call to the EOA address will succeed by default and will not revert. Combining the above conditions, the final situation is that although the attacker has not mortgaged any assets on the source chain, he can still mint a large amount of qXETH on the target chain to realize profits.
Cobo Comment
At present, multiple chains coexist in the blockchain industry, and the cross-chain bridge is already an important infrastructure. The overall complexity of the cross-chain bridge itself is much higher than that of ordinary dapps due to the need for on-chain and off-chain cooperation, so it is more prone to problems. At the same time, a large number of assets are usually mortgaged on the cross-chain bridge, and if it can be transferred illegally, it will be very profitable. Various cross-chain bridge systems seem to have become the key targets of attackers in the past one or two months.
Reference
https://mp.weixin.qq.com/s/PLbuI9JFxyFRlDlj9rPvmQ
https://mp.weixin.qq.com/s/-kTsAs2WH5_4N4_3-XIxag
Cobo Labs hopes to help investors in the encrypted world avoid risks and increase returns, and provide objective and in-depth data analysis for traditional financial institutions, venture capital companies, token funds, individual investors, exchanges, media and other partners.
About Cobo, the largest cryptocurrency custody and asset management platform in the Asia-Pacific: We provide institutions with leading security custody and corporate asset management services; we provide encrypted digital wallet services and rich and flexible regular and structured products to global high-net-worth qualified investors, We focus on financial innovation and established the first fund product DeFi Pro for global institutions in the third quarter of 2020.
