Furucombo's $14 million loss from 'evil contract' attack


Over the last few months, the Extropy team have seen an unprecedented rise in 'evil contract' attacks. Furucombo and its customers are the latest to have fallen victim to this type of exploit.


Furucombo is a tool designed to help customers batch their transactions on multiple DeFi protocols. Users can build their transactions via its drag and drop interface to create a string of transactions and benefit from arbitrary opportunities. They can also authorise Furucombo to make infinite approval transfers.

Furucombo had been audited, however this type of attack would not have been picked up - we explain why towards the end of this article.

Over $14 million of ETH and ERC20 tokens were stolen and washed with Tornado Cash. Only the customers who authorised infinite approval transfers were affected by the attack.


Furucombo analysis

The attacker started by entering the Furucombo proxy contract. The attacker had created and deployed a fake contract and made the protocol believe that Aave v2 had a new implementation.

In comparison to previous attacks we've seen, the attacker took a different approach. Instead of draining funds from the protocol, the attacker targeted users who had given the protocol permission to infinitely transfer tokens. As a result, any interactions with those users allowed transfers-approved tokens to be sent to an arbitrary address controlled by the attacker.


Post mortem

The Furucombo proxy contract splits addresses by callers and callees. These addresses are registered in a registry contract, which checks whether the caller / callee addresses are valid. Aave v2 lending pool is registered as both a caller and a callee address.

Furucombo's proxy contract allowed anyone to change and update the implementation contract address, as long as the address provided had been whitelisted by Furucombo and the address had not been updated before. After this check is completed, a delegate call is made via the proxy admin contract, which stores the protocol's implementation address in the Furucombo proxy contract's storage location. If the implementation address had not been set, it sets the address to the address requested by the caller. In this case, Aave v2's address was registered in the registry contract, but it's implementation address had not been set.

Furucombo analysis

The attacker provided Aave v2's proxy address to pass Furucombo's whitelist check. The attacker then delegate called into Aave v2 proxy contract from Furucombo proxy and requested to change Aave's implementation address - which changed it to the attacker-owned malicious contract address. The implementation address had not been initialised before and the ability to initialise the implementation address could be called publicly, which made it possible for the attacker to change the implementation address.


Furucombo analysis

The only requirement in Aave v2 proxy was that the stored implementation address must be 0 before the address could be changed. This was to ensure that the address could only be implemented once. However, the address was 0 at this point because it had not been set by Aave v2. This oversight, coupled with the ability for anyone to change the implementation made the exploit possible.

Users who infinitely approved transfer tokens had approved Furucombo to transfer their funds to the Aave v2 address. When it believed it was interacting with Aave v2, the Furucombo proxy contract pointed to the malicious implementation address. The attacker was then able to transfer user funds from the malicious contract to a token contract.

The Furucombo team have since rectified the vulnerability and have advised users to change their permissions. They are currently working with local authorities to investigate the attack as well as several independent auditors to audit the platform this year.


Are we seeing a rise in evil contract attacks?

We recently wrote about the Pickle Finance fake jar attack and Alpha Homora attack, which are similar to the Furucombo attack.

Furucombo took responsible steps to ensure that there was a whitelist of verified smart contracts, which was checked before further interaction could be executed.

The attack seems to have fallen down to a missed opportunity for Aave to add the implementation address after it was registered as a trusted protocol, and the ability for the implementation to be changed publicly meant that it could be changed by anyone.

After the Alpha Homora attack, we provided our thoughts on fake contracts - and that in order to mitigate these risks, additional security standards may need to be developed.

There is also the issue of users giving protocols infinite approval. It is remarkably more convenient, but also a high risk option in DeFi, where we are seeing reputable protocols with robust architecture and high coding standards being subject to attacks.