Exactly Protocol Hack

Loss: 7.2 million USD

Platform: Optimism

Details: Exactly is a lending protocol that supports both variable and fixed interest rates. On August 18th, 2023 it was exploited due to a missing validation check. The hacker could create their own market and pass it to a function, bypassing a critical permit check. This allowed the attacker to impersonate victims and manipulate the protocol into transferring funds.

Background: Exactly is a lending protocol that was started in July 2021, launched on Ethereum Mainnet in November 2022, and to the Optimism platform in March of 2023. The TLDR of their docs reads:

“Exactly protocol takes a new approach to interest rate discovery in DeFi. Rather than relying on the value of multiple maturity tokens, we look at the utilization rate of several maturity pools, enabling us to offer both variable and fixed rates within the same protocol.”

The protocol has undergone several audits by Coinspect, Chainsafe, and ABDK. The most recent audit previous to the hack was performed by ABDK in May of 2023. Additionally they had their economic model audited by the Center for Cryptoeconomics. Even with these comprehensive and continuous security practices Exactly neglected to get this specific code audited.

The Exploit: The vulnerability exploited in the Exactly protocol was primarily due to a missing validation check within the DebtManager contract. Essentially, the hacker was able to create their own malicious Market smart contract, deploy it, create a pool for it on Uniswap and then pass it to the leverage() function within the Exactly protocol. Creating their own Market allowed the hacker to bypass a critical permit check, a function that typically validates the authenticity of certain actions within smart contracts.

Here is the leverage() function and permit() modifier in question.

function leverage(Market market, 
                  uint256 deposit, 
                  uint256 ratio, 
                  uint256 borrowAssets, 
                  Permit calldata marketPermit
          ) external permit(market, borrowAssets, marketPermit) msgSender 
{
//….
}

modifier permit(ERC20 token, uint256 assets, Permit calldata p) {
  IERC20PermitUpgradable(address(token)).safePermit(
    paccount,     
    address(this), 
    assets, 
    p.v, 
    p.r, 
    p.s);
	{
	  //…..
	  if(_msgSender == address(0)) _msgSender = p.account;
	}
	_
}

The key vulnerability in the leverage() function was its lack of validation to ensure that the provided Market was a trusted one. An attacker exploited this by creating a malicious Market contract that would always approve the permit, regardless of the signature's validity. When the leverage() function was invoked with this fake Market, the attacker is able to set the _msgSender value to a victim's address. This effectively permitted the attacker to utilize the victim’s funds. The attacker then deposited these ill-gotten tokens into a UniV3 pool tied to the fake Market, minting LP tokens for this fake pool. Since the fake Market contract held these LP tokens, the attacker could freely withdraw them.

Exploiting the protocol further, the fake Market contract was used to initiate a re-entrancy attack on the Debt Manager contract, specifically via the crossDeleverage() function. This re-entrant call was made while the initial leverage() function was still in execution, meaning the msg.sender value remained set to the unsuspecting victim's address. This maneuver forced the Debt Manager to interact with the attacker's counterfeit Uniswap V3 pool, essentially converting and redirecting the victim's USDC tokens into this trap. Since the attacker controlled the liquidity tokens of this pool, they could freely drain these funds.

As a finishing blow, the attacker targeted the victim's health factor. While the siphoning of collateral had already reduced this factor, it was not yet at a point where the victim could be liquidated. Thus, the attacker borrowed from the exaUSDC market, nudging the victim's health factor just below the liquidation boundary. This allowed the attacker to liquidate the victim's position, seizing even more assets. This nefarious strategy was not limited to a single victim; it could be and was redeployed across different users and markets within the Exactly protocol.

Lessons Learned:

In the aftermath of the Exactly Protocol hack, the broader DeFi community is reminded of the delicate balance between innovation and security. While DeFi platforms usher in revolutionary solutions and democratize financial services, they are prone to attacks that manipulate the intricacies of their underlying code. The Exactly debacle underscores a few paramount lessons, one being that protocols should never push code to production that has not been reviewed at least once by a third party. In the dynamic world of DeFi, platforms must commit to unyielding vigilance. This means embracing consistent code reviews, rigorous stress tests, and proactive vulnerability assessments. As we tread the delicate balance between innovation and complexity, unwavering security remains the cornerstone of user trust and the enduring success of any protocol.