Drainage d'approvals via facette LI.FI

Le 16 juillet 2024, le protocole de liquidité cross-chain LI.FI a été exploité pour environ 11,6 millions de dollars. Le bug était une vérification de validation unique manquante dans une facette fraîchement déployée du contrat diamond-proxy de LI.FI — une vérification que le deployer avait simplement oublié d'inclure.

Ce qui s'est passé

Les smart contracts de LI.FI utilisent le pattern diamond proxy : une adresse de contrat unique face à l'utilisateur route vers un ensemble de contrats d'implémentation enfichables (« facettes ») qui gèrent une fonctionnalité spécifique (bridging, swapping, collecte de frais, etc.). Les utilisateurs qui interagissent avec LI.FI accordent des approvals de tokens au diamond proxy, souvent avec des allowances infinies — un pattern UX DeFi courant.

La librairie LibSwap de LI.FI, utilisée par de nombreuses facettes, permet au protocole de faire des appels arbitraires à n'importe quel contrat pendant un swap — nécessaire pour le routage via des DEX inconnus, des collecteurs de frais et des ponts. La librairie est intentionnellement permissive ; la sécurité dépend des facettes qui l'appellent validant les cibles de swap et les calldata avant d'invoquer la librairie.

Une nouvelle facette livrée le 16 juillet n'incluait pas cette validation. N'importe quel appelant pouvait :

1. Identifier un wallet avec une approval infinie au diamond LI.FI.
2. Construire un « swap » dont le calldata sous-jacent invoquait transferFrom() sur l'allowance de la victime.
3. Soumettre le swap ; la facette de LI.FI appelait LibSwap ; LibSwap dispatchait l'appel arbitraire ; les tokens de la victime étaient transférés à l'attaquant.

L'attaquant a balayé 11,6 M$ en ETH, USDC, USDT et DAI des wallets ayant déjà accordé des approvals infinies à LI.FI. Le nombre de wallets affectés était petit (l'équipe a estimé « un très petit nombre d'utilisateurs »), mais ces utilisateurs avaient de gros soldes.

Conséquences

• LI.FI a mis en pause le diamond dans les heures suivant la première transaction malveillante et ajouté des avertissements on-chain sur les adresses affectées.
• L'équipe a publié un post-mortem détaillé et s'est engagée au remboursement total des utilisateurs affectés avec backing d'investisseurs.
• L'exploit était le second incident de sécurité LI.FI — un bug plus petit en 2022 avait coûté ~600 000 $ via un pattern connexe de gestion d'approvals.

Pourquoi c'est important

LI.FI est un cas fort pour deux leçons liées :

1. Les approvals infinies sont une confiance infinie : tout contrat auquel un utilisateur a déjà accordé une approval illimitée peut drainer ses tokens pour toujours, y compris via des bugs introduits dans du code futur qui n'existait pas au moment de l'approval. L'UX revoke — Revoke.cash et al. — est une réponse partielle ; la meilleure réponse est les approvals bornées avec expiration, que la plupart des wallets offrent désormais par défaut pour le pattern EIP-2612 permit.
2. Les primitives permissives requièrent une défense en profondeur : quand une librairie est conçue pour permettre des appels arbitraires, chaque appelant de cette librairie est responsable de valider ses entrées. Un déploiement de facette oublieux a cassé tout le modèle de confiance de LI.FI.