0

So I created a wallet and sent it some funds then I submitted a few invalid transactions. I approved the correct address for transferring wrapped eth. After the approval my script immediately sent the a transaction to perform a swap for USDT. The transaction failed with a transferFrom error that I thought was weird because I had just approved the contract. I checked my balance and my wrapped eth was gone. I checked etherscan to try and understand where it went and I have no transactions I submitted between the approval and the attempt to swap. I looked in the ERC20 Transfers tab on etherscan and see that on the block that my transaction failed another transaction sent my WETH to another address. The weird part is that the from address of the transaction isn't mine. Can somebody please help me understand how they were able to take the tokens?

My address: 0x431604eDa80800a21C5E151Fb518b4aCAD4ffCF7

Approval Transaction: 0x4dbdd5adaac7641e08f34353da63e3be77efc1e306eb8a3486470cd4713559ea

Failed Swap Transaction: 0x6077b8e9adc393561ad80a8ed81bd11ccb29eccb281fcca8bbb8a0a3122ae9fc

Mysterious Transfer Transaction: 0x0b993f6c9d82ab7ea4193a7247d16feb3a7cc140bfc7f897841583b3a54b99e5

Samuel Wagner
  • 1
  • 1

1 Answers1

0

After doing a lot of digging into the transaction that was sent. The attacker called their own malicious smart contract to call my contract using the same method from my transaction but replacing the pair address I was intending to call with their own malicious contract’s address.

The malicious contract is set up to mirror the uniswapv3api when my Contract called theirs to swap. Their contract called mine back with callback data that listed my address as the payer for the transaction. My contract used its approval from the previous block to transfer the tokens from me to the Malicious contract. Then the malicious contract unwrapped the tokens and sent the balance to the attacker. This is higher in the transaction index than my actual transaction which fails because the funds are no longer there even though both transactions are on the same block, the one immediately after the approval. Wow…

Samuel Wagner
  • 1
  • 1
  • Your mistake was approving a contract with unverified source code. https://etherscan.io/address/0x1369e57947f3d79260c76a4f33c96db6dc78a415. The contract was obviously malicious and the attacker took advantage of your approval. You shouldn't use shady apps or approval for unverified addresses. – Ismael Feb 24 '24 at 04:22
  • @Ismael you’re right people should be cautious. They certainly took advantage of the approval. I deployed the unverified smart contract maybe 30 minutes before I did the approval. The reason I did not verify the source code was to prevent things like this.The attack was very sophisticated to actually; it looked at what method to call and which arguments to use based on my following request. They modify the request and change only a couple variables. – Samuel Wagner Feb 24 '24 at 14:36
  • Pending transaction are available to anyone, so unless you use a block builder that doesn't propagate transactions they are subject to this type of attacks. If you deployed the contract 0x1369e5 then you failed to secure it correctly, perhaps using onlyOwner or something like that would have been a mitigation. Hackers have can simulate pending transactions and attack them before they are mined. Together with flashbots they can front run unprotected contracts. – Ismael Feb 24 '24 at 18:46