How Was NGFS Token Exploited?

TL;DR#

On April 25, 2024, FENGSHOU or the NGFS token, was exploited on the BNB chain due to a smart contract vulnerability, which resulted in a loss of assets worth approximately $191,000.  

Introduction to NGFS Token#

FENGSHOU or NGFS is a token on the BNB chain.

Vulnerability Assessment#

The root cause of the exploit is a lack of stringent access control.

Steps#

Step 1:

We attempt to analyze the attack transaction executed by the exploiter.

Step 2:

It can be seen on the vulnerable NGFSToken contract that the delegateCallReserves function was set to a public visibility specifier and lacked proper access control, allowing for an arbitrary configuration of the _uniswapV2Proxy variable.

function delegateCallReserves() public {
  require(!uniswapV2Dele, "ERC20: delegateCall launch");

  _uniswapV2Proxy = _msgSender();
  uniswapV2Dele = !uniswapV2Dele;
}

Step 3:

With this privilege in hand, the attacker was able to set the attack contract as a UniSwapV2 proxy via invoking a call to the setProxySync function. Notably, the attack was carried out roughly 1.5 hours after the deployment of the NGFS token contract.

function setProxySync(address _addr) external {
  require(_addr != ZERO, "ERC20: library to the zero address");
  require(_addr != DEAD, "ERC20: library to the dead address");
  require(msg.sender == _uniswapV2Proxy, "ERC20: uniswapPrivileges");

  _uniswapV2Library = IPancakeLibrary(_addr);
  _isExcludedFromFee[_addr] = true;
}

Step 4:

As a result, the attacker is able to manipulate the _uniswapV2Library variable to set an arbitrary high balance for their attack contract by invoking a call to the reserveMultiSync function, and then swap tokens for the underlying tokens.

function reserveMultiSync(address syncAddr, uint256 syncAmount) public {
  require(_msgSender() == address(_uniswapV2Library), "ERC20: uniswapPrivileges");
  require(syncAddr != address(0), "ERC20: multiSync address is zero");
  require(syncAmount > 0, "ERC20: multiSync amount equal to zero");
  _balances[syncAddr] = _balances[syncAddr].air(syncAmount);
  _isExcludedFromFee[syncAddr] = true;
}

Solution#

To prevent the exploit seen in the NGFS token incident, several robust security measures can be implemented to safeguard smart contracts against unauthorized access and manipulation. If the Uniswap proxy variables are intended to be set once and not modified, they should be configured in the contract's constructor and declared as immutable. This design pattern ensures that the value is written only once during contract creation and cannot be altered thereafter, providing a high level of security against unauthorized changes.

Integrating access control mechanisms is also crucial. The use of an onlyOwner modifier, or similar access control modifiers, should be applied to sensitive functions to ensure that only authorized addresses can execute them. This can be managed through OpenZeppelin's Ownable contract, which provides a robust ownership control mechanism. These modifiers ensure that only the designated owner of the contract can call critical functions, thereby preventing unauthorized users from reassigning critical components like the UniSwapV2 proxy.

Furthermore, conducting comprehensive security audits and thorough testing regimes, including both static analysis and dynamic testing, is essential to identifying vulnerabilities before deployment. Utilizing automated tools along with expert manual review will help uncover issues that might be overlooked by one approach alone. Additionally, increasing the rigor of validation checks within functions that handle critical logic is advisable.

Despite rigorous security measures, completely eliminating the risk of vulnerability exploits remains a difficult task. In such situations, partnering with us at Neptune Mutual proves invaluable. We could have significantly reduced the financial impact of such security breaches if the NGFS token team had created a dedicated cover pool with us. We offer tailored coverage against losses resulting from smart contract vulnerabilities through custom-designed parametric cover policies that target these particular risks.

Working with us streamlines the recovery process for users by reducing the need for extensive proof-of-loss documentation. Once an incident is verified and resolved through our comprehensive incident resolution protocol, our priority shifts to quickly compensating and financially supporting those impacted. This method ensures swift aid to users affected by security breaches.

Our services are available on our marketplace across several prominent blockchain platforms, such as Ethereum, Arbitrum, and the BNB chain, enhancing our ability to support a broad spectrum of DeFi users. This widespread presence greatly bolsters our capability to protect against smart contract vulnerabilities, thus strengthening the security framework for our large user base.

Reference Source ChainAegis