Bug d'approval de Hedgey Finance

Le 19 avril 2024, le protocole DeFi de vesting et distribution de tokens Hedgey Finance a subi des exploits doubles sur Arbitrum (~42,6 M$) et Ethereum (~2,1 M$) pour une perte combinée de 44,7 M$. Le bug était une vérification de paramètre manquante sur une seule fonction de contrat.

Ce qui s'est passé

Hedgey fournissait des campagnes de vesting et de claim — les projets pouvaient verrouiller des tokens dans les contrats Hedgey et permettre aux destinataires de réclamer leur part selon des calendriers de vesting. La fonction createLockedCampaign était responsable de la mise en place de nouvelles campagnes et acceptait plusieurs paramètres décrivant les conditions de lockup de la campagne.

La fonction validait la plupart de ces paramètres — mais pas la configuration claimLockup, qui déterminait quels transferts de tokens et approvals étaient attachés à chaque claim. En soumettant un appel createLockedCampaign avec un claimLockup malveillant, l'attaquant pouvait faire émettre par le contrat des approvals sur les tokens de la victime vers une adresse de son choix.

Un prêt flash a financé le capital temporaire nécessaire pour mettre en place la campagne malveillante et déclencher le pattern d'approval. Une fois les approvals existantes on-chain, l'attaquant a appelé transferFrom et drainé les tokens — USDC, NOBL, MASA, BONUS — des comptes dont les propriétaires avaient déjà interagi avec les contrats Hedgey.

Conséquences

• Hedgey a suspendu les contrats affectés et envoyé un message on-chain à l'attaquant demandant le retour des fonds et offrant un traitement white-hat.
• L'équipe a migré vers un contrat de campagne repensé avec validation explicite sur chaque paramètre.
• L'attaquant n'a pas répondu à l'offre de bounty ; les fonds ont été blanchis.

Pourquoi c'est important

Hedgey a renforcé la vérité non glamour selon laquelle chaque paramètre d'entrée fait partie de la frontière de confiance — particulièrement dans les protocoles qui prennent une configuration de callback des utilisateurs. Un seul champ non vérifié sur une fonction setter privilégiée suffit à compromettre un protocole entier ; la réponse défensive est les allowlists de paramètres deny-by-default, la vérification formelle de la couverture complète des paramètres et les invariants au niveau contrat qui ne peuvent être violés par aucune combinaison d'entrées.