Am 22. Mai 2025 erlitt Cetus Protocol, die größte konzentrierte Liquiditäts-DEX auf Sui, einen großen Exploit, der die Liquidität über mehrere Pools hinweg abzog [1], was zu geschätzten Verlusten von rund 223 Millionen US-Dollar führte.
Der Exploit beruhte auf einem Fehler in einer benutzerdefinierten Funktion zur Verhinderung von Überläufen (d. h. **checked_shlw()**) [2]. Aufgrund einer falschen Konstante und eines falschen Vergleichs konnte die Funktion unsichere Bedingungen nicht erkennen, bevor sie einen Links-Shift durchführte, der in der Festkomma-Arithmetik von u256 verwendet wird. Dies ermöglichte eine stille Abschneidung der höchstwertigen Bits während wichtiger Delta-Berechnungen (z. B. der Logik, die berechnet, wie viel Token-Input für eine bestimmte Liquidität erforderlich ist). Durch sorgfältige Auswahl der Parameter (Liquiditätsgröße und Tick-/Preisbereichseinstellungen) konnte der Angreifer das Protokoll dazu bringen, die erforderliche Einzahlung als im Wesentlichen 1 Einheit Token zu berechnen, während die Position dennoch mit einer enormen Menge an Liquidität gutgeschrieben wurde. Mit dieser aufgeblähten, auf der Kette erfassten Position zog der Angreifer dann Liquidität ab und hob echte Reserven ab, wodurch die Pools geleert wurden.
Hintergrund
Cetus verwendet ein Concentrated Liquidity Market Maker (CLMM)-Design, bei dem Liquiditätsanbieter (LPs) Liquidität nur innerhalb eines gewählten Preisbereichs (ein Tick-Intervall) bereitstellen. Anstatt Gelder gleichmäßig über alle Preise zu verteilen, konzentrieren LPs ihr Kapital zwischen einer unteren und einer oberen Grenze. Dies verbessert die Kapitaleffizienz, macht das Protokoll jedoch stark von präziser Festkomma-Arithmetik abhängig, wenn zwischen Folgendem umgerechnet wird:
- dem Liquiditätsbetrag, der einer Position gutgeschrieben wird, und
- den tatsächlichen Token-Beträgen, die eingezahlt (oder abgehoben) werden müssen.
Im Allgemeinen berechnet das Protokoll bei der Hinzufügung von Liquidität durch einen Benutzer die Token-Deltas (wie viele zugrunde liegende Token erforderlich sind) basierend auf dem aktuellen Preis und dem gewählten Bereich. Wenn ein Benutzer Liquidität abzieht, führt das Protokoll die umgekehrte Berechnung durch, um festzustellen, wie viel die Position abheben darf.
Wenn die Berechnung „Wie viel Sie einzahlen müssen“ zu klein gemacht werden kann, während der Position weiterhin große Liquidität gutgeschrieben wird, kann der Angreifer diese gutgeschriebene Liquidität später abziehen und echte Reserven aus dem Pool abheben.
Schwachstellenanalyse
Die Grundursache war ein Fehler in einer Hilfsfunktion, die dazu diente, einen Links-Shift, der in der Festkomma-u256-Arithmetik verwendet wird, sicher durchzuführen (typischerweise << 64, um einen Skalierungsfaktor von 2^64 anzuwenden). In Move-basierten Systemen werden Überlaufprüfungen nicht für alle Operationen einheitlich durchgesetzt, und Bit-Shifting ist ein Bereich, in dem Entwickler oft manuelle Schutzmaßnahmen hinzufügen.
Cetus implementierte eine Hilfsfunktion zur Verhinderung von Überläufen (d. h. checked_shlw()), um zu bestimmen, ob das Verschieben eines u256-Werts um 64 Bits nach links die 256-Bit-Grenze überschreiten würde. Aufgrund einer falschen Konstante und eines falschen Vergleichs konnte die Prüfung jedoch für bestimmte große Eingaben umgangen werden, die hätten abgelehnt werden müssen.
Konkret wird get_delta_a verwendet, um die Menge der zugrunde liegenden Token (Token A) zu berechnen, die für eine gegebene Liquidität zwischen zwei Preisen (sqrt_price_0 und sqrt_price_1) erforderlich sind. Innerhalb von get_delta_a wird checked_shlw() aufgerufen, um sicherzustellen, dass der Zähler, der bei der Token-A-Berechnung verwendet wird, beim Verschieben nicht überläuft.
Die Überlaufprüfung in checked_shlw() ist jedoch falsch. Sie verwendet eine Maske von 0xffffffffffffffff << 192 (d. h. 2^256 - 2^192), die weit größer ist als der korrekte Schwellenwert. Infolgedessen kann ein Eingabewert, der größer als **2^192** aber kleiner als diese Maske ist, die Prüfung bestehen, obwohl das Verschieben nach links den u256-Bereich überschreiten würde. Das verschobene Ergebnis wird dann abgeschnitten, was einen falschen (kleineren) Wert ergibt.
Die folgende Abbildung vergleicht die anfällige Implementierung und die gepatchte Version. Die korrekte Grenze sollte 1 << 192 sein, nicht 0xffffffffffffffff << 192. Der Angreifer nutzte diese fehlerhafte Prüfung, um eine ungewöhnlich große Menge an LP-Token zu prägen, während er nur 1 Wei Token A einzahlte.
Angriffsanalyse
Während der Angreifer dieselbe Technik über mehrere Pools hinweg anwandte, war der zugrunde liegende Ablauf konsistent. Anhand dieses Transaktionsbeispiels http://suiscan.xyz/mainnet/tx/DVMG3B2kocLEnVMDuQzTYRgjwuuFSfciawPvXXheB3x verlief der Angriff wie folgt:
1) Manipulation des Poolpreises
Der Angreifer nutzte einen Flashloan, um schnell 10.024.321,28 haSUI zu erwerben, und tauschte dann 5.765.124,79 SUI aus, wodurch der Poolpreis von 18.956.530.795.606.879.104 auf 18.425.720.184.762.886 gesenkt wurde. Diese Preisbewegung ermöglichte es dem Angreifer, eine CLMM-Position zu eröffnen, die nur eine minimale Menge eines Tokens erforderte, und nutzte das „Single-Sided / Nearly Single-Token“-Liquiditätsverhalten in konzentrierten Liquiditätsdesigns.
2) Hinzufügen von Liquidität mit einer „fast kostenlosen“ Einzahlung
Als Nächstes wählte der Angreifer einen sehr engen Tick-Bereich (z. B. 300000–300200) und stimmte die Ziel-Liquidität sorgfältig ab. In CLMM-Systemen hängen die Token-Delta-Berechnungen von den Quadratwurzelpreisen an den Bereichsgrenzen ab, und enge Bereiche können bestimmte Zwischenwerte extrem empfindlich machen.
Durch die Abstimmung dieser Parameter verursachte der Angreifer eine interne Multiplikation, die einen u256-Zwischenwert ergab, der beim Links-Shift überlaufen hätte müssen, aber die fehlerhafte Checked-Shift-Schutzvorrichtung dennoch bestand. Infolgedessen berechnete das Protokoll nach dem durch den unsicheren Shift verursachten Abschneiden den erforderlichen Token-A-Betrag effektiv als 1 Einheit, während die Position dennoch mit massiver Liquidität (d. h. 10.365.647.984.364.446.732.462.244.378.333.008**)** geprägt/erfasst wurde.
3) Abziehen von Liquidität zur Entnahme echter Reserven
Mit einer On-Chain-Position, die scheinbar über aufgeblähte Liquidität verfügte, zog der Angreifer Liquidität ab und hob Vermögenswerte ab, als ob die Position ordnungsgemäß finanziert worden wäre. In diesem Schritt wurden die echten Reserven des Pools abgezogen.
4) Wiederholung in mehreren Pools
Nachdem der Exploit-Mechanismus validiert worden war, replizierte der Angreifer denselben Arbeitsablauf in mehreren Pools und steigerte so schnell die Gesamtverluste.
Zusammenfassung
Die Grundursache war eine fehlerhafte Überlaufprüfung um einen u256-Links-Shift im Festkomma-Rechenpfad, die es einem überlaufenden Shift ermöglichte, hohe Bits stillschweigend abzuschneiden, wodurch die erforderliche Einzahlung nahe Null erschien, während einer LP-Position dennoch massive Liquidität gutgeschrieben wurde, was die Entnahme von Reserven ermöglichte.
Lehren
- Seien Sie äußerst streng bei Shifts, Skalierungsfaktoren, Rundungen und Randbedingungen in der Festkomma-Arithmetik.
- Bevorzugen Sie bewährte sichere Mathematik-Primitive (oder formalisierte Invarianten) gegenüber Ad-hoc-Hilfsmitteln; validieren Sie Konstanten/Schwellenwerte sorgfältig.
- Fügen Sie Testfälle für Grenzfälle und Eigenschaftsbasiertes Testen für Maximalwerte, Grenz-Ticks und gegnerische Parameterkombinationen hinzu.
Referenz
Über BlockSec
BlockSec ist ein Full-Stack-Anbieter für Blockchain-Sicherheit und Krypto-Compliance. Wir entwickeln Produkte und Dienstleistungen, die Kunden bei der Code-Prüfung (einschließlich Smart Contracts, Blockchain und Wallets), der Echtzeit-Abwehr von Angriffen, der Analyse von Vorfällen, der Verfolgung illegaler Gelder und der Erfüllung von AML/CFT-Verpflichtungen während des gesamten Lebenszyklus von Protokollen und Plattformen unterstützen.
BlockSec hat mehrere Arbeiten zur Blockchain-Sicherheit auf renommierten Konferenzen veröffentlicht, mehrere Zero-Day-Angriffe auf DeFi-Anwendungen gemeldet, mehrere Hacks blockiert, um mehr als 20 Millionen Dollar zu retten, und Kryptowährungen im Wert von mehreren Milliarden Dollar gesichert.
-
Offizielle Website: https://blocksec.com/
-
Offizieller Twitter-Account: https://twitter.com/BlockSecTeam
