Am 22. Mai 2025 zielte ein großer Exploit auf das Cetus-Protokoll auf der Sui-Blockchain ab, was zu Schäden in Höhe von schätzungsweise 223 Millionen US-Dollar führte. Dieser Vorfall erregte aufgrund der ungewöhnlichen Mechanik sofortige Aufmerksamkeit im gesamten Ökosystem, insbesondere bei technischen Beobachtern. Was folgt, ist eine umfassende Analyse des Angriffs, angefangen bei Flash-Swaps und Tick-Manipulationen bis hin zu einer stillen Sicherheitslücke in der Logik zur Erkennung von Überläufen.

https://suiscan.xyz/mainnet/tx/DVMG3B2kocLEnVMDuQzTYRgjwuuFSfciawPvXXheB3x

Das Setup

Der Angreifer initiierte den Exploit, indem er flash_swap nutzte, um sich im Austausch gegen HasUI eine große Menge an SUI-Tokens auszuleihen. Im Gegensatz zu herkömmlichen Flashloans ermöglicht flash_swap in Cetus einem Benutzer, token1 (in diesem Fall SUI) im Voraus zu erhalten und dann token0 (hasUI) innerhalb derselben Transaktion zurückzuzahlen. Dieser Mechanismus ist von zentraler Bedeutung für das Setup des Angreifers.

In diesem speziellen Fall erwarb der Angreifer erfolgreich 5,76 Millionen SUI und war verpflichtet, 10,02 Millionen SUI zurückzuzahlen. Während dieses Swaps wurde der Preis von HasUI im Liquiditätspool jedoch drastisch manipuliert. Der Kurs des Pools fiel von einem Tick, der einem Verhältnis von 1,056 entspricht, auf einen Tick, der so tief war, dass der Kurs lediglich 0,0000009977 erreichte — eine enorme Abwertung auf 0,00009% seines ursprünglichen Kurses.

Die Preisspanne, die der Tick-Spanne entspricht, ist:

Strategische Liquiditätsspritze

Nach diesem Kursabsturz verwendete der Angreifer open_position, um eine Liquiditätsposition mit einer engen Spanne zu erstellen, wobei er einen hochspezifischen Tickbereich auswählte (TickLower: 300000, TickUpper: 300200). In dieses manipulierte Umfeld injizierten sie eine astronomische Menge an Liquidität: mehr als 10^34 Einheiten, alle innerhalb der extrem komprimierten Preisspanne, die durch den Tick-Kollaps entstanden war.

Dies wurde durch eine scheinbar harmlose Funktion ermöglicht: get_amount_by_liquidity. Unter normalen Bedingungen berechnet diese Funktion, wie viel von Token A und Token B benötigt wird, um ein bestimmtes Liquiditätsniveau zu erreichen. Dazu verwendet sie Hilfsfunktionen wie get_delta_a, das auf get_sqrt_price_at_tick basiert.

Da der manipulierte aktuelle Tick jedoch -138185 betrug und der gewählte Tickbereich weit außerhalb dieses Bereichs lag (ab 300000), sorgte der Logikpfad innerhalb von get_amount_by_liquidity dafür, dass Berechnungen einen anfälligen Codeabschnitt durchliefen, in dem eine Linksshift-Operation (checked_shlw) involviert war.

Überlauf und Kürzung: Die Kernschwachstelle

Hier wird der Exploit wirklich technisch. Die Funktion checked_shlw soll das Verschieben einer 256-Bit-Zahl um 64 Bit nach links bewältigen. In Solidity-ähnlichen Umgebungen ist eine solche Operation riskant, da sie überlaufen kann. Bei dieser speziellen Implementierung wurde versucht, Überläufe zu erkennen, indem überprüft wurde, ob die Eingabe einen vordefinierten Schwellenwert überschritten hat: 0xffffffffffffff << 192.

Der tatsächliche Schwellenwert für die Erkennung einer sicheren Verschiebung um 64 Bit sollte 2^ (256 - 64) - 1 sein. (0xffffffffffffffff << 192) ist jedoch größer als 2^192. Dies bedeutet, dass eine sorgfältig gewählte Eingabe die Überlaufprüfung umgehen könnte, indem sie unter dem im Code verwendeten Schwellenwert liegt, aber immer noch groß genug ist, um während der Ausführung einen Überlauf zu verursachen.

Der Angreifer lieferte eine solche Eingabe, bei der die Multiplikation von Liquidität und Preisdifferenz im Hintergrund überlief und ein viel kleinerer Wert als beabsichtigt zurückgegeben wurde — fast Null.

Infolgedessen berechnete das Protokoll, dass der Angreifer nur einen unbedeutenden Betrag an Token A — im Wesentlichen eine Einheit — zahlen musste, um dem Pool massive Liquidität hinzuzufügen. Diese Fehlkalkulation ermöglichte es dem Angreifer, massive Liquidität ohne wirkliche Kosten zuzuführen.

Anschließend entfernte der Angreifer die zusätzliche Liquidität über remove_liquidity und beendete den Angriff, indem er die unbezahlten Token von flash_swap über repay_flash_swap bezahlte. Der Angreifer erzielte einen Gewinn von 5.765.124 SUI und 10.024.321 HasUI. Schließlich hat das Cetus-Team die Sicherheitsanfälligkeit durch zwei PRs behoben:

https://github.com/CetusProtocol/integer-mate/pull/6/files

Cetus veröffentlichte schnell einen Patch in seinem Integer-Mate-Repository, wobei der erste Pull-Request versuchte, die Überlauferkennung zu verfeinern. Diese erste Korrektur war jedoch unzureichend. Es wurde eine Maske mit dem Wert 1 << 192 verwendet, sodass auch Groß-/Kleinschreibung durchrutschen konnte.

Es folgte ein zweiter Pull-Request mit einem strengeren Vergleich, bei dem überprüft wurde, ob die Eingabe größer oder gleich 2^192 ist, um die richtigen Grenzen für sicheres Verschieben nach links sicherzustellen. Nur mit dieser Korrektur wurde die Sicherheitslücke effektiv gemindert.

https://github.com/CetusProtocol/integer-mate/pull/7/files