How W3A Helps Detect Malicious Token Burning Logic
Learn how to recognize the emerging risk of hidden code modifications that enable unapproved NFT burning.
There hardly is someone who isn’t aware of how crucial it is to safeguard your assets as you enter the web3 market. You never know — scams, phishing, and all kinds of fraud can be lurking behind so many deals. Besides, scammers are becoming smarter, carefully camouflaging the risks and wrapping them into multiple layers, from web apps to social networks to smart contracts.
Many scammers prefer to target their attacks at inexperienced users who are new to blockchain technology. However, no matter how advanced you are in the field, you aren’t 100% immune from getting trapped in a malicious scheme. You may even be able to check smart contract code to figure out the ins and outs of its algorithms… and still not have a safety guarantee.
That is precisely why the Web3 Antivirus team has designed a brand-new technique aimed at smart contract simulation and audit. By polishing the feature non-stop, our engineering squad enables the tech to detect many kinds of multi-vector attacks that often go unnoticed by conventional checks.
Uncover malicious logic behind smart contracts
Take, say, contract owners’ privileges — W3A checks them as well. Why? What makes them so dangerous? Well, smart contracts often include methods that are exclusively available to owners, not regular users. These could involve token minting, metadata operations, and the like. But normally, as you know, none of these actions inherently jeopardize your assets.
The thing is, a malicious actor can inject ill-intended logic somewhere within the code, so by executing the modified logic users unintentionally approve more privileges on the contract owner’s side. And just like that, the owner will have the freedom to transfer or burn users’ tokens with no permission. In other words, your funds can disappear at any moment.
Learn about token burning in the first place
Now, let’s take a step back to refresh our knowledge about token burning. In a nutshell, it is the process of removing tokens from circulation by calling a specific method. These tokens can be either specific assets or, say, a definite number of ERC20s. Again, naturally, it’s just the owner who can burn them.
Imagine your wallet holds three NFTs that you can freely transfer, grant access to, or burn at any time. This means you are the only person who has control over your token balance. If you burn one NFT, you know you still have two left. No one else can manipulate your assets unless you give them access. And this is what we’ll focus on specifically.
Rule out hidden token burning risks
This brings us back to W3A and the real-life cases it helps with. Why do we pay so much attention to burning risks? As mentioned, we’ve recently implemented a brand-new analysis technique. During a test drive, the team discovered an NFT contract that allowed its owner to transfer and burn tokens without users’ knowledge.
At first, the fact that our analyzer reacted to the contract puzzled us, as manual code checks failed to identify any abnormalities. Yet, a detailed audit enabled us to uncover hidden pieces of code.
What you see above is the burn method, where the underlined piece verifies whether the person attempting to burn a token is its rightful owner or has the owner’s approval. Then follows calling the contract’s internal method (the highlighted part, again):
Basically, if zooming in, that’s exactly where the major token burning logic resides:
Sit back & watch W3A detect bad burning logic
Now, let’s shed some light on how we’ve managed to detect malicious logic. Technically, we handled this by calling the internal _isApprovedOrOwner method. Under the hood, it first checked if the token that was about to be burned even existed:
Then W3A checked if the following conditions were met:
1. The one who initiated the token burning transaction is the NFT owner:
2. The initiator has approval to burn this particular token:
3. The initiator has approval to access all the tokens owned by a specified user (in our case, that’s the one whose NFT is being burned):
Normally, in line with EIP721 specifications, calling a standard ERC721 contract method is meant to be a part of the check by default. However, in this case, the developer has modified the method. Meaning, the method enables proceeding with the check:
a) Either in case the burning transaction initiator does have approval to burn all the tokens owned by a particular person:
b) Or in case the burning transaction initiator is the contract owner:
Unsettling, right? See, if one of the three above-mentioned conditions is met, the burning mission will be successfully completed. And it’s specifically the third condition that contains the additional privilege enabling the owner to burn others’ tokens.
Avoid unwanted transfer conditions as well
Notably, the same workflow applies to asset transfer: transaction initiators get checked for approval in the first place. Remember, only the NFT owner or someone with the owner’s approval can transfer the tokens. Which leaves the exact same room for manipulations we’ve described above.
So, watch out! If a contract developer modifies the check conditions to their advantage, they gain the freedom to transfer your tokens whenever they want, without your knowledge. And this is what we’re going to discuss in our upcoming post.
Stay forearmed with Web3 Antivirus and don’t miss out on more updates!
