SUI-Ökosystem DEX #Cetus wurde angegriffen. Ist die Code-Sicherheitsprüfung wirklich ausreichend? Die Gründe und Auswirkungen des Angriffs auf Cetus sind vorerst unklar. Lassen Sie uns zunächst die Sicherheitsprüfungen des Codes von Cetus betrachten. Als Laien können wir die spezifischen technischen Details nicht verstehen, aber diese Zusammenfassung der Prüfung ist verständlich. ➤ Certik-Prüfung Schauen wir uns an, dass Certik bei der Sicherheitsprüfung des Codes von Cetus nur 2 geringfügige Gefahren festgestellt hat, die bereits behoben wurden. Es gibt außerdem 9 informative Risiken, von denen 6 behoben wurden. Die von Certik gegebene Gesamtbewertung beträgt 83,06, die Bewertung der Codeprüfung liegt bei 96 Punkten. ➤ Weitere Prüfberichte von Cetus (SUI-Chain) Auf dem Github von Cetus sind insgesamt 5 Prüfberichte aufgeführt, wobei der Bericht von Certik nicht enthalten ist. Es wird geschätzt, dass das Projektteam auch weiß, dass die Prüfung von Certik eher formeller Natur ist, weshalb dieser Bericht nicht aufgenommen wurde. Cetus unterstützt sowohl die Aptos- als auch die SUI-Chain. Diese 5 Prüfberichte stammen von MoveBit, OtterSec und Zellic. MoveBit und OtterSec haben jeweils den Code von Cetus auf der Aptos- und SUI-Chain geprüft, während Zellic wahrscheinlich ebenfalls den Code auf der SUI-Chain geprüft hat. Da der Angriff auf Cetus auf der SUI-Chain stattfand, betrachten wir im Folgenden nur den Prüfbericht von Cetus auf der SUI-Chain. ❚ Prüfbericht von MoveBit Bericht hochgeladen auf Github am: 2023-04-28 Wenn wir die spezifischen Inhalte der Prüfung nicht verstehen, können wir eine solche Tabelle finden, um die Anzahl der Risiken auf verschiedenen Ebenen und deren Behebungsstatus zu sehen. Der Prüfbericht von MoveBit zu Cetus hat insgesamt 18 Risikoprobleme festgestellt, darunter 1 kritisches Risiko, 2 wesentliche Risiken, 3 moderate Risiken und 12 geringfügige Risiken, die alle behoben wurden. Das sind mehr Probleme als die, die Certik festgestellt hat, und Cetus hat diese Probleme alle behoben. ❚ Prüfbericht von OtterSec Bericht hochgeladen auf Github am: 2023-05-12 Der Prüfbericht von OtterSec zu Cetus hat insgesamt 1 hohes Risiko, 1 moderates Risiko und 7 informative Risiken festgestellt. Da die Tabelle im Bericht den Behebungsstatus der Risiken nicht direkt anzeigt, werde ich keinen Screenshot machen. Das hohe Risiko und das moderate Risiko wurden bereits behoben. Bei den informativen Risiken wurden 2 behoben, 2 haben einen Reparaturpatch eingereicht, und 3 sind noch offen. Nach einer groben Untersuchung sind diese 3: • Inkonsistenz zwischen den Versionen von Sui und Aptos, die die Genauigkeit der Preisberechnung im Liquiditätspool beeinträchtigen könnte. • Fehlende Validierung des Pausenzustands, bei Swap wird nicht überprüft, ob der Liquiditätspool pausiert ist. Wenn der Pool pausiert ist, könnte dennoch gehandelt werden. • Umwandlung des Typs u256 in u64, was zu Überläufen führen kann, wenn der Wert MAX_U64 überschreitet, was bei großen Transaktionen zu Berechnungsfehlern führen könnte. Es ist derzeit unklar, ob der Angriff mit diesen Problemen zusammenhängt. ❚ Prüfbericht von Zellic Bericht hochgeladen auf Github am: April 2025 Der Prüfbericht von Zellic zu Cetus hat insgesamt 3 informative Risiken festgestellt, die nicht behoben wurden: • Ein Funktionsautorisierungsproblem, das es jedem erlaubt, Gebühren auf jedes Partnerkonto einzuzahlen. Das scheint kein Risiko darzustellen, es ist eine Einzahlung, kein Abheben. Daher hat Cetus dies vorerst nicht behoben. • Es gibt eine veraltete Funktion, die weiterhin referenziert wird, was zu redundanten Codes führt. Das scheint kein Risiko darzustellen, ist jedoch nicht konform mit den Codierungsstandards. • Ein UI-Darstellungsproblem in den NFT-Anzeigedaten, das ursprünglich mit einem Zeichenformat hätte gelöst werden können, aber Cetus verwendete einen komplexeren Datentyp aus der Move-Sprache. Das ist kein großes Problem und möglicherweise wird Cetus in Zukunft weitere Funktionen für NFTs entwickeln. Insgesamt hat Zellic 3 Probleme im Bereich der Codierungsstandards festgestellt, die im Grunde kein Risiko darstellen. Wir sollten uns an diese drei Prüfstellen erinnern: MoveBit, OtterSec und Zellic. Denn die meisten Prüfstellen auf dem Markt sind auf EVM-Prüfungen spezialisiert, während diese drei Prüfstellen auf die Prüfung von Move-Code spezialisiert sind. ➤ Prüfung und Sicherheitsstufen (am Beispiel neuer DEX) Zunächst einmal gibt es bei Projekten, die nicht geprüft wurden, ein gewisses Rug-Risiko. Schließlich sind sie nicht bereit, auch nur für diese Prüfung zu bezahlen, was es schwer macht, an eine langfristige Geschäftsabsicht zu glauben. Zweitens ist die Certik-Prüfung eigentlich eine Art "Beziehungsprüfung". Warum nenne ich es "Beziehungsprüfung"? Certik hat eine sehr enge Zusammenarbeit mit CoinMarketCap. Auf der Projektseite von CoinMarketCap gibt es ein Prüfungs-Icon, das zu Certiks Navigationsplattform Skynet führt. CoinMarketCap, als Plattform von Binance, hat indirekt eine Partnerschaft zwischen Certik und Binance geschaffen. Tatsächlich ist die Beziehung zwischen Binance und Certik immer gut gewesen, weshalb die meisten Projekte, die auf Binance gelistet werden wollen, Certiks Prüfung anstreben. Wenn ein Projekt also eine Certik-Prüfung anstrebt, möchte es höchstwahrscheinlich auf Binance gelistet werden. Die Geschichte hat jedoch gezeigt, dass Projekte, die nur von Certik geprüft wurden, eine hohe Wahrscheinlichkeit haben, angegriffen zu werden, wie z.B. DEXX. Einige Projekte sind sogar bereits FUG gegangen, wie z.B. ZKasino. Natürlich bietet Certik auch andere Sicherheitsdienste an, nicht nur Codeprüfungen. Certik scannt auch Websites, DNS usw. und bietet einige Sicherheitsinformationen, die über die Codeprüfung hinausgehen. Drittens suchen viele Projekte 1 bis mehrere andere hochwertige Prüfstellen für die Code-Sicherheitsprüfung. Viertens führen einige Projekte neben professionellen Codeprüfungen auch Bug-Bounty-Programme und Prüfungswettbewerbe durch, um Ideen zu sammeln und Schwachstellen auszuschließen. Da in diesem Fall ein DEX-Produkt angegriffen wurde, betrachten wir einige neuere DEX als Beispiele: --------------------------- ✦✦✦ GMX V2, geprüft von 5 Unternehmen: abdk, certora, dedaub, guardian, sherlock, und bietet ein Bug-Bounty-Programm mit einer maximalen Belohnung von 5 Millionen USD an. ✦✦✦ DeGate, geprüft von 35 Unternehmen: Secbit, Least Authority, Trail of Bits, und bietet ein Bug-Bounty-Programm mit einer maximalen Belohnung von 1,11 Millionen USD an. ✦✦✦ DYDX V4, geprüft von Informal Systems, und bietet ein Bug-Bounty-Programm mit einer maximalen Belohnung von 5 Millionen USD an. ✦✦✦ hyperliquid, geprüft von hyperliquid, und bietet ein Bug-Bounty-Programm mit einer maximalen Belohnung von 1 Million USD an. ✦✦ UniversalX, geprüft von Certik und einer anderen spezialisierten Prüfstelle (der Bericht wurde vorübergehend entfernt). ✦ GMGN ist etwas besonders, da ich keinen Prüfbericht finden konnte, nur ein Bug-Bounty-Programm mit einer maximalen Belohnung von 10.000 USD. ➤ Abschließend Nach der Überprüfung der Code-Sicherheitsprüfungen dieser DEX können wir feststellen, dass selbst DEX wie Cetus, die von 3 Prüfstellen gemeinsam geprüft wurden, dennoch angegriffen werden können. Eine Prüfung durch mehrere Stellen, kombiniert mit Bug-Bounty-Programmen oder Prüfungswettbewerben, bietet relativ gute Sicherheitsgarantien. Für einige neue DeFi-Protokolle gibt es jedoch noch Probleme, die in den Codeprüfungen nicht behoben wurden. Das ist der Grund, warum die Bienenbrüder besonders auf die Codeprüfungen neuer DeFi-Protokolle achten.