SlowMist: Fortress Protocol Hack Analysis
On the morning of May 9th, Fortress Protocol had its fund stolen due to a malicious attack. The root cause of the attack on Fortress Protocol was due to the design flaw of its governance contract and the arbitrary manipulation of the Umbrella Network Oracle.
Fortress Protocol is a DeFi lending protocol that operates on the Binance Smart Chain. The address involved in this attack are listed below:
FTS Token Contract Address:
It was determined that the attackers began to prepare as early as 19 days before executing the official attack.
On April 29th, the attacker obtained 20 ETIH on Ethereum Network through TornadoCash and bridged 12.4 ETH to the Binance Smart Chain using cBridge.
$FTS is Fortress Protocol’s governance token and was issued on April 21st, 2022 with a total supply of 10,000,000.
Due to the low price of $FTS, the attacker only spent about 11.4 ETH to purchase approximately 400,000 FTS tokens, 4% of the total supply.
On May 4th the attacker created a malicious proposal contract:
The proposal contract was then added to the proposal queue, Proposition 11.
The proposal had a three-day voting period, where the attackers voted in favor of the proposal utilizing some of their previously purchased 400,000 FTS token hours prior to the vote ending on May 7th.
As shown in the figure below, the governance contract requires two conditions be met for the proposal to pass successfully:
- The number of positives votes is greater than the number of negative votes
- The number of positive votes is greater than or equal to 4% of the total FTS token supply, which is 400,000 FTS.
After voting has ended, the proposal gets approved with a two-day waiting period prior to its implementation.
On May 9th, 2-days later, the user created the attack contract and initiated the official attack.
The attack contract executes the malicious proposal as follows:
Modify the leverage rate of FTS tokens from 0 to 0.7. This allows the attacker to use 70% of the value of leveraged FTS tokens to lend assets in the protocol.
Fortress Protocol receives the collateral price contract:
As demonstrated in the figure below, the price of each token is acquired through different oracles:
Among those is FTS, where the price is obtained from the Umbrella Oracle:
As shown in the figure below, we can see a vulnerability in the ‘submit multi-signature price feed’ function of the Umbrella Oracle:
As long as the number of signatures exceeds the requiredSignatures value, there is no verification of whether the signer has the right feed to the price. This allows the attacker to generate a signature with any account to feed the price.
After the attack, the Umbrella Network promptly repaired the vulnerability and updated the contract:
The new submit function now verifies signer permissions:
Back to the attack itself. The attacker was able to manipulate the oracle machine to set a very high price for FTS so he could lend all tokens such as BNB, USDC, USDT, BUSD, BTCB, ETH, LTC, XRP, ADA, DAI, DOT, and SHIB.
All these tokens were converted to around three million USDT and bridged over to the Ethereum network through Anyswap and cBridge. The USDT was then converted into ETH and DAI on the Ethereum Network and transferred to TornadoCash.
This attack exploited a flaw in the governance protocol and a vulnerability in oracle price manipulation. When developing a governance contract, it’s essential to consider the design logic of the token voting model so it can be made in a way that’s difficult to execute a malicious attack. In addition to assessing decentralized oracles, attention should also be dedicated to the compatibility of external oracles with the protocol itself.