At 4:34:42 AM on May 9, 2022, Beijing time, the CertiK security technology team detected that Fortress Loans was attacked by oracle manipulation.
At 10:05 am on May 9th, Beijing time, JetFuel Finance also officially confirmed the news about oracle manipulation, and released links to suspicious addresses and transactions:
At present, the project has lost about 1,048.1 ETH and 400,000 DAI (a total value of about 2.98 million US dollars ). The attacker steals ETH and DAI through DAO and oracle manipulation to complete the attack. After obtaining the stolen tokens, it quickly exchanged all the tokens for ETH, and transferred ETH out through Tornado Cash.
Vulnerability transaction
https://bscscan.com/tx/0x13d19809b19ac512da6d110764caee75e2157ea62cb70937c8d9471afcb061bf
https://bscscan.com/tx/0x851a65865ec89e64f0000ab973a92c3313ea09e80eb4b4660195a14d254cd425
relevant address
Attack address: https://bscscan.com/address/0xA6AF2872176320015f8ddB2ba013B38Cb35d22Ad
Attacker contract (most likely self-destructed):
https://bscscan.com/address/0xcd337b920678cf35143322ab31ab8977c3463a45
Fortress Loans oracle:
https://bscscan.com/address/0x00fcf33bfa9e3ff791b2b819ab2446861a318285#code
Chain contract: https://bscscan.com/address/0xc11b687cd6061a6516e23769e4657b6efa25d
attack steps
The attacker created and funded an EOA (0x0db3b68c482b04c49cd64728ad5d6d9a7b8e43e6) with a proposal ID of 11 to the Fortress Governor Alpha contract (0xe79ecdb7fedd413e697f083982bac29e93d86b2e).
Proposal11: https://bscscan.com/tx/0x12bea43496f35e7d92fb91bf2807b1c95fcc6fedb062d66678c0b5cfe07cc002#eventlog
Another attacker-controlled EOA (0x0db3b68c482b04c49cd64728ad5d6d9a7b8e43e6) was subsequently voted for this proposal: https://bscscan.com/tx/0x83a4f8f52b8f9e6ff1dd76546a772475824d9aa5b953808dbc34d 1f39250f29d #eventlog
Proposal 11 is thus implemented, increasing the FTS token collateral to 70000000000000, which allows the attacker to exploit it for profit in the following steps.
Subsequently, the attacker provided 100 FTS as collateral by attacking the contract https://bscscan.com/address/0xcd337b920678cf35143322ab31ab8977c3463a45, and borrowed a huge amount of other tokens in return. https://bscscan.com/tx/0x13d19809b19ac512da6d110764caee75e2157ea62cb70937c8d9471afcb061bf
The attacker also manipulates the oracle by calling the "submit()" function in the chained smart contract, where "requiredSignatures" can be bypassed and power checks are disabled in deployments.
Eventually part of the profit is transferred to the attacker's address, and the rest of the profit is transferred outside the attacking contract.
Contract Vulnerability Analysis
Vulnerability ①
The first vulnerability is a design flaw in the governance contract.
Governance contracts can execute successful proposals to modify lending-related configurations (i.e., add a collateral and its corresponding collateral coefficient). However, the minimum FTS tokens required to vote is 400,000 for a proposal to be successfully executed. Due to the low price of FTS tokens, the attackers exchanged approximately 11 ETH for over 400,000 FTS tokens.
With these FTS tokens, an attacker can create a malicious proposal at will and execute it successfully.
Vulnerability②
The second vulnerability is that the "commit" function of the chain contract has a flaw - allowing anyone to update the price.
Necessary statements in L142 are commented out. Therefore, there is no validation to ensure that the function call is fired correctly.
Whereabouts of assets
780,000 + 2.28 million USDT were transferred to the attacker's address after two attack transactions.
2.3 million USDT was sent to Ethereum to anySwap(Multichain).
770,000 USDT was sent to Ethereum through cBridge (Celer Network).
All USDT is converted into ETH and DAI through Unswap and sent to Tornado Cash.
timeline
At around 00:30 on May 9, Beijing time, the token price of Fortress (FTS) plummeted. Soon the project team stated in telegram: There are some problems with the project, which are currently under investigation.
But the attack may have started earlier than we thought.
The first time the attackers started "testing" was at 1:41:59 AM on April 20th, Beijing time, when they deployed an unverified custom contract. In the weeks following the "stomp," the attackers continued to interact with Fortress through a series of transactions and deploy unverified contracts, a behavior that did not subside until the first few days of the attack.
After the attacker deployed the contract, they then initiated a series of transactions — allowing them to create and fund an externally owned address, make malicious proposals to the Fortress Governor Alpha contract and vote themselves — as the attacker previously manipulated the price, So they can easily buy enough FTS (the necessary votes of 400,000), then set the collateral of the FTS token so high that the value of the FTS increases, use it to borrow a large number of other tokens, and then exchange it for ETH and DAI.
In addition, there is a " self-destruct " function in the contract deployed by the attacker, which will be triggered once all malicious transactions are completed.
Currently funds are transferred to the Ethereum chain after passing through the cBridge (Celer Network) bridge and the Multichain exchange bridge, and are sent to Tornado Cash in a series of subsequent transactions.
write at the end
This attack should have been effectively avoided through security audits.
For vulnerability ①, since the price of governance tokens and how many tokens are in circulation are unknown, it is not easy to discover this risk, but it is possible to warn of potential related attacks through certain risk discovery.
For the vulnerability ②, the audit can find the lack of key verification, preventing anyone from manipulating the price by submitting the function.
The attack caused by the oracle machine manipulation is not the only example. A few days ago, CertiK released the [Just manipulate the oracle machine to be an empty-handed wolf? Analysis of the $15.7 million attack on DEUS Finance DAO] The stolen funds are even larger.
There are endless security risks in the encryption field. The project team should be as vigilant as possible and always pay attention to security incidents for self-examination, and improve and audit the contract code in a timely manner.