Double-claim referral de Level Finance

Le 1er mai 2023, le protocole de perpétuels BNB Chain Level Finance a perdu environ 1,1 million de dollars (214 000 tokens LVL) via un bug de double-claim dans son contrat LevelReferralControllerV2. La fonction de claim de récompense referral payait avant de marquer l'epoch comme claimed, permettant à un attaquant de claim les récompenses du même epoch de manière répétée en boucle.

Ce qui s'est passé

Level Finance opérait un programme referral : les utilisateurs gagnaient des récompenses en tokens LVL basées sur le volume de trading référé, réclamables par epoch. La fonction claimMultiple dans LevelReferralControllerV2 traitait ces claims.

Le bug était une violation classique de checks-effects-interactions spécifique à la comptabilité de claim :

1. La fonction de claim calculait les récompenses dues à l'utilisateur pour un epoch.
2. Transférait les tokens LVL à l'utilisateur.
3. Puis mettait à jour la comptabilité pour marquer cet epoch comme claimed.

Parce que l'étape « marquer comme claimed » se produisait après le paiement — et parce que la fonction pouvait être appelée de manière répétée dans le même contexte de transaction avant que l'état ne se stabilise — l'attaquant pouvait réclamer les récompenses du même epoch de nombreuses fois avant que le contrat n'en enregistre aucune comme claimed.

L'attaquant a bouclé le claim, extrayant 214 000 LVL (~1,1 M$) contre l'entitlement légitime d'un seul epoch, puis a dumpé le LVL dans la liquidité.

Conséquences

• Level Finance a confirmé l'exploit et identifié l'ordre de claim buggé comme seule cause racine.
• L'équipe a mis en pause le contrat referral et livré une version corrigée avec l'état de claim mis à jour avant le paiement.
• Le token LVL a pris un coup de prix du dump ; le protocole a continué à opérer avec le contrat patché.

Pourquoi c'est important

Level Finance est une instance à petits dollars mais pédagogiquement parfaite de la plus ancienne règle de la sécurité smart-contract : checks-effects-interactions — mettez à jour votre état avant de faire l'appel externe / le paiement, jamais après.

Le DAO a enseigné cela en 2016. C'est la première règle dans chaque guide de sécurité Solidity. Et pourtant cela continue à être livré — ici dans une fonction de claim de récompense plutôt qu'une fonction de retrait, ce qui est exactement pourquoi c'est passé inaperçu : les développeurs intériorisent « appliquer CEI aux retraits » mais ne reconnaissent pas toujours qu'un claim de récompense referral est structurellement un retrait et nécessite la même discipline.

Le catalogue est plein de cet échec de généralisation — la classe de bug centrale est bien connue, mais elle réapparaît à chaque fois qu'elle porte des vêtements légèrement différents :

• Réentrance dans les dépôts (Grim), pas seulement les retraits.
• Vérifications de solvabilité manquantes dans les fonctions d'urgence (Platypus), pas seulement les fonctions du chemin normal.
• CEI violé dans les claims de récompenses (Level Finance), pas seulement les transferts de tokens.

La leçon que Level Finance cristallise : une classe de vulnérabilité n'est pas « gérée » parce que les instances évidentes sont gérées. Chaque fonction qui déplace de la valeur est soumise aux mêmes règles, et les bugs se regroupent précisément dans les fonctions auxquelles les développeurs ne pensent pas comme déplaçant de la valeur — périphérie, récompenses, migration, urgence, claim. Ce sont les fonctions écrites le plus vite et revues le moins, et le catalogue montre, encore et encore, que c'est là où apparaîtra la prochaine instance des plus anciens bugs.