Cobo Security Team: Blockchain Security Trading Guide

Author: Cobo Security Team

Introduction

With the approval of Bitcoin ETFs, the blockchain market has begun to warm up. The rebound in cryptocurrency prices has gradually restored the industry's former prosperity. Meanwhile, hacker activities have also started to become more active. The Cobo Security Team has observed an increase in the frequency of phishing incidents over the past month or two.

Recently, new application hotspots such as Restaking and BTC L2 have emerged, and on-chain transactions have gradually become an indispensable part of daily life for Web3 users, with more and more user funds being transferred on-chain.

Unlike centralized applications such as exchanges, the account security of on-chain applications needs to be ensured by the users themselves. Conducting blockchain transactions securely is the most basic capability for Web3 natives. Although many infrastructures, such as browser extension wallets and even the browsers themselves, provide certain risk alerts against phishing, incidents of asset loss due to unsafe transactions still occur from time to time (e.g., private key leaks, signature phishing, etc.).

The Cobo Security Team has compiled common risk points during on-chain transactions and drafted execution guidelines for transaction security, aiming to help users avoid risks during transactions, protect their funds, and prevent phishing attacks.

Before diving into the details, the Cobo Security Team has summarized the core principles of secure transactions as follows:

1. Refuse blind signing; do not sign transactions or messages that you do not understand.

2. Be diligent and verify repeatedly.

How to Conduct Secure Transactions

A complete DApp transaction process includes multiple steps: wallet installation, accessing DApp, connecting wallet, message signing, transaction signing, post-transaction processing. Each step carries certain security risks, which will be introduced in detail below.

Note: This article mainly discusses the secure interaction process on Ethereum and various EVM-compatible chains; tools and specific technical details for other non-EVM chains may differ.

Wallet Installation

Currently, the mainstream way to interact with DApps is through browser extension wallets. The mainstream wallets used on EVM chains include Metamask and Rabby.

After extensive experience, the Cobo Security Team recommends using the Rabby extension wallet as the primary on-chain interaction wallet from a risk alert perspective. The reason is that compared to Metamask, Rabby offers features such as transaction data analysis, transaction simulation execution, transaction risk warnings, authorization queries, and historical signature data queries, providing a greater advantage in phishing prevention.

When installing a Chrome extension wallet, ensure that it is downloaded from the Chrome Web Store and not from third-party websites to avoid installing wallet software with backdoors.

Users with the means are advised to use hardware wallets in conjunction to enhance overall security in private key management.

Accessing DApp

Web phishing is a common attack method in Web3, with typical cases involving phishing DApps that lure users to visit under the guise of airdrops. After users connect their wallets, they may be induced to sign token authorizations, transfer transactions, or token authorization signatures, resulting in asset losses.

Therefore, users need to remain vigilant when accessing DApps to avoid falling into web phishing traps.

Before accessing a DApp, users should confirm the correctness of the DApp's URL. Recommendations include:

1. Avoid directly accessing the top result from Google search keywords, as phishing attackers can purchase ad placements to rank their phishing sites at the top, meaning the first result may not be the official site.

2. Avoid directly clicking on URLs posted by other users in comments or messages on x.com and various social media platforms, as these URLs are likely phishing links.

3. Confirm the correctness of the DApp URL multiple times before accessing it, cross-referencing with DApp markets like DefiLlama, official project X accounts, and Google search results.

4. Add confirmed safe websites to the browser's favorites for future access.

After opening the DApp webpage, users should also perform a security check on the address bar:

1. Check the domain name and URL. DApps typically use relatively simple domain names and URLs, such as https://app.uniswap.org/. If encountering particularly long domain names like https://zk-polyhedra.network-8jb.xyz/ or names similar to well-known sites, such as https://pufffer.fi (note the extra 'f'), it is likely a phishing site, and users should exit immediately. When identifying domain names, pay special attention to similar-looking characters like 1il, oO0, etc.

2. Check the browser's HTTPS link status. Currently, mainstream DApps use HTTPS links, and the browser should display a 🔒 symbol. If it is not an HTTPS link or the browser indicates a certificate issue, the site may not be the official one or may have been hijacked, and users should stop accessing it immediately.

Currently, mainstream browser extension wallets have integrated certain risk alert features, such as Metamask/Phantom. When accessing some risk URLs on blacklists, the browser extension wallet or even the Chrome browser itself may display strong security alerts (see the image below).

Connecting Wallet

After entering the DApp, the wallet connection operation may be triggered automatically or by actively clicking "Connect." The extension wallet will perform checks and display information related to the current DApp.

Below is the webpage review information provided by the Rabby wallet, which can assist in judging the authenticity of the DApp.

After connecting the wallet, typically, the DApp will not actively prompt the extension wallet unless the user performs other actions. If the DApp frequently prompts the wallet to sign messages or transactions after logging in, even after refusing to sign, it is likely a phishing site and should be handled with caution.

Message Signing

In extreme cases, for example, if an attacker compromises the official website of a protocol or hijacks the front end, replacing the page content, ordinary users may find it difficult to identify the security of the site in such scenarios.

At this point, the signature from the extension wallet is the user's last line of defense in safeguarding their assets. As long as malicious signatures are refused, users can protect their assets from loss. Users should carefully review the content of any message or transaction they sign and refuse blind signing.

Technically, there are three common types of signatures in Ethereum:

• Hash Signature eth_sign: Signatures for the raw hash of certain data. The raw data for the hash may be a message or even an Ethereum transaction.

• Message Signature personal_sign: Signatures for plaintext data, most commonly used during user login verification or agreement confirmation.

• Structured Data Signature eth_signTypedData (EIP-712): Signatures for data objects used in DeFi protocols, commonly seen in ERC20 Permit authorization signatures, NFT listing signatures, etc.

For risk assessment regarding message signing, users can follow these guidelines:

1. Natural language signatures can usually be allowed. These signatures are typically personal_sign, used for login confirmation or acknowledgment of product terms, consisting of lengthy natural language descriptions (rather than numerical or hexadecimal forms). Such messages are less risky since they include natural language, making them complex strings that smart contracts find difficult to process, and are generally not used for on-chain authentication, serving only to confirm address identity.

2. Directly signing hexadecimal raw hashes is prohibited. These signatures are usually ethsign signatures and are the most dangerous because users cannot determine the original data content of the hash. Therefore, most wallets have disabled the ability to sign raw hashes (hexadecimal data). In Metamask, this can be confirmed in Settings -> Advanced -> Ethsign Request tab, ensuring it is set to off. In Rabby, this configuration is disabled by default, requiring no additional setup.

3. Carefully check the content of structured data signatures. For example, in an ERC20 Permit authorization signature, check whether the spender address meets expectations; if it is an EOA address, it is likely that a phishing signature was clicked, and it should be immediately refused.

An additional note regarding message signing is that although the ethsign operation is default disabled in browser extension wallets, wallets can still sign hash-type data using personalsign. Such signatures will not result in permit authorizations or initiate transactions. However, some protocols (like certain AA wallets) may still use personal_sign signatures for authentication. To avoid losses, it is generally advisable not to sign hexadecimal data. The effect of such signatures is as follows:

Transaction Signing

Signing transactions should adhere to the principle of not blind signing. Currently, many extension wallets decode and display relevant content for messages awaiting signature. Below is an example of Rabby wallet's analysis of a DEX transaction:

Users can view relevant information about the target address of the transaction, such as whether it is an EOA address, the address balance, and the contract deployment time. Users can use this information to assess the risk of the transaction they are about to sign. For example, if the interacting address is an EOA address or if the contract deployment time is less than 7 days, it may indicate a higher risk, and users should conduct thorough investigations before proceeding.

For open-source protocols, mainstream browser extension wallets already support transaction data analysis. By viewing the ABI-decoded transaction content, users can gain a clearer understanding of what operation is being performed. The function names of contract calls can provide some reference for their functionalities, such as approve, swap, transfer, deposit, and withdraw.

Rabby and imToken wallets also integrate simulation execution features, allowing users to see the transaction execution results before confirming. Through transaction simulation execution, users can view various fund transfer scenarios that the current transaction may cause. Users should carefully check and refuse to sign for any unexpected execution results.

For users with a certain level of technical knowledge, when automated tools cannot successfully analyze transactions, they can use some common manual inspection methods:

1. Copy the interacting target contract address into a blockchain explorer like Etherscan for review. The review content mainly includes whether the contract is open-source, whether there have been a large number of recent transactions, and whether Etherscan has labeled the address as official or malicious.

2. When encountering transactions that the extension wallet cannot recognize, manually copy the first 8 digits of the raw transaction data (raw_data, displayed in hexadecimal) to https://openchain.xyz/signatures for querying, obtaining the original function name to roughly determine the transaction behavior.

3. Use transaction simulation tools like Phalcon, Tenderly, and Dedaub for simulated execution to check the specific execution details of the transaction.

Post-Transaction Processing

Surviving phishing websites and malicious signatures does not mean everything is fine; risk management is still necessary after transactions.

After a transaction, promptly check the on-chain status of the transaction to confirm whether it aligns with the expected state at the time of signing. If any anomalies are detected, take timely actions such as asset transfers or revoking authorizations to mitigate losses.

ERC20 Approval management is also very important. In some cases, users authorized tokens for certain contracts, and years later, these contracts were attacked, with attackers exploiting the token authorization limits of the compromised contracts to steal user funds.

To avoid such situations, the Cobo Security Team recommends that users follow these standards for risk prevention:

1. Minimize authorizations. When authorizing tokens, limit the authorization to the corresponding token amount based on the transaction's needs. For example, if a transaction requires authorization of 100 USDT, then the authorization amount should be limited to 100 USDT, rather than using the default unlimited authorization.

2. Timely revoke unnecessary token authorizations. Use the Approval feature in Rabby wallet or log in to revoke.cash to check the authorization status of the corresponding address, revoking authorizations for protocols that have not interacted for a long time to prevent potential vulnerabilities from being exploited to cause asset losses.

Other Tips

In addition to the risks in the transaction process mentioned above, effectively utilizing certain integrated features in some tools can also help mitigate risks.

1. Some wallets have built-in wallet import features (like Rabby). By importing addresses from other mobile wallets, users can enforce a secondary confirmation during transactions (requiring wallet wake-up, scanning, and password confirmation) to reduce phishing risks while enjoying transaction security checks from mobile wallets (whitelists, simulation execution, and phishing alerts, etc.).

2. Some wallets support importing observer wallets (like Rabby, OneKey, TokenPocket, imToken, etc.), allowing users to enter unfamiliar websites through observer wallets. The message signing or transaction initiation pages will still be prompted normally, allowing users to carefully review the content awaiting signature. Additionally, since there are no private keys, users need not worry about accidental confirmations.

3. Use the Approvals feature in Rabby wallet to check the authorization status of addresses and timely revoke high-risk authorizations. Tips: Rabby uses multiple dimensions (total amount of historical authorization links/24h revocation count/authorization time/authorized asset quantity) to assess authorization risks, which can more effectively help users identify authorization risks.

4. After mistakenly signing, promptly check the transactions and text data signed through Rabby's Signature Record feature to investigate authorization risks.

With risk awareness and sufficient preventive measures in place, effective fund isolation should also be implemented to minimize potential losses in extreme situations. The Cobo Security Team recommends the following solutions for fund storage:

1. Use Gnosis Safe multi-signature wallets or cold wallets to store large amounts of funds;

2. Use addresses generated by browser wallets or other EOA wallets to store small amounts of funds for user interactions, and regularly change hot wallet addresses.

If phishing does occur, immediate actions can be taken to minimize losses:

1. Use Revoke.cash to promptly cancel authorizations;

2. If a phishing permit message has been signed and funds have not been transferred, immediately sign a new message and initiate a permit call to invalidate the nonce of the phishing message;

3. Transfer account funds if necessary.

How to Securely Claim Airdrops

Distributing airdrops is a common method for project teams to attract users, but it is also a hotspot for phishing attacks. Therefore, based on the secure transaction principles mentioned above, the Cobo Security Team has compiled a set of secure interaction processes for claiming on-chain airdrops:

1. First, use the Rabby observer wallet to test the interaction process, confirming no token authorizations or token transfer transactions.

2. Do not sign Permit-type messages during the airdrop claiming process. Do not perform Approve contract calls.

3. Try to use a "secondary account" to claim airdrops.

4. Check the simulation execution results of the airdrop transaction to confirm no tokens are transferred out.

Selection of Plugin Tools

The content of blockchain security guidelines is extensive, and it may not be possible to conduct detailed checks for every interaction. So, is there a useful browser plugin to assist us in making risk judgments?

The Cobo Security Team has experienced several mainstream transaction risk check plugins on the market and organized them into a table based on "Phishing Website Interception," "Malicious Authorization Address Check," and "Open Source Status" dimensions, allowing everyone to choose based on their own situation, as follows: