Hedgey Finance Approval-Bug

Am 19. April 2024 erlitt das DeFi-Vesting- und Token-Distributionsprotokoll Hedgey Finance doppelte Exploits über Arbitrum (rund 42,6 Mio. $) und Ethereum (rund 2,1 Mio. $) für einen kombinierten Verlust von 44,7 Mio. $. Der Bug war ein fehlender Parameter-Check in einer einzigen Contract-Funktion.

Was geschah

Hedgey stellte Vesting- und Claim-Kampagnen bereit — Projekte konnten Tokens in Hedgey-Contracts sperren und Empfänger ihren Anteil gemäß Vesting-Plänen claimen lassen. Die Contract-Funktion createLockedCampaign war für das Anlegen neuer Kampagnen zuständig und akzeptierte mehrere Parameter, die die Lockup-Bedingungen der Kampagne beschrieben.

Die Funktion validierte die meisten dieser Parameter — aber nicht die claimLockup-Konfiguration, die bestimmte, welche Token-Transfers und Approvals an jeden Claim angehängt waren. Mit der Übergabe eines createLockedCampaign-Aufrufs mit bösartigem claimLockup konnte der Angreifer den Contract dazu bringen, Approvals auf den Tokens des Opfers an eine Adresse seiner Wahl auszustellen.

Ein Flash Loan finanzierte das temporäre Kapital, das nötig war, um die bösartige Kampagne aufzusetzen und das Approval-Muster auszulösen. Sobald die Approvals On-Chain existierten, rief der Angreifer transferFrom auf und drainte Tokens — USDC, NOBL, MASA, BONUS — aus Konten, deren Eigentümer jemals mit den Hedgey-Contracts interagiert hatten.

Folgen

• Hedgey pausierte betroffene Contracts und sandte eine On-Chain-Nachricht an den Angreifer, mit der Bitte um Rückgabe der Gelder und Angebot der White-Hat-Behandlung.
• Das Team migrierte zu einem neu designten Kampagnen-Contract mit expliziter Validierung jedes Parameters.
• Der Angreifer reagierte nicht auf das Bounty-Angebot; Gelder wurden gewaschen.

Warum es wichtig ist

Hedgey bekräftigte die unglamouröse Wahrheit, dass jeder Input-Parameter Teil der Trust-Boundary ist — insbesondere in Protokollen, die Callback-Konfiguration von Nutzern entgegennehmen. Ein einziges ungeprüftes Feld in einer privilegierten Setter-Funktion reicht, um ein gesamtes Protokoll zu kompromittieren; die defensive Antwort sind Deny-by-Default-Parameter-Allowlists, formale Verifikation kompletter Parameter-Abdeckung und Contract-ebene Invarianten, die durch keine Eingabe-Kombination verletzt werden können.