SlowMist enthüllt die Drift-Angriffskette: Änderung des Multi-Signature-Mechanismus, Offenlegung von Administratorrechten

Die On-Chain-Sicherheitsorganisation SlowMist hat am 2. April eine technische Analyse veröffentlicht, die die entscheidenden Voraussetzungen für den Diebstahl des Drift Protocol aufdeckt: Etwa eine Woche vor dem Angriff nahm Drift Anpassungen am Multisig-Mechanismus vor, und es wurden keine Zeit-Sperrschutzmechanismen synchron eingerichtet. Anschließend erlangte der Angreifer Administratorrechte, fälschte CVT-Tokens, manipulierte den Oracle und schaltete das Sicherheitsmodul ab, um systematisch hochwertige Vermögenswerte aus dem Liquiditätspool abzuziehen.

SlowMist Rekonstruktion der Angriffs-Vorboten: Multisig-Änderungen ohne Zeit-Sperre sind das Kernproblem

（Quelle: SlowMist）

Die Analyse von SlowMist zeigt, dass bei diesem Angriff der am meisten besorgniserregende Vorfall ein entscheidender Knotenpunkt ist: Etwa eine Woche vor dem Diebstahl passte Drift den Multisig-Mechanismus ohne das Einrichten irgendeiner Zeit-Sperre auf den Modus „2/5“ an und führte gleichzeitig 4 neue Unterzeichner ein.

Eine Zeit-Sperre ist in der Sicherheitsarchitektur des Protokolls eine notwendige Ergänzung für den Multisig-Mechanismus. Sie legt vor der Ausführung risikoreicher Konfigurationsänderungen eine verpflichtende Wartezeit fest (typischerweise 24–48 Stunden oder länger), sodass die Community und Sicherheitsorganisationen genügend Zeit haben, Anomalien zu erkennen und einzugreifen. Das Fehlen einer Zeit-Sperre bedeutet, dass, sobald der private Schlüssel eines neuen Unterzeichners gestohlen oder böswillig kontrolliert wird, der Angreifer Administrator-Operationen unmittelbar ausführen kann, ohne irgendeinen Warte-Puffer.

Die eine Woche vor dem Diebstahl erfolgte Änderung der Multisig-Architektur (Einführung von 4 neuen Unterzeichnern) ist zeitlich äußerst verdächtig und damit der am stärksten beachtete Warnknoten in dieser Sicherheitsanalyse.

Rekonstruktion der Angriffs-Schritte: Vom Administrator-Leak bis zum Diebstahl von 105,969 ETH

Laut der technischen Analyse von SlowMist führte der Angreifer nach dem Erhalt der administrativen Kontrolle die Vermögenswerte wie folgt systematisch leer:

CVT-Tokens fälschen: Innerhalb des Protokolls fiktive Tokens erschaffen und dabei die Logik zur normalen Vermögensvalidierung umgehen

Den Oracle manipulieren: Die externen Preisquellen des Protokolls ändern, sodass die On-Chain-Preisfindung verzerrt wird und günstige Bedingungen für das anschließende Ausziehen geschaffen werden

Sicherheitsmechanismen deaktivieren: Die in das Protokoll eingebauten Module für Risikokontrolle und Sicherheitsbeschränkungen abschalten und so Hindernisse für das Abziehen von Vermögenswerten beseitigen

Hochwertige Vermögenswerte übertragen: Systematisches Abziehen hochliquider Vermögenswerte aus dem Liquiditätspool, um das endgültige Leerräumen der Vermögenswerte abzuschließen

Derzeit wurden die gestohlenen Gelder hauptsächlich auf Ethereum-Adressen konsolidiert: insgesamt etwa 105,969 ETH (rund 226 Millionen US-Dollar). SlowMist sagt, dass die entsprechenden Geldflüsse noch fortlaufend verfolgt werden.

ZachXBT nennt Circle namentlich: Keine Sperrung von USDC für mehrere Stunden wird in der Branche stark kritisiert

Der On-Chain-Detektiv ZachXBT übte am selben Tag starke Kritik an Circle. Er wies darauf hin, dass während des US-Handelszeitraums, als Drift gestohlen wurde, USDC im Umfang von mehreren hunderttausend US-Dollar über ein Cross-Chain-Protokoll von Solana zur Ethereum übertragen wurde. Der gesamte Prozess habe „mehrere Stunden lang angedauert, ohne dass jemand eingriff“, die betreffenden Gelder seien bereits vollständig übertragen, und Circle habe „wieder einmal keinerlei Maßnahmen ergriffen“.

ZachXBT deckte zudem ein weiteres früheres Problem von Circle auf: Circle hatte irrtümlich über 16 geschäftliche Hot-Wallets eingefroren, und die entsprechenden Entsperrverfahren laufen bis heute weiter. Er nannte den CEO von Circle, Jeremy Allaire, und sagte, dass die Leistungen von Circle sich negativ auf die gesamte Kryptoindustrie auswirkten.

Diese Anschuldigung löste branchenweit eine breite Diskussion darüber aus, welche aktive Interventionsverantwortung Stablecoin-Emittenten bei Sicherheitsvorfällen tragen sollen.

Häufige Fragen

Warum ist das fehlende Einrichten einer Zeit-Sperre bei Multisig-Änderungen das Kernproblem dieses Angriffs?

Eine Zeit-Sperre ist die entscheidende Sicherheitsergänzung für den Multisig-Mechanismus. Sie legt vor der Ausführung von Operationen mit hohen Berechtigungen eine verpflichtende Wartezeit fest, damit die Community und Sicherheitsorganisationen Zeit haben, Anomalien zu erkennen und Maßnahmen zu ergreifen. Als Drift die Multisig-Architektur anpasste, wurde keine Zeit-Sperre eingerichtet. Das bedeutet, dass sobald die Nachweise eines hinzugefügten Unterzeichners offengelegt werden, der Angreifer sofort Administrator-Operationen ausführen kann und so die letzte Verteidigungslinie der Community-Überwachung umgeht. Der Zeitpunkt der Änderung, bei der eine Woche vor dem Diebstahl 4 neue Unterzeichner eingeführt wurden, ist der derzeit am stärksten beachtete Zweifel im laufenden Ermittlungsprozess.

Welche Verantwortung sollte Circle in diesem Vorfall tragen?

Die Kritik von ZachXBT richtet sich auf das Fehlen von sofortigem Monitoring und Intervention seitens Circle während des großvolumigen Cross-Chain-USDC-Transfers. Als USDC-Emittent hat Circle technisch die Fähigkeit, an den Vorfällen beteiligte Adressen einzufrieren, jedoch wurden während des mehrstündigen Zeitfensters der Geldübertragung keine Maßnahmen ergriffen. Diese Kontroverse berührt die Grenze der aktiven Interventionsverantwortung von Stablecoin-Emittenten bei DeFi-Sicherheitsvorfällen und ist derzeit ein Kern-Thema, das in der Branche intensiv diskutiert wird.

Welche technische Bedeutung hat die Kombination aus gefälschten CVT-Tokens und manipuliertem Oracle-Modul?

Gefälschte CVT-Tokens ermöglichen es Angreifern, innerhalb des Protokolls fiktive Liquidität oder Sicherheiten herzustellen; die Manipulation des Oracles sorgt dafür, dass das Protokoll bei der Preisfindung verzerrte Marktdaten verwendet. In Kombination führen beide dazu, dass das Protokoll „davon ausgeht“, dass ausreichende Sicherheiten vorhanden sind, wodurch Angreifer Vermögenswerte abziehen können, die weit über das hinausgehen, was ihnen tatsächlich zustehen würde. Diese klassische Kombinationsmethode tritt bei Smart-Contract-Angriffen häufig auf und wurde in mehreren DeFi-Diebstahlfällen beobachtet.