Wöchentlicher Web3-Sicherheitsbericht | 9. März – 15. März 2026

In der vergangenen Woche (09.03.2026 - 15.03.2026) hat BlockSec acht Angriffsereignisse erkannt und analysiert, mit geschätzten Gesamtverlusten von ~1,66 Mio. $. Die folgende Tabelle fasst diese Vorfälle zusammen; detaillierte Analysen zu jedem Fall finden sich in den folgenden Unterabschnitten.

EtherFreakers-Vorfall

Kurze Zusammenfassung

Am 9. März 2026 wurde EtherFreakers, ein NFT-Spiel auf Ethereum, aufgrund einer fehlerhaften Zählung („Double Counting“) angegriffen, was zu einem Verlust von ~25.000 $ führte. Jedes NFT im Spiel hält ein abhebbares ETH-Guthaben (genannt „Energie“). Als Spielmechanik können Spieler attack() verwenden, um ein anderes NFT zu fangen und die Energie des Ziel-NFTs zu beanspruchen. Der Vertrag zahlt jedoch das Guthaben des Ziels aus, überträgt das NFT aber, bevor die Abrechnung abgeschlossen ist. Ein „Transfer-Hook“ liest dann veraltete Daten vor der Auszahlung und speist einen Teil davon in einen globalen Dividendenpool ein, was den Pool ohne neue ETH-Deckung aufbläht. Der Angreifer nutzte diese Fangmechanik wiederholt, um den globalen Index aufzupumpen und dann das aufgeblähte Guthaben einer Reihe von NFTs abzuziehen.

Hintergrund

EtherFreakers ist ein On-Chain-NFT-Spiel, bei dem jedes NFT (ein „Freaker“) ein abhebbares ETH-Guthaben namens energy besitzt. Das System funktioniert wie ein Dividendenpool: Wenn bestimmte Aktionen stattfinden, wird ein Teil der ETH proportional auf alle Freaker verteilt. Die beanspruchbare ETH jedes Freakers wird durch einen globalen Akkumulator freakerIndex in Kombination mit einem tokenbezogenen Anteilswert fortune verfolgt.

Konkret lautet die Abrechnungsformel: energyOf = basic + (freakerIndex - index) * fortune. Der freakerIndex steigt, wenn _dissipateEnergyIntoPool(amount) ausgeführt wird, wodurch 80 % des amount an alle Freaker und 20 % an die Ersteller verteilt werden. Direkte Einzahlungen über charge() erhöhen nur basic, ohne den freakerIndex zu beeinflussen. Daher sollten Erhöhungen des freakerIndex immer durch echtes Ether gedeckt sein, das in das System fließt. Wenn der freakerIndex ohne entsprechenden ETH-Zufluss wächst, können Freaker mehr Ether einlösen, als der Vertrag tatsächlich hält.

Schwachstellenanalyse

Die Grundursache ist eine falsche Ausführungsreihenfolge im EtherFreak-Vertrag (0x3A27...c0f33). Wenn ein Fang gelingt, führt die attack()-Funktion diese Schritte in der folgenden Reihenfolge aus:

1. Zeile 237: Auszahlung von targetCharge (die volle Energie des Ziel-NFTs) an den Verteidiger als direkte ETH-Übertragung. Die Energie ist nun verbraucht.
2. Zeile 240: Aufruf von _transfer(defender, capturer, targetId), um das NFT zu verschieben. Intern ruft _transfer() den ERC-721-Hook _beforeTokenTransfer() auf, welcher _dissipateEnergyIntoPool() mit 0,1 % von energyOf(targetId) aufruft. Dies ist der erste Aufruf von _dissipateEnergyIntoPool() und er liest einen veralteten Wert, da Schritt 5 noch nicht stattgefunden hat.
3. Zeile 241: Expliziter Aufruf von _dissipateEnergyIntoPool(sourceSpent). Dies ist der zweite Aufruf, der Teil der normalen Spiel-Logik ist.
4. Zeilen 244-251: Aktualisierung von energyBalances für sowohl sourceId als auch targetId.

Der Fehler liegt in Schritt 2: Da energyBalances[targetId] noch nicht aktualisiert wurde, sieht der Hook weiterhin das Guthaben vor der Auszahlung und speist einen Teil der bereits ausgegebenen Energie in den Dividendenpool ein. Die direkte ETH-Auszahlung in Schritt 1 und die Pooleinspeisung in Schritt 2 stammen beide aus derselben Energie, was den freakerIndex ohne neue ETH-Deckung aufbläht. Es handelt sich um einen Fehler in der Geschäftslogik, nicht um einen Reentrancy-Fehler.

Angriffsanalyse

Die folgende Analyse basiert auf der Transaktion 0x89e24d...9abd2942.

• Schritt 1: Leihe von 1.700 WETH.
• Schritt 2: Prägung zweier neuer Freaker, Token 590 und 591, unter vom Angreifer kontrollierten Adressen.
• Schritt 3: Wiederholter Aufruf der attack(590, 591)-Funktion des Spiels, wobei die Ausführung auf dem erfolgreichen Fang-Zweig gehalten wird.
• Schritt 4: Nach jedem Erfolg Transfer von Token 591 an den Helfer, sodass das gleiche Paar wiederverwendet werden kann.
• Schritt 5: Jede erfolgreiche Schleife bläht den freakerIndex über das tatsächlich im System konservierte Ether-Niveau hinaus auf.
• Schritt 6: Sobald der Index hoch genug ist, Entladung einer Reihe zuvor kontrollierter Freaker. Die Token-IDs 496 bis 520 wurden jeweils für 0,278052246002402082 Ether entladen.
• Schritt 7: Umwandlung des abgezogenen Ethers in WETH, Rückzahlung des 1.700 WETH Flash-Loans und Behalt von etwa 7,498 WETH als Gewinn.

Fazit

Die Grundursache liegt im erfolgreichen Fang-Ablauf von attack(): EtherFreakers zahlt targetCharge aus, bevor der Energiestatus des Ziel-Tokens abgerechnet ist. _transfer() löst dann _beforeTokenTransfer() aus, welche die veraltete energyOf(targetId) vor der Auszahlung liest und einen Teil davon in den Pool auflöst. Dies erhöht den freakerIndex ohne neue Ether-Deckung, sodass dieselbe Zielenergie sowohl als Auszahlung als auch als Pooleinspeisung gezählt wird.

Um ähnliche Risiken in Zukunft zu reduzieren:

• Vermeiden Sie die Neuberechnung wirtschaftlicher Werte aus veränderlichem Status innerhalb von Transfer-Hooks, während dieselbe Transaktion noch abgerechnet wird.
• Wenn der Transfer-Hook eine Statusvariable liest, stellen Sie sicher, dass die Ausführungsreihenfolge das Ergebnis nicht beeinflusst.

Alkemi-Vorfall

Kurze Zusammenfassung

Am 10. März 2026 wurde das Alkemi-Protokoll auf Ethereum angegriffen, was zu einem Verlust von ~89.000 $ führte. Die Grundursache ist ein Buchungsfehler und fehlerhafte Geschäftslogik. Die fehlerhafte Liquidationslogik ermöglicht es jedem, seine eigene Position innerhalb derselben Transaktion zu liquidieren und davon zu profitieren. Zusätzlich führt ein Buchungsfehler dazu, dass der Abzug der eigenen Sicherheiten des Angreifers während der Liquidation überschrieben wird, was es dem Angreifer ermöglicht, Liquidationsbelohnungen zu erhalten, ohne die vorgesehenen Kosten zu tragen.

Hintergrund

Alkemi ist ein Leihprotokoll. Wenn die Position eines Kreditnehmers unterbesichert ist, kann jeder liquidateBorrow() aufrufen, um einen Teil der Schulden zurückzuzahlen und Sicherheiten mit einem Abschlag zu beschlagnahmen. Um übermäßige Liquidationen zu verhindern, begrenzt das Protokoll den rückzahlbaren Betrag pro Transaktion auf das Minimum von drei Werten:

1. Dem aktuellen Kreditguthaben des Kreditnehmers (currentBorrowBalance_TargetUnderwaterAsset).
2. Der maximalen Rückzahlung, die die Sicherheiten des Kreditnehmers nach Anwendung des Liquidationsabschlags abdecken können (calculateDiscountedBorrowDenominatedCollateral()).
3. Dem Rückzahlungsbetrag, der erforderlich ist, um das Konto zurück zur Liquidationsgrenze zu bringen (calculateDiscountedRepayToEvenAmount()).

Schwachstellenanalyse

Die Grundursache ist fehlerhafte Geschäftslogik und ein Buchungsfehler im Alkemi-Protokoll (0x4822...a888). Da currentBorrowBalance_TargetUnderwaterAsset zwangsläufig größer als 0 ist, solange der Kreditnehmer ausstehende Schulden hat, verlässt sich das AlkemiEarnPublic-Protokoll effektiv auf calculateDiscountedRepayToEvenAmount(). In der Implementierung wird jedoch stattdessen fälschlicherweise eine globale Variable closeFactorMantissa verwendet, um ein Limit für die zur Rückzahlung zugelassenen Schulden zu berechnen. Dadurch kann ein Angreifer seine eigene Position in derselben Transaktion sofort liquidieren. Zudem wird beim Überschreiben der Buchungen bei identischem Liquidator und Kreditnehmer der Abzugseffekt verloren.

Fazit

Die Grundursache ist, dass die fehlerhafte Liquidationslogik es dem Angreifer erlaubt, innerhalb derselben Transaktion zu leihen und die eigene Position zu liquidieren, während die fehlerhafte Buchungslogik die Gewinne weiter vervielfacht.

Um ähnliche Risiken in Zukunft zu reduzieren:

• Bei Saldoaktualisierungen für Kreditnehmer und Liquidatoren sollte das Protokoll direkt auf Speichervariablen operieren, anstatt die Salden zur getrennten Berechnung in temporäre Speichervariablen zu kopieren.

MT-Vorfall

Kurze Zusammenfassung

Am 10. März 2026 wurde MT Token, ein deflationärer Token auf der BNB Chain, angegriffen, was zu einem Verlust von ~242.000 $ führte. Die Grundursache ist eine fehlerhafte Handelsbeschränkungslogik in Kombination mit inkonsequenter Handhabung spezieller Transferbedingungen. Der Angreifer häufte MT-Token an, ohne Beschränkungen oder Gebühren auszulösen, manipulierte pendingBurnAmount durch kontrollierte Liquiditätsoperationen und erzwang einen abnormalen Zustand, in dem der Token-Preis künstlich aufgebläht wurde.

AAVE-Liquidationsvorfall

Kurze Zusammenfassung

Am 11. März 2026 erlitt AAVE falsche Liquidationen in Höhe von 21 Mio. $ auf Ethereum, was zu einem Verlust von ~1,01 Mio. $ für die betroffenen Nutzer führte. Die Grundursache war ein inkorrekter Oracle-Preis für wstETH, wodurch ursprünglich gesunde Positionen als unterbesichert eingestuft wurden.

Planet Finance-Vorfall

Kurze Zusammenfassung

Am 11. März 2026 wurde Planet Finance auf der BNB Chain angegriffen (Verlust ~10.000 $). Das Protokoll behandelte Erhöhungen des gespeicherten Kreditguthabens fälschlicherweise als aufgelaufene Zinsen, was es einem Angreifer ermöglichte, durch wiederholtes Leihen und Rabattabrechnungen seine Schulden künstlich zu drücken.

AM-Vorfall

Kurze Zusammenfassung

Am 12. März 2026 wurde AM Token mit einem Verlust von ~131.000 $ angegriffen. Durch eine verzögerte Burn-Mechanik, bei der Verkäufe einen Burn im nächsten Schritt auslösen, konnte der Angreifer die Reserve manipulieren und den Preis extrem verzerrt ausnutzen.

DBXen-Vorfall

Kurze Zusammenfassung

Am 12. März 2026 wurde DBXen mit einem Verlust von ~149.000 $ angegriffen. Die Ursache war eine Inkonsistenz zwischen _msgSender() und msg.sender bei der Verwendung eines Forwarders. Dies erlaubte es dem Angreifer, Belohnungen und Gebühren anhand veralteter Zyklusdaten zu beanspruchen.

Goose Finance-Vorfall

Kurze Zusammenfassung

Am 15. März 2026 wurde Goose Finance (~8.000 $) aufgrund eines Fehlers in der Reihenfolge der Anteilspreisbildung angegriffen. Deposits prägten Anteile, bevor Erträge gebucht wurden, was zu einer zu hohen Anteilsmenge führte. Der Angreifer nutzte dies durch Schleifen aus.

Über BlockSec

BlockSec ist ein Full-Stack-Blockchain-Sicherheits- und Krypto-Compliance-Anbieter. Wir entwickeln Produkte und Dienstleistungen, die Kunden bei der Code-Prüfung (Smart Contracts, Blockchain und Wallets), der Echtzeit-Abwehr von Angriffen, der Analyse von Vorfällen, der Verfolgung illichter Gelder und der Einhaltung von AML/CFT-Verpflichtungen unterstützen.

BlockSec hat zahlreiche Blockchain-Sicherheitsberichte auf prestigeträchtigen Konferenzen veröffentlicht, mehrere Zero-Day-Angriffe gemeldet, Angriffe abgeblockt, um mehr als 20 Millionen Dollar zu retten, und Milliarden an Kryptowährungen gesichert.

• Offizielle Website: https://blocksec.com/
• Offizieller Twitter-Account: https://twitter.com/BlockSecTeam
• 🔗 BlockSec Auditing Service : Anfrage einreichen
• 🔗 Phalcon Security APP: Demo buchen
• 🔗 Phalcon Compliance