DeFi can certainly bring considerable benefits to users, but financial security is the core of steady asset growth. The Cobo security team has sorted out the common security risks in DeFi interactions and the corresponding security precautions, hoping to inspire and help everyone's DeFi security interactions in the bull market.
Since the launch of DeFi Summer in 2019, more and more creative decentralized financial protocols (DeFi) have appeared, led by Ethereum. Protocol), which greatly enriches the availability of on-chain assets, allowing blockchain users to better utilize on-chain assets to conduct more diverse financial activities and create substantial returns. But with the rise of more and more DeFi protocols, security challenges also arise. According to incomplete statistics, in 2023 alone, asset losses caused by blockchain attacks have reached US$2.61 billion. It can be seen that in the process of participating in the DeFi protocol, in addition to evaluating the corresponding revenue expectations, the evaluation of the security of the protocol cannot be ignored, otherwise it will bring big losses to users.
Generally speaking, the current mainstream definition of protocol security assessment is code security assessment. The dimension of this definition is relatively single. The problem here is , the evaluation itself only considers the security of the protocol in the static process, while in the DeFi interaction process, security is often dynamic, including account management, preparation before protocol interaction, asset management after the interaction is completed, data monitoring and Multiple stages including self-rescue after asset loss under extreme circumstances.
As a user who is about to enter the DeFi Novice Village, how can you maximize the security of your funds while earning income? The Cobo security team has sorted out common security risks in DeFi interactions and corresponding security precautions, hoping to inspire and help everyone's DeFi security interactions in the bull market.
Common security risks and precautions in DeFi interactions
1. Account private key leaked
Account private key leaked This is one of the problems that novice users are more likely to fall into. Due to the wide variety of wallets on the market, novice users lack the ability to judge the security of wallets by themselves. Many novice users will download some unsafe wallets and use them to generate private keys. , causing the private key to be maliciously transmitted back to the attacker, causing the private key to be leaked. Many experienced users found that all their assets were transferred from their main account on a certain day. After analysis for most of the day, they found that all the behaviors were normal. In most of these cases, the account used an unsafe wallet to generate its own private key. The private key has long been leaked.
At the same time, due to the wealth effect caused by blockchain airdrops, many novice users will blindly click on some so-called airdrop websites. These airdrop websites package themselves as very serious project web page and inform users that there are a large number of unclaimed tokens. Driven by profit, many novice users will be induced by web pages to fill in their own account private keys, causing the private keys to be leaked.
In order to prevent the leakage of private keys, users need to do the following to prevent it:
Use a well-known blockchain wallet and download the wallet from the corresponding official website. Qualified users are recommended to use hardware wallets.
Never expose your private key in plain text to the Internet, and do not arbitrarily expose your private key to the Internet. Enter your private key into any web page.
2. Signature Phishing Risk
Signature phishing risks are the same as private key leaks, and they are also the hardest hit area for novice users. Different from directly asking users to fill in their private keys, this type of phishing attack induces users to initiate a transaction or signature to obtain authorization for user-related assets. It is highly concealed, difficult to analyze, and difficult to detect.
Usually, the attacker will first induce the user to a phishing webpage, and let the user initiate a signature in the name of receiving airdrops, verifying login, etc. At this time, the user's browsing The server wallet prompts the user to complete the signature.
There may be many types of phishing transactions:
Direct transfer type. Transfer ETH directly or make an ERC20 transfer call to transfer wallet assets to the attacker's address.
Approve type. Call the ERC20 Approve method to authorize the attacker's wallet. No transfer of assets occurs when the user signs. However, the attacker's wallet can transfer user assets by calling transferFrom.
EIP712 message signature. Such as ERC20 Permit method; Permit2 authorization; NFT pending order signature, etc. Such signatures are usually displayed in the wallet as Json data or well-formatted tree data. No transaction will be initiated when the user signs, and there will be no gas consumption. However, the signature result will be recorded by the phishing website, and the attacker can use the signature result to transfer the victim's ERC20 or NFT assets.
Original hash signature. The signature data is hexadecimal hash data, and the specific signature content cannot be inferred from the signature data itself. Behind the hash may be the above 1-3 types of data. Signatures are likely to result in loss of assets. However, current mainstream wallets usually prohibit this signature method or provide obvious risk warnings.
In recent cases, it has been found that some phishing websites will require users to sign multiple times in a row, and the first few signatures are A harmless normal signature. Then mix in a malicious signature. Use the user's operational inertia to induce the user to complete the signature operation.
In order to prevent financial losses caused by phishing, thecore is to refuse blind signing. Carefully review each signature and refuse to sign transactions with uncertain content. Specifically, you can pay attention to the following during the signing process:
Confirm interaction The website is the official website of the DeFi project, check the complete domain name.
Check the methods called by the contract, focusing on the transfer and approve methods.
Check the ETH transfer attached to the transaction. Some phishing websites will try to construct methods that look safe (such as Claim), but will actually include an ETH transfer when calling, causing the loss of chain-native tokens such as ETH.
Do not sign the original hash content.
3. Transfer address poisoning
< p style="text-align: left;">Transfer address poisoning is a relatively new attack method recently. The attack method is to use the same as the received in the transaction when the user initiates a transfer (ERC20, native token, etc.) Addresses with similar addresses send users a transaction with the same amount, or a transaction with the same amount but the corresponding token is a fake token.
Example:
Alice transfers 1 ETH to Bob as salary every month . Charlie monitored this transaction and sent 0.001 ETH to Alice using an address similar to Bob's (the first 8 digits and the last 8 digits of the address are the same). After this operation, the next time Alice transfers money to Bob, it is possible to use Charlie's address as the receiving address of the transaction. The reason why this happens is that blockchain addresses are long and irregular, making it difficult for users to remember. As a result, many times users will copy the address directly from the last transaction record for convenience. Since the addresses of Charlie and Bob are very similar, it is difficult for Alice to distinguish them, which ultimately leads to asset loss.
In order to prevent transfer addresses from being poisoned, users can take the following precautions:
Check the transfer address for each transaction, and check the complete content rather than just comparing a few bytes before and after.
Set frequently used addresses into the address whitelist (address book) and set aliases as much as possible Only use addresses in your address book for transfers.
Avoid using on-chain channels (including blockchain browsers, wallet transaction records, etc.) Copy the address as the transfer destination.
4. Over-authorization of tokens< /p>
Token authorization is almost the first step in DeFi interaction. When performing DeFi operations, since the transaction data is constructed through the project's webpage rather than the user's structure, under normal circumstances, in order to facilitate the user's multiple interactions without repeated authorization, the project's webpage usually constructs an unlimited authorization transaction for the user. sign. The starting point is to save gas for users, but this also creates hidden dangers for subsequent fund security. Assuming problems occur in subsequent project codes, such as unauthorized interfaces or arbitrary calling vulnerabilities, the user's unlimited authorization to the contract will be exploited by attackers, resulting in the transfer of user assets. This attack scenario is more common in cross-chain bridges and DEX protocols.
In order to prevent subsequent projects from introducing risky code in upgrades or from undiscovered vulnerabilities in the project code itself, users should adopt the principle of minimum authorization and try to only Authorize the amount used in this transactionto prevent subsequent project risks from causing losses to your assets.
5. Unsafe DeFi operations
In addition to preparation before interaction, there are also many risks that are easily overlooked during the interaction process. These risks usually arise from users' lack of understanding of the project itself. Specific examples are:
Slippage during token exchange through the on-chain exchange protocol If the setting is too large or the minimum receiving quantity is not set in the script for swap (set to 0 for convenience of writing), the transaction will be subject to a "sandwich" attack by the MEV robot.
When conducting lending operations through the on-chain lending agreement, the health of the position was not managed in a timely manner, resulting in the loss of positions during large market fluctuations. Being liquidated.
When interacting with some projects, the project party’s credentials were not well kept, such as treating Uniswap V3’s NFT credentials as It is an ordinary NFT sold in OpenSea.
In order to prevent these risks, users must conduct corresponding project research and clarify the project mechanism and Relevant features to prevent asset loss.
DeFi New Paradigm for Secure Transactions--Cobo Argus
The above introduces the common interaction risks of DeFi activities on the blockchain. If a user accidentally falls into one of these traps, years of hard work may be lost, and even the slightest carelessness will lead to irreparable damage. So, is there a risk control plan that is safe, effective, and easy to manage? A new option is the Cobo Argus.
Cobo Argus is an on-chain risk control product developed by the Cobo team and built on Gnosis Safe. The main function is to analyze user transactions by constructing different ACL strategies and intercept transactions that do not comply with risk control rules, thereby ensuring the safety of user funds.
How does Cobo Argus deal with security risks in the DeFi environment?
1. Bottom-level multi-signature wallet, upper-level single-signature authorization: avoid single-point risk of private key leakage, slow down Eliminate phishing risks while ensuring operational efficiency
Cobo Argus is a product built on Safe {Wallet}'s multi-signature wallet. Its foundation and core are Multi-signature contract wallet. Therefore, Cobo Argus naturally inherits the security of Safe {Wallet} multi-signature wallet.
By changing the management of funds from a single private key to the joint maintenance of multiple private keys, the risk of asset loss/locking caused by the leakage of a single private key can be eliminated. The multi-signature wallet itself requires multiple signatures to trigger the execution of transactions, and the leakage of a single address's private key will not affect the overall security of funds. In addition, multi-signature transactions can be initiated to replace lost or risky single-signature addresses to ensure the security of the multi-signature wallet.
In addition, after switching from a single signature address to a multi-signature address, each user is required to sign a transaction when signing a transaction, which is conducive to cross-auditing. Transaction content, thereby greatly reducing the possibility of being phished.
Multiple signatures require multiple people to review, which has a certain impact on operational efficiency. Cobo Argus allows users to configure flexible authorization rules, allowing certain low-risk high-frequency operations (such as regular claims of income during farming) to be authorized to a certain EOA address. This address can initiate operations instead of a multi-signature wallet to improve work efficiency. At the same time, since the address permissions are strictly restricted, the overall security of the wallet will not be significantly affected.
2. Custom robot: 7*24 hours automatic risk monitoring and response
By configuring the Cobo Argus monitoring robot, you can customize the conditions that need to be monitored and the operations that need to be performed when triggering conditions.
Take the leverage management of lending projects as an example. Users can configure the Argus robot to monitor their health factor. When the position is close to liquidation, the robot can supplement the mortgage. Leverage-reducing operations such as property and repayment.
3. Customized ACL policy
In addition to self- In addition to defining monitoring robots, users with certain development capabilities can also develop customized ACL (Access Control List) contracts to achieve more flexible permission management. This is one of the core features of Cobo Argus. Here are some examples to feel the charm of this feature:
Position based on address To prevent poison attacks, you can write an ACL contract. Users can specify commonly used addresses as whitelists in the ACL contract. During the transaction process, the ACL contract will parse the receiving address in the transaction (ERC20/native token). And compare the whitelist addresses set by the user. If the receiving address is not within the corresponding address, the transaction cannot be completed successfully.
To address the problem of over-authorization, users can write an ACL policy contract to set the authorization limit in Approve transactions. Analyze and limit the token's Approve authorization amount to no more than the user's preset value. Or 1, you can configure a custom robot to clear the authorization of the relevant tokens regularly.
For unsafe DeFi operations, such as swap transactions without slippage check, you can write The Argus ACL strategy contract sets the minimum acceptable slippage for exchange transactions. After the setting is completed, the ACL strategy contract can analyze different swap transactions based on the set slippage. If the exchange slippage is not met, it can The transaction is intercepted.
Summary
There are many risks that are difficult to prevent in DeFi interactions. Although the content mentioned in the article covers many common scenarios, it cannot completely cover all risk points. Users need to handle every transaction carefully.
Cobo Argus can provide users with reliable and easy-to-configure means to prevent some common security risks. Flexible and secure authorization management can be completed through ACL, improving operational efficiency while ensuring security; custom robots can reduce manual operations, and the real-time monitoring capability can ensure the security of user funds 7*24 hours.
DeFi can certainly bring considerable benefits to users, but financial security is the core of steady asset growth. Cobo Argus will protect every DeFi Farmer and help everyone create more value in the bull market.
JinseFinance
Darren
Tech Flow
Coindesk
Coinlive 
Bitcoinist
Cointelegraph