This article is jointly published by X-explore and WuBlockchain.

Abstract:

The address poisoning attack on $0 USD transfers is savage in recent weeks. As of December 2, more than 340K addresses have been poisoned on the chain, totaling 99 victim addresses and more than 1.64M USD stolen.

In this article, X-explore provides a comprehensive analysis of the attack landscape, traces the attackers on-chain, and also provides an in-depth analysis of how the attack is implemented.

We would like to appeal to wallet apps to step up risk alerts and ordinary users to be aware of such attacks when transferring tokens.

1. Background

Recently, our on-chain risk monitoring found that $0 USD transfers occur frequently on ETH and BSC chains. We took the following BSC chain transaction data as an example to illurstrate how is this going. After VICTIM A sends a normal transaction to send 452 BSC-USD to USER B, USER B will immediately receive 0 BSC-USD from ATTACKER C. At the same time, within the same transaction hash, USER A himself will uncontrollably transfer 0 BSC-USD to ATTACKER C (realizing a "back and forth" 0 BSC-USD transfer operation)

Many users in the social media community are unaware of this and fear that their wallet private keys have been compromised, and attackers are stealing assets.

2. Attack Intention

In fact, users who encounter this situation do not need to be nervous, everyone's assets are safe, the private key is not leaked, you just need to carefully confirm the address and not transfer the wrong address is fine. The hacker's methods are very simple:

1. The hacker monitors the transfer information of several stablecoins on the chain and captures the transfer information that victim address A normally sends to user B.

2. The hacker carefully constructs a hacker address C with the same first and last digits as user address B, so that victim A and hacker address C transfer 0U to each other. (Here the attacker can use the pretty number generation tool Profanity to generate an address with the same first and last 7 digits as the user address in a few seconds)

3. The next time Victim A carelessly copies the address of the historical transaction, it is easy to copy it to the address C prepared by the hacker by mistake, thus transferring the funds to the wrong account

We consider this attack to be an on-chain address poisoning attack:

1. First, the hacker makes his address appear in the user's transaction history, luring the user into mistaking it for a trusted interaction address.

2. In addition, the hacker constructs an address that has the same first and last digits as the user's trusted address and is used by the user for the next transaction.

Users are vulnerable to capital loss under double poisoning, and all on-chain users need to be on guard together!

3. Attack Trend

As of December 2, the number of attacks on the BSC and ETH chains exceeded 290,000 and 40,000, respectively, and the number of independent addresses affected by the attacks exceeded 150,000 and 36,000, respectively.

In terms of trends, the BSC chain has been exploding since Nov. 22, while the ETH chain has been exploding since Nov. 27, with the scale of attacks on both chains intensifying.

In addition, it can be seen that there is a significant regularity in the timing of the attacks, with a significant decrease in the volume of attacks between 17:00 UTC and 0:00 UTC each day. The suspected attackers are in the Asian time zone.

As of December 2, a total of 94 unique addresses have been scammed, with a cumulative total of 1,640,000 USD, and with the increase in attackers' targets, it is expected that a large number of users will continue to be scammed in the near future.

In addition, we analyzed the attacker's cost of attack and the total cost is currently close to 25,000 USD (46 BNB + 9 ETH), with the attacker having a strong preference for BSC-USD and USDT, related to the coin circulation and user holdings of the stablecoin.

4. Attacker Traceability

We trace one of the attackers, associated with two major centralized exchanges, the complete process is shown in the figure below.

1. The source address of its attack funds is associated with OKX.com, and the attacker transfers the original attack funds from the TRON chain to the BSC chain by using the Transit.Finance cross-chain bridge.

2. The stolen funds are eventually attributed to Huobi.com, and the attacker is still using the Transit.Finance cross-chain bridge to transfer the stolen funds to the TRON chain.

Let us expand further and trace the flow of the stolen funds to the source.

First, the victim address 0xe17c2b2b40574d229a251fe3776e6da2cc46aa5e transfers a total of 1300U to the attacker address 0x720c1cfe1bfc38b3b21c20961262ad1e095a6867 in two installments.

Next, the attacker address deposit the funds to address 0x89e692c1b31e7f03b7b9cbb1c7ab7872ddeadd49

The attacker performed a cross-chain transfer of funds at address 0x89e692c1b31e7f03b7b9cbb1c7ab7872ddeadd49, in a txhash of 0 x72905bd839f682f795946d285500143ee7606e9690df2ad32968e878ad290d9f in the transaction as shown below, passing 10561 USDT through the contract of Transit.Finance (0 xb45a2dda996c32e93b8c47098e90ed0e7ab18e39) was Crossed. In the Event Logs of this transaction, you can see that the funds went to the USDT of the TRON chain. The corresponding address is TLUKBw37BVWDZdhbGco2ZEfdMd5Cit8TMD, corresponding to the transaction hash on the TRON chain is: 716507136ad28717ffd5f2f437af753ff96d344d2bcbe83f24d801db49f5a884

Eventually, the attacker topped up the TLUKBw37BVWDZdhbGco2ZEfdMd5Cit8TMD address into the Huobi exchange. The deposit addresses for the top-ups are: TPtzsrCAG61QMwig3jZV8Px7Rd1WZVnRXG, TDp7r3S1hJeiNfH1CvCVXeY8notY47nagJ

5. Analysis of the Principle of the Attack

Attacker Case 1:

EOA: 0xBAA1451bE8C33998CD43F375c2e67E79c1a104AD

CA: 0x7ceBeb6035B231A73CB5Fb4119c2FbBC04Ec6fD1

Attacker Case 2:

EOA: 0x616384a80f32aDb65243522971aE2ba7664B62E3

CA: 0x6f00Ed594A6AceEf0E1A6FE023Ecd5Eb96c8665a

The token attacks on the bsc chain mainly include BSC-USD, BUSD, USDC, ETH, etc. Most of them are through the batch call of transferFrom() function by the attack contract, but there are also cases of manual call of transfer() function and the case for the main coin. The principle is basically the same. The following is an example of an attack contract with BSC-USD.

transferFrom()

In a transaction where the attacker calls the attack contract, the attack contract only calls the transferFrom() function of BSC-USD, and by filling the parameters with sender, recipient, and amount, it can manipulate the 0 USD transfer between any addresses, and at the same time generate the events of AuthorizeApproval() and TransferTransfer().

The source code of the BSC-USD contract shows that the transferFrom() function calls the _transfer() and _approve() functions in sequence.

The _transfer() function has a simple function. First, it excludes all-zero addresses from the transaction, then it subtracts money for the sender and adds money for the receiver, and finally it records the transfer event. The add and subtract functions used here add()/sub() are OpenZeppelin's safemath library, and overflow will report an error revert.

The _approve() function also excludes the full zero address and modifies the authorization value. The focus of this function is in the parameter calculation of the transferFrom call to approve, which uses_allowances[sender][_msgSender()].sub(amount, "BEP20: transfer amount exceeds allowance") , to subtract the number of existing authorization tokens from the transfer The remaining authorization amount is put into approve and re-authorized. The subtraction function sub() used here is OpenZeppelin's safemath library, and overflow will report an error revert; however, if the parameter amount of the whole process is zero, no detection mechanism can reject the transaction, which also leads to a large number of $0 transfers on the chain that can be sent normally, and the hacker only needs to pay a fee to reap a significant return.

transfer()

Call transfer () function of the attack in the same way as the principle, the whole process only adds or subtracts the overflow detection, there is no filtering of the zero transfer.

BNB

In the process of token attack tracing, we also found the first and last identical phishing attack through 0 BNB transfer, the principle is similar to token phishing, constructing the first and last identical address for phishing.

Attack Transactions: https://bscscan.com/tx/0x5ae6a7b8e3ee1f342153c1992ef9170788e024c4142941590857d773c63ceeb3

After constructing the address is very confusing, accidentally transferred to the wrong hacker address

Normal user address: 0x69cb60065ddd0197e0837fac61f8de8e186c2a73

Hacker construction address: 0x69c22da7a26a322ace4098cba637b39fa0a42a73

6. X-explore attack detection

X-explore currently provides the real-time on-chain monitoring for such attacks. In order to avoid further harm, we recommend that:

1. The Wallet App helps users distinguish addresses through color or other prompts, and does a good job of alerting users.

2. Users should carefully distinguish and double check historical transaction addresses when transferring funds, preferably by keeping an address book on their own.

In the meantime, we developed and revealed this address poisoning attack on data basis as the reference, which are supported by Dune.

dune dashboard: https://dune.com/opang/first-and-last-address-construction

For more, please follow x-explore.
Mirror: https://mirror.xyz/x-explore.eth
Twitter: https://twitter.com/x_explore_eth