163 total views
The Furucombo incident is not within the scope of the security vulnerability. The main reason is that the official has added the inactive AaveV2 Proxy contract to its whitelist, and the AaveV2 Proxy contract has not been initialized, giving the attacker a chance. Users who have interacted with Furucombo should revoke relevant authorizations in time to avoid further losses.
Original title: “Avoid natural disasters, but man-made disasters are inevitable-Furucombo hacked analysis”
Written by: SlowMist Security Team
According to news from the chain, Furucombo, a well-known DeFi project, was hacked and lost approximately US$15 million. The SlowMist security team immediately intervened in the analysis and shared the details of the attack with everyone.
Attack details analysis
The contract in which the problem occurred this time is in Furucombo’s own agency contract. The entire attack process is very simple. By setting the logical address of Furucombo’s AaveV2 Proxy, the attacker caused all subsequent logic called through the Furucombo proxy contract to be forwarded to the attacker’s own malicious contract, resulting in the theft of any funds.
But if things are that simple, then this analysis is not worth mentioning. The problem is far more complicated than imagined.
As shown in the figure above, the attacker’s entrance is in Furucombo’s batchExec function. 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 the 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. But looking back at the call data of the attacker above, it is not difficult to find that in the call data of the attacker, the data of configs is a 0 address:
There is a trick here. Since address 0 is an EOA address, all function calls to the EOA address 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. Directly see the final core _exec function:
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 officially designated 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 to 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 call address has also been whitelisted. 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 at the beginning, it checks whether _implementation is a 0 address. If it is a 0 address, an error is thrown. The purpose of this check is actually to check whether _implementation is set. If it is set, it cannot be set again. According to this setting, it is not difficult to think that the initialize function can only be called once. Unless AaveV2 Proxy has never set _implementation, this call will not succeed. Is it true that Furucombo has not set the corresponding _implementation? With this question, we checked the status changes within the transaction. as follows:
It can be seen that the storage location is changed to 0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc in the transaction, and the content written is the attacker’s own malicious contract address 0x86765dde9304bea32f65330d266155c4fa0c4f04.
The location 0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc is the storage address of the _implementation data.
In other words, the official has never set the _implementation address of the AaveV2 Proxy contract, causing the attacker to take advantage of this loophole and cause the loss of Furucombo’s assets.
to sum up
Through the analysis of the entire incident, Furucombo’s accident was not within the scope of the security vulnerability. The main reason was that the official added the inactive AaveV2 Proxy contract to its whitelist and did not initialize the AaveV2 Proxy contract. , Causing the attacker to take advantage of it.
At present, due to the attack on Furucombo, any user who has authorized tokens to the Furucombo contract (0x17e8ca1b4798b97602895f63206afcd1fc90ca5f) will face the risk of capital loss.
The SlowMist security team recommends that users who have interacted with Furucombo check whether they have authorized relevant tokens to the Furucombo contract. If authorized, the relevant authorization should be revoked in time to avoid further losses.
Disclaimer: As a blockchain information platform, the articles published on this site only represent the author’s personal views and have nothing to do with ChainNews’ position. The information, opinions, etc. in the article are for reference only, and are not intended as or regarded as actual investment advice.