Analysis of attack details
Analysis of attack details
The problematic contract this time is in the agency contract of Furucombo itself. The whole attack process is very simple. By setting the logical address of Furucombo's AaveV2 Proxy, the attacker will forward all the logic called through the Furucombo proxy contract to the attacker's own malicious contract, resulting in the theft of any funds.
But if things were that simple, this analysis wouldn't be worth mentioning. The problem is far more complicated than imagined.
As shown in the figure above, the attacker’s entry is in the batchExec function of Furucombo. Let’s analyze the batchExec function first:
The above is the specific implementation of the batchExec function of the Furucombo Proxy contract. The _preProcess and _postProcess contracts respectively do some data processing before and after the call, and do not involve specific call logic, which can be ignored here. We mainly observe the core _execs function:
Through the analysis of the execs code, it is not difficult to find that the main logic of the function is to check the data in the configs array and perform some processing on the data according to the data in the configs array. However, looking back at the attacker’s invocation data above, it is not difficult to find that in the attacker’s invocation data, the data of configs is a 0 address:
There is a trick here, since address 0 is an EOA address, all function calls to EOA addresses will succeed, but will not return any results. Combined with this trick, the part about configs data in the execs function can be temporarily ignored. See the final core _exec function directly:
The logic of the _exec function is also very simple. After verifying the _to address, the data is directly forwarded to the specified _to address. And through the analysis of the attack transaction, we can find that this _to address is indeed an official legal address.
The last step is to call the _to address, which is the initialize function of the officially designated AaveV2 Proxy contract, and set the attacker's own malicious address as the logical address of the AaveV2 Proxy contract. Through the analysis of the Furucombo contract, it can be found that there are no serious security points in the entire call process, and the whitelist check is also carried out on the address of the call. Then the problem can only be in the corresponding proxy logic to be called, that is, the AaveV2 Proxy contract.
We directly analyze the logic of the initialize function of the AaveV2 Proxy contract:
You can see that the initialize function is a public function, and it checks whether _implementation is 0 address at the beginning, and if it is 0 address, an error is thrown. The purpose of this check is actually to check whether _implementation is set, and if it is set, it cannot be set again. According to this setting, it is not difficult to figure out that the initialize function can only be called once. Unless the AaveV2 Proxy has never set _implementation, this call will not succeed. Is it true that Furucombo has not set the corresponding _implementation? With this in mind, we examine the state changes within the transaction. as follows:
It can be seen that the content stored at 0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc has been changed in the transaction, and the written content is exactly the attacker’s own malicious contract address 0x86765dde9304bea32f65330d266155c4fa0 c4f04.
And 0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc is the storage address of _implementation data.
Summarize
Summarize
suggestion
suggestion
Currently, due to the Furucombo attack, any user who has authorized tokens to the Furucombo contract (0x17e8ca1b4798b97602895f63206afcd1fc90ca5f) will be at risk of losing funds.
Reference link:
Reference link:
Attack transactions:https://approved.zone/
Attack transactions:
https://ethtx.info/mainnet/0x6a14869266a1dcf3f51b102f44b7af7d0a56f1766e5b1908ac80a6a23dbaf449
