Same Mistake Twice? Decoding LiFi Protocol’s $9.7M Exploit

• The LiFi team deployed the GasZipFacet contract five days prior to the attack to enable gas refueling for bridging transactions.
• The attacker exploited an arbitrary call vulnerability via depositToGasZipERC20() in the GasZipFacet contract, allowing unauthorized transactions.
• Users with infinite approvals for specific LiFi contract addresses were targeted, enabling the attacker to perform unauthorized transferFrom operations.
• The attacker crafted arbitrary transaction calls to execute unauthorized transfers instead of legitimate asset swaps. This drained significant amounts of USDT, USDC, and DAI from the users who had given infinite approval to LiFi Diamond contract.
• Stolen funds were converted into approximately 2,857 ETH using platforms like Uniswap and Hop Protocol, then dispersed across multiple wallets.
• Tornado Cash was used to obscure the origins of the stolen funds, making it challenging to trace their final destination.
• Exploited Tokens: The primary tokens the attacker got away with include:
  • 6,335,889 USDT
  • 3,191,914 USDC
  • 169,533 DAI
• Attacker’s Address: 0x8b3cb6bf982798fba233bca56749e22eec42dcf3
• Vulnerable Contract: 0x1231deb6f5749ef6ce6943a275a1d3e7486f4eae (LiFi Diamond)
• Example attack transaction hashes: 0xd82fe84e63b1aa52e1ce540582ee0895ba4a71ec5e7a632a3faa1aff3e763873, 0x65a92b189e4ae0b8a8a02cd59c5e9f6832586bd5167d41a24eb4f4d2ac692755

1. Infinite Approval Vulnerability

The exploit targeted users who had set infinite approvals for specific LiFi contract addresses. These approvals allowed the attacker to perform unauthorized transactions.

2. Deployment of GasZipFacet Contract

Five days before the attack, the LiFi team deployed the GasZipFacet contract to enable gas refueling for bridging transactions. This contract was designed to accept and swap a limited set of assets into supported ones (typically ETH).

3. Arbitrary Call Vulnerability

The root cause is the possibility of an arbitrary call with user-controlled data via depositToGasZipERC20() in GasZipFacet. The critical flaw was in the transaction call mechanism within the GasZipFacet contract. This transaction call, intended for asset swapping, was not validated and could be arbitrary. This allowed the attacker to craft a transaction call that executed a transferFrom instead of a swap, effectively draining user balances.

4. Execution of the Exploit

1. Exploit Details: The attacker exploited this vulnerability by submitting a transaction call that moved funds from users who had given infinite approval to the vulnerable contract. The attacker repeatedly executed these calls, draining significant amounts of USDT, USDC, and DAI.
2. Transaction Address: The exploit transactions were performed using the attacker’s address.

3. Affected Contract Addresses:

   • 0x1231deb6f5749ef6ce6943a275a1d3e7486f4eae (LiFi Diamond)

   Contract addresses in high risk:

   • 0x341e94069f53234fE6DabeF707aD424830525715
   • 0xDE1E598b81620773454588B85D6b5D4eEC32573e
   • 0x24ca98fB6972F5eE05f0dB00595c7f68D9FaFd68

    

5. Converting Stolen Funds

The stolen assets, totaling around $9.7 million, were converted into approximately 2,857 ETH and distributed across multiple wallets. Specific amounts of the assets stolen include:

• 6,335,889 USDT
• 3,191,914 USDC
• 169,533 DAI

The root cause of the exploit was the arbitrary call vulnerability within the GasZipFacet contract. This vulnerability enabled the attacker to execute unauthorized transferFrom operations by manipulating transaction calls.

Specifically, the flaw allowed for arbitrary calls with user-controlled data through the depositToGasZipERC20() function in GasZipFacet. This function, designed for asset swapping, lacked proper validation and restrictions, permitting the attacker to craft malicious transaction calls. The swap function didn’t check call target and call data.

As a result, the attacker was able to invoke transferFrom actions, leading to the token loss of users who gave infinite approval to (LiFi Diamond) Contract.

Moreover, the Lifi protocol uses a diamondProxy pattern, which allows for switching the implementation contract based on the function selector, played a role in the exploit.

1. Initial Setup

• Initial Funding through Tornado Cash: The attacker received 0.95646735 ETH from Tornado Cash at address 0x7e6c0ec5a67e0ed34615b0b625c60c0e23f79c86.

   

2. Conversion and Exploitation

• Exploiting LiFi Protocol:
  • Initial Funds Received: 74,336.536952 USDT and 63,406.940384 USDC
  • Address: 0x8b3cb6bf98279bfba233bca56749e22ec42dcf3 (LiFi Exploiter 2)

• Conversion to ETH:

  • 473,568 USDT converted to 36.478 ETH
  • 683,242 USDT converted to 48.242 ETH
  • 767,884 USDC converted to ETH via 0xcb7c341dc6172b642dcfa14a015b70a27e5831be
  • 472,541 USDC converted to ETH via 0x6a6d7fc48f5dc6e6f7d4a8b8b18e1eac3e1664e
  • 4,156,307.62 USDT & 1,947,597 USDC converted to 1767.88 ETH via 0x74de5d4fcbf63e00296fd95d33236b9794016631

   

3. Distribution of Assets

1. Distribution Across Multiple Wallets:
   • 209.31 ETH: 0x5367159bcbb2cda37526171a1d3439dea5dbf4e7
   • 212.31 ETH: 0xa2a6e22978a7b9d35c6f08c3fc4df5ac9bacb749
   • 204.35 ETH: 0x67807727f68ddbd0e59a89194f2d81f728551621
   • 201.89 ETH: 0xb84ca7c825c1dde18a5bebbd5f6470ef2688eec8
   • 204.36 ETH: 0xbea46c21adf801f177ded28edb37147c8f73a98c
   • 203.15 ETH: 0xb9657eedd8bf2281004fde1baf4e8c938224e986
   • 206.49 ETH: 0x8e85eace2fa757c1d97c5ebfb8b0622e5f23c5a1
   • 226.54 ETH: 0x14c1597cc833783ed8ac08ecc9b704b0a398201d
   • 242.44 ETH: 0x3a993fa6744c009b3b8d52e2edd854bd97e5b866
   • 36.48 ETH & 873,568 USDT: 0xcb7c341dc6172b642dcf4a14015be70a27e5b31e
   • 682,359 USDT & 483,242 USDC: 0x8a93360f6c9830210a4cf835fca943286221a349
   • 623,654 USDT: 0x9cc9305cB588a001CEd32bC6c9d752D3D8B279E6
   • 1 ETH & 472,542 USDT: 0x6a6df7cf485fdc6e6f7d4a8b818e1eacc31e664e

1. Both hacks exploited the ability to make arbitrary calls to the smart contracts. In the March 2022 attack, the exploit took advantage of the internal swap() function which allowed the contract to call any address with a message crafted by the attacker. This enabled the contract to execute transferFrom operations unauthorized.
2. In both cases, users who had set infinite approvals were specifically targeted. The attacker was able to drain funds because the contracts were allowed to make transactions on behalf of the users without any limit.

• The affected smart contract facet was immediately disabled to prevent further exploitation. LiFi Protocol urgently advised users to revoke all approvals for the compromised contract addresses using a dedicated revoke website: https://revoke.cash/
• The team is working with law enforcement authorities and industry security teams to trace the stolen funds and identify the attacker.
• LiFi Protocol has committed to conducting thorough security audits of all contracts and facets to identify and patch vulnerabilities. The organization plans to educate users on the risks of infinite approvals and encourage safer practices.
• Users were asked to Immediately revoke approvals for the following contracts:
• 0x1231deb6f5749ef6ce6943a275a1d3e7486f4eae
• 0x341e94069f53234fE6DabeF707aD424830525715
• 0xDE1E598b81620773454588B85D6b5D4eEC32573e
• 0x24ca98fB6972F5eE05f0dB00595c7f68D9FaFd68

An auditing firm like QuillAudits can play a crucial role in preventing such exploits through the following measures:

Comprehensive Security Audits

A thorough review of the LiFi Protocol's smart contracts to identify and fix vulnerabilities would be essential. Implementing robust validation mechanisms to ensure that transaction calls are authorized and safe could have prevented unauthorized access and mitigated the risks associated with the exploit. Before deploying the GasZipFacet contract in production, LiFi should have done a comprehensive audit of the contract. That way they could have identified the potential issue in depositToGasZipERC20() function.

Continuous Monitoring

Implementing continuous monitoring and real-time alerts for suspicious activities and potential exploits is crucial. Regular audits should be conducted periodically to ensure that new features and updates do not introduce new vulnerabilities, thereby maintaining the security and integrity of the protocol.

User Education and Best Practices

Raising awareness through educational campaigns can help users understand the risks associated with infinite approvals and encourage safer interaction methods. Additionally, providing best practice guidelines for smart contract development and user interactions can significantly minimize risk exposure and enhance overall security.