Solana Phishing Scam Research Report

Original title: "Solana Phishing Scam Research Report"

Original source: Goplus

Introduction

Recently, phishing and fraud incidents in the Solana ecosystem have continued to occur frequently. With the rapid growth of the ecosystem, a large number of black and gray industries have also begun to shift their positions. They continue to attack ordinary Solana users through more advanced technical means and more covert phishing techniques. Various types of phishing scams are emerging in an endless stream. In the past six months, the GoPlus security team has discovered four major popular phishing scam scenarios through a large number of case studies: airdrop scams, phishing signatures, authority transfer, and address poisoning. This article will introduce these four forms of phishing cases and their principles respectively. At the same time, we have also received a large number of user feedback that in some mainstream wallets of Solana, the simulation failure of some phishing scam transactions has caused user losses. This article will also conduct an in-depth analysis of this technology.

Analysis of Fraud Scenarios

Airdrop Fraud

First, airdrop fraud refers to phishing websites that are posted in communities such as Twitter and Discord, disguised as airdrop activities.

Malicious Link Posting

Among them, on-chain airdrop phishing for NFTs is that phisher airdrops NFTs associated with phishing links to users, and tricks users into clicking on the links and signing malicious transactions. The figure below shows a case in which the user received an NFT that claimed to be redeemable for 1,000 ZERO tokens, and then the user clicked on the link in the NFT and signed the transaction. Later, the user found that the BONK, ZERO, USDT and other tokens in his wallet were stolen.

On-chain airdrop phishing NFT

The principle of airdrop scam is relatively simple, that is, the phishers use fake airdrop activities to lure users into the website and sign a transaction to link their wallet to the website. At this time, the website will initiate a phishing transaction containing one or more SOL/SPL Token transfer instructions to obtain the user's digital assets. There is also a difference between transferring with one instruction and multiple instructions. A relatively simple phishing, as shown in the left picture, is a transaction that only transfers one type of token. A more complex phishing, as shown in the right picture, can include many transfer instructions in one transaction.

One instruction/multiple instructions transfer

Phishing signature

The second type of fraud is phishing signature. Some experienced users will avoid airdrop phishing by observing the simulated transaction results of the wallet. However, phishermen take advantage of this and use anti-simulation and fake simulation technology to confuse users, thereby increasing the possibility of malicious transactions being signed. Specifically, through anti-simulation means such as merged transactions and malicious browser plug-ins (which will be highlighted below), the wallet software displays false profit results or even does not display simulation results, thereby inducing users to sign phishing transactions.

Authorization transfer

The third type of fraud is authority transfer. First of all, the approve operation of SPL Token on Solana does not directly lead to token transfer, but it will lead to the transfer of authority of token assets. Therefore, the phisher can trick the user into signing a phishing transaction containing approve, so that the ownership of a token account in the user's wallet is transferred to the phisher's wallet. When the ownership of the token account is transferred, as shown in the figure below, the mainstream wallet software will issue a warning prompt for the ownership transfer.

Warning of token account ownership transfer

The principle of authority transfer is that each token in Solana has a separate account Token Account. The hacker can change the owner of the token account by initiating a transaction containing the createSetAuthorityInstruction operation. Once the operation is successful, the user cannot transfer the token out even if the token is still in the wallet.

createSetAuthorityInstruction structure

Address poisoning

The fourth type of fraud is address poisoning. Its goal is to trick users into transferring money to a phishing address that is similar to an address that users interact with on a daily basis or that they recognize as safe, such as having the same prefix or suffix, and these prefixes and suffixes are also carefully designed. As shown in the figure below, you can see that the two addresses have the same prefix and suffix, except for the difference in the red circle, which confuses users to copy the forged phishing address and transfer money to it. Address poisoning is common in Ethereum and TRON chains, and has recently spread to the Solana ecosystem.

EVM address poisoning example

Address poisoning can also be subdivided into the following categories:

1) 0U/small transfer, refers to the phishers transferring 0 amount or a small amount of cryptocurrency to induce users to mistakenly copy the phishing address in the historical transaction record.

2) Transfer + airdrop mixed poisoning, refers to the phishers transferring a small amount of tokens and adding an airdrop phishing link in the transaction memo to induce users to click.

Transfer + airdrop mixed poisoning case

The third type is fake system program address poisoning. The fake system program address refers to the address generated by the attacker that is similar to the fake system program address as a phishing address, making the user mistakenly believe that the phishing address is a trusted address. This type of fraud was reported on February 3, 2024 by Scam Sniffer on Twitter. A Solana address poisoning incident, in which the attacker generated an address with the same tail number as the system program, so that the user mistakenly believed that the disguised address was a normal system program. Among them, the fake system program address can be generated by the command "solana-keygen grind --starts-with :1 --ignore-case". For example, if I want a prefix of "8888", then write the prefix into this command to get it.

Fake system Program address poisoning case

Fake system Program address generation case

Wallet simulation transaction and anti-simulation

Solana's simulated transactions provide users with a way to observe the results of transaction execution before the transaction is on the chain. The specific process of the simulated transaction operation is shown in the figure below. After constructing a transaction object and serializing it, requesting the simulateTransaction method can return the results of the simulated transaction, such as which accounts have changed balances and permissions. This function is commonly used in wallet software to assist users in checking transaction security before the transaction is confirmed.

Simulated transaction operation

However, in some cases, simulated transactions may also fail, which can be divided into two categories:

1) Anti-simulation: The transaction simulation fails due to network fluctuations or other reasons, resulting in the inability to infer the transaction execution result.

2) False simulation: The transaction simulation is successful, but the execution result obtained by the simulation is different from the effect after being uploaded to the chain.

Anti-simulation

Anti-simulation may occur in two cases:

1) Wallet implementation mechanism defects. For example, when the early Phantom wallet initiated multiple transactions, it merged the instructions in different transactions, causing the size of the simulated transaction to exceed the maximum limit.

2) Network error. The simulated transaction requests the wallet RPC service, denial of service attacks, malicious plug-in proxy requests, and long-term unresponsive requests, which lead to network errors and simulation failures.

Take the Phantom wallet as an example. When implementing simulated transactions, we intentionally create network errors. The specific code is shown in the figure below: First, connect to an RPC service through Solana's web3. Then, create dozens of transactions, each of which contains a large number of instructions. Finally, send the above transactions to the wallet. Due to possible network timeouts, the simulation results cannot be viewed.

Anti-simulation case

False simulation

There are also two possible reasons for the occurrence of false simulation:

1) Durable Nonce. This mechanism allows signing first and initiating transactions at a certain time in the future. However, please note that if a transaction triggers an upgradeable contract (the contract logic is maliciously modified), the transaction execution results simulated at the time of signing may be different from the execution results when the transaction is initiated.

2) Wallet implementation defects. For example, if the wallet simulates multiple transactions at the same time, the results may be inaccurate.

Also taking the Phantom wallet as an example, we initiate multiple identical transactions at the same time, and the simulated execution only shows the result of one of the transactions. As shown in the figure below, the logic indicated by the code sends 0.00002 SOL, but the simulation result is only 0.00001 SOL.

Mainstream Wallet Anti-Simulation and Fake Simulation Issues

Furthermore, we also explored whether other wallets have similar anti-simulation and fake simulation issues as above. Here we try to analyze two other common Solana wallets, Solflare and Backpack.

Solflare

· In the case of network timeout, the confirmation button will not be displayed, reducing the anti-simulation risk caused by network delay

· Simulate multiple transfer transactions at the same time, do not display the balance changes, and directly prompt the risk;

False simulation case

Backpack

· Similar to Solflare, the confirmation button will not be displayed in the case of network timeout, reducing the anti-simulation risk caused by network delay

· There may be potential false simulation risks. Refer to the above Phantom fake simulation code, send 0.00002 SOL, but the simulation result is 0.00003 SOL.

Summary

At present, there are still many hidden dangers to user security in the Solana ecosystem. Although mainstream wallets already have certain security features, these features have not yet been able to cover all security issues. For example, transaction simulation results are not always credible, which poses potential risks to users. Even if users take precautions, such as checking the results of simulated transactions, they may still be confused by anti-simulation and fake simulation technologies and sign malicious transactions. To meet these challenges, the GoPlus security team will launch the wallet drainer detection feature this month. This capability will empower mainstream applications in the Solana ecosystem to fully protect every transaction of users by detecting and blocking potential fraud and phishing transactions in real time. This will not only significantly improve the user's security experience, but also contribute to the stability and prosperity of the Solana ecosystem. The GoPlus security team calls on the Solana public chain and its ecological partners to jointly accelerate the construction of user security infrastructure to provide users with a safer and more reliable trading environment. Through continuous technological innovation and security protection upgrades, we believe that we can effectively reduce the occurrence of phishing scams, protect the security of users' digital assets, and achieve long-term stability and healthy development of the Solana ecosystem.

This article is from a contribution and does not represent the views of BlockBeats.