Cetus Sicherheitsprobleme: Worauf sollte das Dezentrale Finanzwesen-Team achten?

Autor: Haotian

Nachdem Sie den Sicherheitsbericht über den Hackerangriff von @CetusProtocol gelesen haben, werden Sie ein “interessantes” Phänomen feststellen: Die technischen Details sind ziemlich transparent offengelegt, die Notfallreaktion ist buchstäblich lehrbuchmäßig, aber bei der entscheidenden Frage “Warum wurde angegriffen?” wird das Wesentliche eher umschifft.

Der Bericht erklärt ausführlich, dass die checked\_shlw-Funktion der integer-mate-Bibliothek Fehler überprüft (sollte ≤2^192 sein, tatsächlich ≤2^256) und qualifiziert dies als “semantisches Missverständnis”. Diese Darstellung ist zwar technisch korrekt, lenkt jedoch geschickt den Fokus auf externe Verantwortlichkeiten, als ob Cetus ebenfalls ein unschuldiges Opfer dieses technischen Defekts wäre.

Die Frage ist, warum es, da integer-mate eine Open-Source- und weit verbreitete Mathematikbibliothek ist, bei dir zu dem absurden Fehler kommt, dass man mit nur 1 Token eine exorbitante Liquiditätsanteil erhalten kann?

Die Analyse der Angriffswege von Hackern zeigt, dass für einen perfekten Angriff vier Bedingungen gleichzeitig erfüllt sein müssen: fehlerhafte Überlaufüberprüfung, erhebliche Verschiebungsoperationen, Aufrundungsregeln und das Fehlen einer wirtschaftlichen Plausibilitätsprüfung.

Cetus hat bei jedem “Trigger”-Kriterium “unachtsam” gehandelt, zum Beispiel: die Annahme von Benutzereingaben wie 2^200, die Verwendung extrem gefährlicher großer Verschiebungsoperationen, das vollkommene Vertrauen in die Überprüfungsmechanismen externer Bibliotheken, und das Todesurteil war – als das System das “1 Token gegen astronomische Anteile”-Resultat berechnete, wurde dies ohne jegliche wirtschaftliche Plausibilitätsprüfung direkt ausgeführt.

Deshalb sollten die folgenden Punkte von Cetus wirklich überdacht werden:

1. Warum wurde die Verwendung von allgemeinen externen Bibliotheken nicht ausreichend auf Sicherheit getestet? Auch wenn die integer-mate-Bibliothek Merkmale wie Open Source, Beliebtheit und weit verbreitete Nutzung aufweist, hat Cetus, das damit Vermögenswerte im Wert von über 100 Millionen Dollar verwaltet, nicht ausreichend verstanden, wo die Sicherheitsgrenzen dieser Bibliothek liegen und ob es geeignete Alternativen gibt, falls die Bibliothek versagt. Offensichtlich fehlt Cetus das grundlegendste Bewusstsein für die Sicherheit der Lieferkette;

2. Warum wird erlaubt, astronomische Zahlen einzugeben, ohne Grenzen zu setzen? Auch wenn DeFi-Protokolle nach Dezentralisierung streben sollten, benötigt ein reifes Finanzsystem umso klarere Grenzen, je offener es ist.

Wenn das System die Eingabe von vom Angreifer sorgfältig konstruierten astronomischen Zahlen erlaubt, hat das Team offensichtlich nicht darüber nachgedacht, ob eine solche Liquiditätsnachfrage gerechtfertigt ist. Selbst die größten Hedgefonds der Welt können nicht so übertriebene Liquiditätsanteile benötigen. Offensichtlich fehlt es dem Cetus-Team an risikomanagementfähigen Talenten mit finanzieller Intuition;

3. Warum wird nach mehreren Runden von Sicherheitsaudits immer noch kein Problem im Voraus gefunden? Dieser Satz entlarvt unbeabsichtigt ein fatales kognitives Missverständnis: Das Projektteam lagert die Sicherheitsverantwortung an das Sicherheitsunternehmen aus und betrachtet das Audit als Goldmedaille für eine Ausnahme. Aber die Realität sieht hart aus: Security Audit Engineers sind gut darin, Codefehler zu finden, und wer hätte gedacht, dass es falsch sein könnte, das System zu testen, um das fantastische Austauschverhältnis zu berechnen?

Diese Art der Grenzverifizierung in Mathematik, Kryptographie und Wirtschaft ist der größte blinde Fleck in der modernen DeFi-Sicherheit. Die Wirtschaftsprüfungsgesellschaft wird sagen, dass “es sich um einen Konstruktionsfehler im Wirtschaftsmodell handelt, nicht um ein Problem der Codelogik”; Das Projektteam bemängelte, dass “die Prüfung keine Probleme festgestellt hat”; Und der Nutzer weiß nur, dass sein Geld weg ist!

Sieh mal, das offenbart letztendlich die systemischen Sicherheitsmängel der DeFi-Branche: Teams mit rein technischem Hintergrund mangeln es erheblich an einem grundlegenden “Finanzrisiko-Gespür”.

Laut dem Bericht von Cetus hat das Team offensichtlich nicht ausreichend reflektiert.

Im Vergleich zu den technischen Mängeln, die allein für den aktuellen Hackerangriff verantwortlich sind, denke ich, dass alle DeFi-Teams, beginnend mit Cetus, die Beschränkungen des rein technischen Denkens überwinden sollten, um ein echtes Sicherheitsbewusstsein für “Finanzingenieure” zu entwickeln.

Zum Beispiel: Finanzrisiko-Experten einbeziehen, um Wissenslücken im technischen Team zu schließen; ein mehrstufiges Prüfmechanismus durchführen, der nicht nur die Codeprüfung umfasst, sondern auch die notwendige Prüfung des Wirtschaftsmodells; “finanzielles Gespür” entwickeln, verschiedene Angriffszenarien und entsprechende Gegenmaßnahmen simulieren und jederzeit sensibel auf anomalien Operationen reagieren usw.

Das erinnert mich an meine bisherigen Erfahrungen in Sicherheitsunternehmen, einschließlich des Konsenses, den Branchenexperten @evilcos, @chiachih_wu, @yajinzhou, @mikelee205 in ihren Gesprächen hatten:

Mit der zunehmenden Reifung der Branche werden die technischen Bugs auf der Code-Ebene allmählich abnehmen, während die “Bewusstseins-Bugs” in der Geschäftlogik, die unklare Grenzen und unklare Verantwortlichkeiten aufweisen, die größte Herausforderung darstellen.

Auditfirmen können nur sicherstellen, dass der Code fehlerfrei ist, aber wie man “logische Grenzen” einhält, erfordert ein tieferes Verständnis des Geschäftswesens und die Fähigkeit, Grenzen vom Projektteam zu kontrollieren. (Die grundlegenden Ursachen vieler “Abschiebungsfälle”, bei denen es nach Sicherheitsprüfungen dennoch zu Hackerangriffen kam, liegen genau darin.)

Die Zukunft von DeFi gehört den Teams, die sowohl über fundierte Programmierkenntnisse als auch ein tiefes Verständnis der Geschäftslogik verfügen!