A few days ago, Numen Cyber Labs discovered that the New Free DAO project on the Binance Smart Chain (BSC) was attacked by flash loans. As a result, the price of NFD tokens dropped by 98%.
The vulnerability was found in a contract for receiving rewards. Hackers used flash loans to borrow large amounts of WBNB, exchanged them for NFD tokens, and then used an attack contract to repeatedly create multiple contracts that called the reward contract function in the NFD project, resulting in a profit of 4481 BNB, equivalent to $1.25M. The hacker left the scene, but the project and its users were left with a lot of troubles.
What is a Flash Loan?
Flash loans were first proposed by the Marble Agreement in 2018. Marble describes itself as a “smart contract bank” and offers a simple but smart DeFi innovation: risk-free loans that can be easily obtained through smart contracts.
How it works: Anyone can borrow a large amount of money from a flash loan platform without collateral, but must return the borrowed funds at the end of the transaction and pay a handling fee. If the funds cannot be returned as required, the transaction is rolled back. (This makes use of the characteristics of blockchain smart contracts).
A flash loan attack refers to the use of flash loans and other vulnerabilities to carry out arbitrage, price manipulation, and other types of attacks.
Why are Many Projects Attacked by Flash Loans?
It’s becoming increasingly common to see projects attacked by flash loans, which have become a well-known attack method. But why are so many projects falling victim to these attacks?
At its core, the flash loan platform simply provides funds to users, which shouldn’t be a problem. However, some project protocols have inherent vulnerabilities that hackers can exploit by borrowing large amounts of funds through the flash loan platform, which they then use to launch attacks and profit from them.
Projects that are commonly attacked tend to have the following characteristics:
- Price: The protocol uses the number of tokens in the trading pool on a decentralized exchange to calculate token prices.
- Quantity: There are often reward collection functions, such as mortgage and airdrop, that calculate the quantity of rewards based on the number of tokens held by an address. The more tokens held by an address, the more rewards it will receive.
How to Prevent Flash Loan Attacks?
Many people may argue that the best way to prevent flash loan attacks is to shut down all flash loan platforms, but this is not a realistic solution.
Instead, we can start by addressing the two main characteristics of flash loan attacks as described earlier. By focusing on security protection, we can reduce the risk of flash loan attacks to a certain extent.
- Price: Instead of relying on the calculation of the number of tokens in the trading pool, using multiple data sources to acquire token prices can minimize errors. Additionally, decentralized exchanges like Uniswap and PancakeSwap have a feature for weighted average price (TWAP) acquisition.
- Quantity: To prevent flash loan attacks, rewards can be calculated based on the number of tokens held by an address with additional measures such as time locks. Flash loan transactions need to be completed in one transaction, so if the address holding time is more than two blocks, flash loan attacks can be avoided.
In conclusion, while this is a simple analysis and security suggestion for flash loans, the characteristics of being attacked, and the prevention method, there are other better ways to avoid attacks. Our goal is to make each project more secure. In the case of the NFD project, we have conducted a detailed analysis.
NFD Project Attack Analysis
Attack Contract Address:
NFD Token Address:
NFD Reward Redemption Contract Address:
A. The hacker calls the addMember function in the attack contract after deploying it, adding themselves as a member.
B. The hackers borrowed 250 WBNBs from a flash loan platform, exchanged them for USDT on the transaction pool in pancakeswap, converted the USDT into 6313508 NFDs, and transferred them to a newly created contract (0x9f49375d30dd556776c14e95fb2502ac7e09a281). They then called the 0xe2f9d09c function in the contract, which included external calls. They then called the 0x6811e3b9 function in the reward contract (0x8b068e22e9a4a9bca3c321e0ec428abf32691d1e), and the reward contract transferred 525283 NFD tokens to the address 0x9f49375d30dd556776c14e95fb2502ac7e09a281.
C. The hacker then transferred all NFD tokens into the initial attack contract, 0xa35ef9fa2f5e0527cb9fbb6f9d3a24cfed948863, and continued to create new contracts, transferring all NFD tokens and calling the function of the reward contract to profit. This process went through multiple cycles of creating new contracts, as there is a conditional judgment in the NFD reward contract. The hacker had to keep creating new contracts, and the balance of the hacker’s NFDs had increased to 7407780 in the second cycle.
D. In this single transaction, the hacker gained 2952 WBNBs. This was just one of their trades, and the hackers executed similar transactions 3 times in total, making a total profit of 4481 WBNBs, equivalent to about $1.25M.
NFD Reward Contract Bytecode Analysis:
In the attack transaction flow mentioned above, we noticed that the function 0xe2f9d09c in the reward contract was called multiple times. Our analysis revealed that the reason behind this was the code in lines 168-169, where the timestamp of the caller’s address was updated in the variable stor6 after each call to this function.
Upon further examination of the code, we found that the number of rewards received, v3, is equal to the value of v5 divided by 0xf4240. The value of v5 is determined by the number of coins held by the address, divided by stor_b. This means that the more coins held by the address, the more rewards are received. As a result, the hackers were able to obtain a large number of NFD tokens through flash loans and created multiple contracts to recycle them, ultimately leaving the market with a substantial amount of rewards.
As shown in the above figure, the 1881 BNB and 556556 BUSD obtained by the hacker are currently left in the address 0x22C9736D4Fc73A8fa0EB436D2ce919F5849D6fD2. Numen Cyber Labs will continue to monitor the movement of funds. Flash loan attacks are becoming increasingly common, and Numen Cyber Labs reminds everyone that the protocol code must undergo thorough security checks and tests to ensure safe and stable operation.
Numen Cyber Labs is committed to facilitating the safe development of Web 3.0. We are dedicated to the security of the blockchain ecosystem, as well as operating systems & browser/mobile security. We regularly disseminate analyses on topics such as these, please stay tuned or visit our blog here for more!
This blog was originally published on our Medium Account.