Cobo Security Team: Bull Market DeFi Interaction Guide

Author: Cobo Security Team

Since the onset of DeFi Summer in 2019, a growing number of creative decentralized finance protocols (DeFi protocols) have emerged, led by Ethereum, significantly enriching the availability of on-chain assets. This has enabled blockchain users to better utilize on-chain assets for a wider range of financial activities and generate substantial returns. However, with the rise of more DeFi protocols, security challenges have also arisen. According to incomplete statistics, the asset losses due to blockchain attacks have reached $2.61 billion in just 2023. It is evident that in the process of participating in DeFi protocols, the assessment of protocol security cannot be overlooked, in addition to evaluating the expected returns; otherwise, it may lead to significant losses for users.

Generally speaking, the current mainstream definition of protocol security assessment is the evaluation of code security, which has a relatively narrow dimension. The issue here is that the assessment only considers the security of the protocol in a static process, while in the DeFi interaction process, security is often dynamic and includes multiple stages such as account management, preparation before protocol interaction, asset management after interaction completion, data monitoring, and self-rescue after asset loss in extreme cases.

As a user about to enter the DeFi novice village, how can one maximize the security of funds while earning returns? The Cobo Security Team has outlined common security risks in DeFi interactions and corresponding preventive measures, hoping to inspire and assist everyone in safe DeFi interactions during a bull market.

Common Security Risks and Preventive Measures in DeFi Interactions

1. Account Private Key Leakage

Account private key leakage is one of the issues that novice users are more likely to encounter. Due to the wide variety of wallets available on the market, novice users often lack the ability to assess wallet security themselves. Many novice users download insecure wallets and use them to generate private keys, leading to the malicious transmission of private keys back to attackers and causing key leakage. Many experienced users find that their main account has had all assets transferred one day, and after analyzing for a long time, they discover that all actions appeared normal. In most cases, this is due to the early use of an insecure wallet to generate their private key, resulting in its leakage.

At the same time, due to the wealth effect caused by blockchain airdrops, many novice users blindly click on so-called airdrop websites. These airdrop websites package themselves as very legitimate project pages and inform users of a large number of unclaimed tokens. Driven by profit, many novice users fill in their account private keys under the inducement of the webpage, leading to key leakage.

To prevent private key leakage, users should take the following precautions:

Use well-known blockchain wallets and download them from the corresponding official websites. Users with conditions are advised to use hardware wallets.

Never expose your private key in plaintext in a networked environment, and do not casually input your private key into any webpage.

2. Signature Phishing Risks

Signature phishing risks, like private key leakage, are also a major issue for novice users. Unlike directly asking users to input their private keys, this type of phishing attack induces users to initiate a transaction or signature, thereby obtaining authorization for the user's related assets. It is characterized by high concealment, difficulty in analysis, and being hard to detect.

Typically, attackers will first lure users to a phishing webpage, asking them to initiate a signature under the pretext of claiming an airdrop or verifying login. At this point, the user's browser wallet prompts them to complete the signature.

Types of phishing transactions may vary:

Direct transfer type. Directly transferring ETH or calling ERC20 transfer to move wallet assets to the attacker's address.

Approve type. Calling the ERC20 Approve method to authorize the attacker's wallet. No asset transfer occurs when the user signs. However, the attacker's wallet can transfer user assets by calling transferFrom.

EIP712 message signature. Such as the ERC20 Permit method; Permit2 authorization; NFT listing signatures, etc. These signatures are usually displayed in the wallet as JSON data or well-formatted tree data. No transaction is initiated when the user signs, and there is no gas consumption. However, the signature result will be recorded by the phishing site, and the attacker can use that signature to transfer the victim's ERC20 or NFT assets.

Raw hash signature. The signature data is hexadecimal hash data, and the specific signature content cannot be inferred from the signature data itself. The hash may correspond to the aforementioned types 1-3. Signing could likely lead to asset loss. However, mainstream wallets usually prohibit this type of signature method or provide clear risk warnings.

Recently, some cases have also found that certain phishing sites require users to perform multiple signatures consecutively, with the first few being harmless normal signatures, then mixing in a malicious signature. This exploits the user's habitual actions to induce them to complete the signature operation.

To prevent financial losses caused by phishing, the key is to refuse blind signing. Carefully review each signature and reject signatures for transactions with uncertain content. Specifically, during the signing process, pay attention to the following:

Confirm that the interaction website is the official website of the DeFi project and check the complete domain name.

Check the method of contract calls, with a focus on transfer and approve methods.

Check the ETH transfer accompanying the transaction. Some phishing sites may attempt to construct seemingly safe methods (like Claim), but actually attach ETH transfers that cause losses of ETH or other native tokens.

Do not sign raw hash content.

3. Transfer Address Poisoning

Transfer address poisoning is a relatively novel attack method, where the attacker sends a transaction with an address similar to the recipient address in the user's initiated transfer (ERC20, native token, etc.) with the same amount, or a transaction with the same amount but a fake token.

For example:

Alice regularly transfers 1 ETH to Bob as salary every month. Charlie monitors this transaction and sends 0.001 ETH to Alice from an address similar to Bob's (the first 8 characters and the last 8 characters are the same). After this operation, when Alice transfers to Bob again, she may use Charlie's address as the recipient address. This situation occurs because blockchain addresses are long and irregular, making them hard to remember, leading users to often copy addresses directly from previous transaction records for convenience. Due to the extreme similarity between Charlie's and Bob's addresses, Alice finds it difficult to distinguish, ultimately resulting in asset loss.

To prevent falling victim to transfer address poisoning, users can take the following measures:

Verify the transfer address for each transaction, and check the complete content rather than just comparing a few bytes at the beginning and end.

Set frequently used addresses in an address whitelist (address book) and assign aliases, trying to use only addresses from the address book for transfers.

Avoid copying addresses from on-chain sources (including blockchain explorers, wallet transaction records, etc.) as transfer targets.

4. Excessive Token Authorization

Token authorization is almost the first step in DeFi interactions. When performing DeFi operations, since transaction data is constructed through the project’s webpage rather than by the user, it is common for project webpages to construct a transaction with unlimited authorization for users to sign, in order to save gas for users. However, this also lays hidden risks for subsequent fund security. If the project code later encounters issues, such as unauthorized interfaces or arbitrary call vulnerabilities, the user's unlimited authorization to the contract will be exploited by attackers, leading to the transfer of user assets. This type of attack scenario is more common in cross-chain bridges and DEX protocols.

To prevent risks from project upgrades introducing risky code or undiscovered vulnerabilities in the project code itself, users should adopt the principle of minimal authorization, authorizing only the amount used in the current transaction to prevent asset loss due to subsequent project risks.

5. Unsafe DeFi Operations

In addition to pre-interaction preparations, there are also many easily overlooked risks during the interaction process. These risks often stem from users' lack of understanding of the project itself. Specific examples include:

Setting slippage too high when exchanging tokens through on-chain exchange protocols or writing scripts for swaps without setting a minimum received amount (setting it to 0 for convenience), leading to the transaction being subjected to MEV bots' "sandwich" attacks.

Not managing position health in a timely manner during borrowing operations through on-chain lending protocols, resulting in liquidation during significant market fluctuations.

Failing to properly safeguard project credentials when interacting with certain projects, such as treating Uniswap V3 NFT credentials as ordinary NFTs and selling them on OpenSea.

To mitigate these risks, users must conduct thorough research on the corresponding projects during interactions, clarifying project mechanisms and related characteristics to prevent asset loss.

New Paradigm of DeFi Security Transactions -- Cobo Argus

The above text introduces common interaction risks in DeFi activities on the blockchain. A careless mistake in any of these could lead to the loss of years of effort, and a slight misstep could result in irreversible consequences. So, is there a safe, effective, and manageable risk control solution? A new option is Cobo Argus.

Cobo Argus is an on-chain risk control product developed by the Cobo team, built on Gnosis Safe. Its 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 security of user funds.

How does Cobo Argus address security risks in the DeFi environment?

1. Underlying multi-signature wallet, upper-layer single-signature authorization: Avoid single-point risks of private key leakage, mitigate phishing risks, while ensuring operational efficiency

Cobo Argus is a product built on a multi-signature wallet based on Safe {Wallet}, with its foundation and core being a multi-signature contract wallet. Therefore, Cobo Argus inherently inherits the security of the Safe {Wallet} multi-signature wallet.

By changing fund management from a single private key to multiple private keys jointly maintained, it eliminates the risk of asset loss/lock due to a single private key leakage. A multi-signature wallet 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 the funds. Additionally, multi-signature transactions can be initiated to replace lost or risky single-signature addresses, ensuring the security of the multi-signature wallet.

Moreover, since the transition from a single-signature address to a multi-signature address requires each user to sign a transaction, it facilitates cross-auditing of transaction content, greatly reducing the likelihood of phishing.

Due to the need for multiple people to review, multi-signature operations may impact operational efficiency. Cobo Argus allows users to configure flexible authorization rules, permitting certain low-risk high-frequency operations (such as regularly claiming rewards during farming) to be authorized to a specific EOA address. This address can initiate operations on behalf of the multi-signature wallet, improving work efficiency. At the same time, since the permissions of this address are strictly limited, the overall security of the wallet will not be significantly affected.

2. Custom Bots: 24/7 Automatic Risk Monitoring and Response

By configuring Cobo Argus monitoring bots, users can customize the conditions to be monitored and the actions to be executed when trigger conditions are met.

For example, in the case of leverage management for lending projects, users can configure the Argus bot to monitor their health factor. When the position approaches liquidation, the bot can perform operations such as adding collateral or repaying to reduce leverage.

3. Custom ACL Strategies

In addition to custom monitoring bots, users with certain development capabilities can also achieve more flexible permission management by developing custom ACL (Access Control List) contracts. This is one of the core functions of Cobo Argus. Below are several examples to appreciate the charm of this function:

For address poisoning attacks, users can write an ACL contract to specify commonly used addresses as a whitelist. During transactions, the ACL contract will analyze the recipient address in the transaction (ERC20/native token) and compare it with the user-defined whitelist. If the recipient address is not in the corresponding list, the transaction cannot be successfully completed.

For excessive authorization issues, users can write ACL strategy contracts to analyze the authorization amount in Approve transactions, limiting the token's Approve authorization amount to not exceed the user's preset value. Alternatively, users can configure custom bots to periodically reset the authorization of related tokens.

For unsafe DeFi operations, such as swap transactions without slippage checks, users can write Argus ACL strategy contracts to set the minimum acceptable slippage for exchange transactions. Once set, the ACL strategy contract can analyze different swap transactions based on the defined slippage, and if the exchange slippage does not meet the criteria, it can intercept the transaction.

Conclusion

There are many risks in DeFi interactions that are difficult to prevent. Although the content mentioned in this article covers many common scenarios, it cannot completely cover all risk points. Users need to handle each transaction carefully.

Cobo Argus can provide users with reliable and easily configurable means to prevent common security risks. Through ACL, flexible and secure authorization management can be achieved, improving operational efficiency while ensuring security; custom bots can reduce manual operations, and the real-time monitoring capability can ensure the security of user funds 24/7.

While DeFi can certainly bring considerable returns to users, the security of funds is the core of steady asset growth. Cobo Argus will protect every DeFi farmer and help everyone create more value in the bull market.