Redacted Cartel Custom Approval Logic Bugfix Review
Summary
Whitehat Tommaso Pifferi submitted a vulnerability in Redacted Cartel via Immunefi on January 11. The vulnerability was rated as critical because it would have allowed a malicious attacker to assign a user’s allowance to themselves, enabling the attacker to steal that user’s funds. Funds at risk were just under $6 million dollars. Redacted patched the bug and paid the whitehat $560,000 for his find.
The ERC-20 token standard is the most adopted standard in the Ethereum ecosystem. Many Ethereum users already know what an ERC-20 token does and what functions it has.
The purpose of ERC-20’s approve(spender, amount) function is to allow any address to spend the tokens on behalf of the tokens’ owner. For example, Alice approves Bob to spend 20 of Alice’s tokens from her wallet. Bob’s allowance is 20 tokens, and he transfers tokens through the transferFrom(sender, recipient, amount) function, which does exactly what the name suggests.
OpenZeppelin created a framework for widely used standards like ERC-20 or ERC-721. The framework contains battle-tested implementations, so that developers won’t need to re-implement various EIPs.
The vulnerability here consisted of a faulty implementation of standard ERC-20 functions in REDACTED’s wxBTRFLY token, which is a wrapped version of the xBTRFLY. It was also inside the transferFrom function, but the issue was different. It allowed an attacker to take somebody else’s allowance and assign it to the attacker so she could steal funds from the user.
Vulnerability Analysis
The issue lies in the highlighted section of code.
The _approve takes as its arguments the following parameters:
- address owner,
- address spender,
- uint256 amount
This function first sends the tokens from the sender’s account to the recipient’s account (the first line of the code). Next, it decreases the allowance/approval to account for the tokens that we just moved. And here, we can see where the issue lies.
Instead of reading and writing the allowance/approval from the sender to the operator (msg.sender), the function reads the allowance/approval from the sender to the recipient and writes the sender to the operator (msg.sender)! This means that whenever calling the transferFrom at the end, we get the recipient’s approval minus the amount sent. This could be exploited in such a way that a hacker could steal money from the users and send them to our address!
A step-by-step guide to the attack:
- Alice has 1000 wxBTRFLY and approves her contract to spend 1000 wxBTRFLY on her behalf
- Bob calls
wxBTRFLY.transferFrom(Alice, aliceContract, 0). This way, no transfer happens, but due to the allowance bug, Bob gets an allowance for Alice’s money equal to 1000 wxBTRFLY - Bob calls
wxBTRFLY.transferFrom(Alice, bob, 1000)and steals all the funds from Alice
Vulnerability Fix
The new token version removed the FrozenToken contract which contained the vulnerable transferFrom function. Now, the wxBTRFLY relies on the ERC-20 implementation from OpenZeppelin.
Acknowledgments
We want to congratulate whitehat Tommaso Pifferi for his critical find. This issue was reported responsibly and securely via the Immunefi platform, leading to a happy outcome for everyone, especially the users.
If you’d like to start bug hunting, we got you. Check out the Web3 Security Library, and start earning rewards on Immunefi — the leading bug bounty platform for web3 with the world’s biggest payouts.
