How W3A Exposes Unapproved Token Transfer
Discover hardly noticeable manipulations behind transfer transaction methods.
In our previous post, we showcased how Web3 Antivirus reveals hidden risks of token burning by revealing modified sections of smart contract code. Today, we will dissect a similar scheme behind token transfer methods.
Shortly after red-flagging the first malicious contract, yet another dangerous one popped up while we were test-driving our new simulation technology. At a closer look, it was clear that the contract logic had been altered to allow just anyone to secretly transfer user tokens with no approval.
The fraud could remain completely unnoticed — this got us thinking of the contract’s issues further. Understanding the reason behind this anomaly was not straightforward; it required careful consideration. The thing was, the contract ran on a ready-made OpenZeppelin’s ERC721 while additionally executing custom logic.
A healthy token transfer workflow: What does it look like?
First, let’s focus on a typical NFT transfer process behind ERC721 contracts. There are several variations of transfer methods, including:
1. SafeTransferFrom method;
2. TransferFrom method;
3. Several internal methods that cannot be accessed externally.
Now, examine the conventional transfer method example:
Each transfer method follows a nearly identical initiation process, starting with a check of operation approval. This check ensures that the initiator has the necessary rights to initiate the transfer:
Again, it’s either the token owner or the approved party who can initiate the process. As we take a closer look at the _isApprovedOrOwner method used during the check, we should pay extra attention to the parameters sent there.
Normally, the method should receive two parameters:
- The wallet address of the initiator behind the transfer transaction (basically, that’s what the check is for);
2. The identifier of the token being transferred.
At first glance, no rocket science. But what if we scrutinize the problematic method where something went wrong?
The malicious method unveiled
Given that we take a quick peek at the method, the issue may remain under covers:
Yet, it’s way simpler to notice the underlying twist by setting a couple of methods against each other. This way, we can see that the problem specifically roots in the variables within the check:
In fact, the highlighted variable isn’t supposed to be there — it’s totally out of the ERC721 standard. And it’s exactly the injected value that makes the check run counter to our expectations.
One may suppose that it’s a mere coding mistake that happens from time to time. But no, it’s quite the opposite. The engineer took a pre-built ERC721 contract as a basis and intentionally modified the variable, derailing the normal method process to enable secret token transfers. Impressive, and not in a good way.
Expect more practical features any time soon!
