LI.FI Bridge Hack could have been $24.5M USD!

Recently the LI.FI bridge was upgraded and a new diamond facet was added 0xf28a352377663ca134bd27b582b1a9a4dad7e534. This facet, GasZipFacet was vulnerable to unrestricted external calls. As the LIFI bridge 0x1231deb6f5749ef6ce6943a275a1d3e7486f4eae performed a delegatecall to the GasZipFacet all approvals made to the LIFI bridge were vulnerable and could have been stolen by the attacker 0x8B3Cb6Bf982798fba233Bca56749e22EEc42DcF3. The total vulnerable value of approvals to the LIFI bridge was $24.5M USDC and approximately half of that was stolen.

LIFI on X (July 16th) and in their Incident Report (July 18th) reiterated that only accounts with "infinite approvals" were vulnerable and this was wrong. This advice might have led those who had used the LIFI interface and had finite approvals to not take action when they should have. A calculation such as TVV would have quickly informed LIFI they were in error and a much larger amount of customer funds were at risk including those that had finite approvals.

LI.FI

@lifiprotocol

Please do not interact with any LI.FI powered applications for now!

We're investigating a potential exploit. If you did not set infinite approval, you are not at risk.

Only users that have manually set infinite approvals seem to be affected.

Revoke all…

800

23:41 • 16 Jul 2024

And from LIFI's incident report (below);

The total value the attacker could have captured from the attack was much greater than just victims with infinite approvals. My assumption is LIFI made a logical error in their accounting and thought that those who had made finite approvals and bridged their funds would no longer have a balance that could be stolen by the attacker.

There were three types of victims in this attack;

1. Those with infinite approvals set to type(uint256).max or all FFs. This balance was vulnerable.

2. Those with finite approvals that at the time of the attack were greater than their balance. This balance was vulnerable.

3. Those with finite approvals that at the time of the attack were less than their balance. This approved amount was vulnerable.

On ETH L1 there were 78 victims who lost USDC, 37 of them (or 47.8%) had infinite approvals. The majority (52.2%) had finite approvals and still lost money.

For USDT there were 59 victims and the majority were infinite approvals (55.9%) and the rest were finite approvals (44.1%).Those with finite approvals still lost money.

For DAI there were 2 victims, all were finite approvals and they both lost money.

Take the example of 0x44735671ac65db3ccf8bd3f4ca041e19a5e7d100 who set finite approvals in blocks 20244286, 20258007 and 20258008 then lost $195,504.10 USDC in block 20318976. The final approval in block 20258008 was for $400,000 and the attacker took the entire balance.

If you take all approvals and check the current balance of each address (for each ERC20) you can determine the total vulnerable value (TVV);

• If the Approval > Balance the balance is vulnerable and at risk.

• If the Approval < Balance the approved amount is vulnerable and at risk.

The assumption LIFI seem to have made was that for finite approvals there should be no balance in the account (they might have bridged it) but over time this balance can return due to the fungibility of ERC20 tokens.

LIFI had significant funds at risk, significantly more than what was exploited. All of the values in the table below are for ETH L1. Arbitrum was also impacted but I've focused on ETH L1 as that's where the majority of value was stolen.

There was $24,591,851 USD of Total Vulnerable Value (TVV) in approvals made my accounts to the LIFI bridge contract and roughly half of that value was stolen by the attacker.

The TVV represents all balances accessible via approvals (24.5M USD) but there’s obviously a long tail of small balances where the effort / reward starts to reduce. The attacker might not have been interested in working that hard after already taking ~11M USD in funds. However I believe there were errors in targeting that would have added a lot more yield (200%).

For example 0x960f8bd0b4351863c659b57fe5b097969e81e105 had $1,000,000 USDC approved to the vulnerable LIFI bridge contract in block 19234368 and a balance of $2,776,941 USDC at block height 20319130 (when the attacker finished their attack) but was not impacted. Similarly 0xceb4581add9b665fdd5d73ef6983f026d8fbaf4c had $500,000 approved to the vulnerable contract in block 20006660 and a balance of $482,811 USDC at block height 20319130 and wasn’t impacted.

If the attacker had targeted just 10 more victims on USDC, USDT and DAI they would have increased their payout by $6,084,785 USD from $9,697,334 USD on ETH L1 to $15,782,119 USD. See the table below;

NB: * there may have been a second attacker or a change in tactics of the primary attacker when targeting USDC funds (see below).

This has not been documented in many write-ups. There was an additional $1.8M of USDC transferred from 0x9fc3b6191927b044ef709addd163b15c933ee205 to 0x7742Ed59E9ecF1712BC4c6bDd0c526e903a7f2C8. I've left it out of the table above as the majority of funds transfers were to the attacker 0x8B3Cb6Bf982798fba233Bca56749e22EEc42DcF3. My assumption is there was a copycat attacker that started towards the end of the primary attack and was able to work out there was a $1.8M approval sitting there and exploited it in this transaction. It could also be the same attacker that noticed they missed the $1.8M and attacked it via another account.

1. LIFI were in error stating that only accounts with infinite approvals were vulnerable attack. This blog cited multiple examples where customers did not have infinite approvals and still lost money.

2. 52.2% of victims holding USDC and almost half of USDT victims (44.1%) had finite approvals. They were told they weren't affected by the attack but they were and the lost money.

3. The Total Vulnerable Value of all approvals was $24.5M USDC and approximately half of that value was stolen.

4. There was a change in tactics or a second (copycat) attacker with $1.8M of USDC being stolen from a finite approval.