Analyse des Hedgey-Angriffsvorfalls: Verlust von mehreren zehn Millionen Dollar bei der Token-Autorisierung

Am 19. April 2024 wurde der Hedgey Token Claim-Vertrag auf mehreren Ketten wie Ethereum und Arbitrum angegriffen, was zu Verlusten in zweistelliger Millionenhöhe führte. Das Hedgey-Projektteam gab sofort eine Sicherheitswarnung heraus und erinnerte Benutzer, die Token-Anspruchsaktivitäten erstellt hatten, daran, die Token-Anspruchsaktivitäten über offizielle Kanäle abzubrechen. (https://twitter.com/hedgeyfinance/status/1781257581488418862)

Attack Brief

Hedgey hilft DAOs und On-Chain-Organisationen, Token durch On-Chain- und programmatische Token-Ausgabe zu verteilen werden an ihr Team, Mitwirkende, Investoren und die Community verteilt. Das Tool, bei dem die Sicherheitslücke dieses Mal auftrat, ist das Produkt „Token Claims“, mit dem Benutzer eine Token-Anspruchsseite erstellen, über CSV-Dateien mehr als 100.000 Empfänger zur Whitelist hinzufügen und steuern können, wie Flows, Zeitsperren und beanspruchte Token weitergeleitet werden können durch Recycling oder andere Methoden freigesetzt werden.

Die von diesem Angriff ausgenutzte Vertragsschwachstelle besteht darin, dass der ClaimCampaigns-Vertrag im Token Claims-Produkt, wenn er ein Token-Anspruchsereignis erstellt, seinen Token an die vom Ersteller angegebene Adresse autorisiert. Wenn der Ersteller die Beanspruchung des Ereignisses abbricht, wird der vom Ersteller während der Ereigniserstellungsphase übertragene Token an eine andere vom Ersteller angegebene Adresse zurückgegeben, die Token-Autorisierung wird jedoch nicht widerrufen, was dazu führt, dass die Adresse des Erstellers des Ereignisses die Informationen weiterhin verwenden kann autorisiert durch den ClaimCampaigns-Token.

Am Angriff beteiligte Schlüsseladressen

Dieser Angriff umfasst mehrere Transaktionen. Wir verwenden nur die folgende Transaktion zum Diebstahl von NOBL-Tokens als Beispiel, um das Angriffsprinzip zu analysieren.

Attack -Transaktion: https: //etherscan.io/tx/0x017ce9593350cba65d506e1a87e52d20079fdfa80a350a89Fe6fc875f2d9f9

attack EOA:

0B15E15ATACK 7181dda2

attacker (Vertrag):

0xd818ff3d5cfc938014b270d0c8029ba04629b549

Vulnerable Contract (Vertrag ClaimCampaigns):

0xbc452fdc8f851d7c5b72e1fe74dfb63bb793d511

Gestohlener Token (NobleBlocks: NOBL Token):

0x88b9f5c663 42ebaf661b3e2836b807c8cb1b3195

Analyse des Angriffsprozesses

1.Angriffsimplementierung

In der Phase der Angriffsimplementierung Der Angreifer rief wiederholt die Funktion „createLockedCampaign“ des anfälligen Vertrags auf, um eine Kampagne zu erstellen, und rief dann die Funktion „cancelCampaign“ auf, um die Kampagne zu löschen. Beim Erstellen einer Kampagne überträgt der Angreifer eine bestimmte Anzahl von NOBL-Tokens an den Schwachstellenvertrag und erhält das durch den Schwachstellenvertrag autorisierte NOBL-Token-Nutzungslimit. Wenn die Kampagne gelöscht wird, gibt der Schwachstellenvertrag die NOBL-Tokens zurück, die der Angreifer beim Erstellen der Kampagne übertragen hat. Zu diesem Zeitpunkt widerruft der Schwachstellenvertrag jedoch nicht das für den Angreifer autorisierte NOBL-Token-Nutzungslimit. Daher kann der Angreifer durch das Erstellen einer Kampagne und das anschließende Löschen der Kampagne die Macht erlangen, die vom anfälligen Vertrag gehaltenen NOBL-Token aus dem Nichts auszugeben.

Die spezifischen Angriffsschritte sind wie folgt:

1. Der Angreifer ruft die Funktion „createLockedCampaign“ des anfälligen Vertrags auf, um eine Kampagne zu erstellen, und legt in den Parametern des Angreifers sowohl „campaign.manager“ als auch „claimLockup.tokenLocker“ fest sich selbst und setzt „campaign.token“ auf NOBL-Tokens, „campaign.amount“ auf „680000000000000000000000“ (die Dezimalzahl der NOBL-Tokens ist 18, das entspricht also 680.000 NOBL-Tokens) und „donation.amount“ ist auf 0 gesetzt. Wie aus dem Funktionscode „createLockedCampaign“ ersichtlich ist, überträgt der Angreifer zunächst die NOBL-Tokens an den anfälligen Vertrag und verwendet dann die Funktion „safeIncreaseAllowance“, um den anfälligen Vertrag an „claimLockup.tokenLocker“ (den Angreifer) zu autorisieren, diese auszugeben Die Macht der NOBL-Tokens erlaubt dem Angreifer so viel „Kampagnenbetrag“.

   

2. Der Angreifer ruft die Funktion „cancelCampaign“ auf, um die in Schritt 1 erstellte Kampagne zu löschen. Wie aus dem Funktionscode ersichtlich ist, löscht der angreifbare Vertrag die Daten der Kampagne und ruft die Funktion „withdrawTokens“ auf TransferHelper-Bibliothek zum Löschen der Kampagne in Schritt 1. In diesem Schritt werden die vom Angreifer übertragenen NOBL-Tokens an „campaign.manager“ (Angreifer) zurückgegeben. Zu diesem Zeitpunkt wurde die Kampagne erfolgreich abgebrochen. Das durch den Schwachstellenvertrag für den Angreifer in Schritt 1 autorisierte NOBL-Token-Nutzungskontingent wurde jedoch nicht gleichzeitig gelöscht. Daher hat der Angreifer zu diesem Zeitpunkt auch die Macht, die NOBL-Token des anfälligen Vertrags auszugeben.

   

   

3. Der Angreifer wiederholte die Schritte 1 und 2 25 Mal und erhielt schließlich die Nutzungsquote von 680000 * 25 = 17000000 NOBL-Token aus dem anfälligen Vertrag.

2. Einsammeln des gestohlenen Geldes

In der Phase des Einsammelns des gestohlenen Geldes ruft der Angreifer direkt die „transferFrom“-Funktion des NOBL-Tokens auf, um den NOBL-Token vom anfälligen Vertrag an die EOA-Adresse des Angreifers zu übertragen. Aufgrund des Angriffs während der Angriffsimplementierungsphase hat der Angreifer das Recht erhalten, die im anfälligen Vertrag enthaltenen NOBL-Token auszugeben, sodass die Limitüberprüfung in der Funktion „transferFrom“ reibungslos verlaufen kann. Am Ende hat der Angreifer die NOBL erfolgreich gestohlen Token im anfälligen Vertrag.

Bitte überprüfen Sie die Transaktion auf spezifische Details: https://etherscan.io/tx/0x47da1ac72d488f746865891c9196c1632ae04f018b285b762b2b564ad1d3a9e5

An dem Angriff beteiligte Transaktionen

Durch ZAN KYT-Datenanalyse kann der Angreifer dem Schwachen den NOBL-Token wegnehmen, bevor er ihn entwendet Vertrag, der die Vertragsschwachstelle ausnutzt, um es dem anfälligen Vertrag zu ermöglichen, dem Angreifer den Genehmigungstoken-Transaktions-Hash wie folgt zu geben (es werden nur Transaktionen auf Ethereum aufgeführt):

Derzeit hat der Angreifer einen Teil der illegalen Gewinne an eine andere Adresse übertragen 0xd84f48b7D1AaFA7bd5905c95c5d1ffB2625AdA46 , es gibt derzeit keine weiteren Aktionen. Der Entwickler des Anspruchsvertrags (0x5a4bC2bdA1f6B9929b6efdCef4728246bEc4C635) kontaktierte den Angreifer über den Blockscan-Chat, gab die Schwachstelle im Vertrag zu und ging davon aus, dass es sich bei ihrem Verhalten um eine White-Hat-Operation handelte, in der Hoffnung, dass der Angreifer sie innerhalb von 24 Stunden kontaktieren würde.

Sicherheitsempfehlungen

Durch die Analyse dieses Angriffsvorfalls haben wir die folgenden Vorschläge:

1. Überprüfen Sie den Betrieb der Token-Autorisierung im Projekt genau. Projektentwickler und Vertragsprüfer sollten klären, welche Geschäftsszenarien eine Token-Autorisierung erfordern und welche Geschäftsszenarien eine recycelte Token-Autorisierung erfordern, um zu verhindern, dass nicht wiederhergestellte Token-Autorisierungen oder unerwartete redundante Autorisierungen von Angreifern verwendet werden.

2. Das Projekt sollte einen Notaussetzungsmechanismus einrichten. Es wird empfohlen, dass bei Projekten mit Kapitalzirkulation ein vollständiger Aussetzungsmechanismus eingerichtet wird, damit Verluste im Falle eines Angriffs rechtzeitig gestoppt werden können.

Dieser Artikel wurde gemeinsam von Cara (X-Konto @Cara6289) und XiG (X-Konto @SHXiGi) vom ZAN-Team geschrieben.

Das obige ist der detaillierte Inhalt vonAnalyse des Hedgey-Angriffsvorfalls: Verlust von mehreren zehn Millionen Dollar bei der Token-Autorisierung. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!