Von der Vorabunterschrift bis zum Verlust der Berechtigungen, warum sind Drifts Sicherheitslinien so durchlässig?
Verfasst von: Four Pillars
Übersetzung: AididiaoJP, Foresight News
Kernpunkte
Am 1. April 2026 um 16:05 (UTC-Zeit) wurde das Drift-Protokoll von einem bedeutenden Angriff im Wert von etwa 285 Millionen USD heimgesucht. Drift ist die führende dezentrale Handelsplattform für Perpetual Contracts im Solana-Ökosystem. Dieser Angriff ist Teil eines komplexen Plans zur Manipulation von Sicherheiten: Die Angreifer nutzten den kompromittierten Administratorschlüssel, um einen neuen Spotmarkt für einen wertlosen Token zu eröffnen, schlossen dann den Abhebungsschutzmechanismus und entzogen schließlich echte Vermögenswerte durch gefälschte Sicherheitenwerte.
Der Angriff kombinierte vorab signierte Techniken, die auf persistenten Zufallszahlen basieren, mit fortgeschrittenen sozialen Ingenieurmethoden. Ab dem 23. März erstellten die Angreifer persistenten Zufallszahl-Konten für zwei Multi-Signatur-Signierer und zwei von den Angreifern kontrollierte Konten. Selbst nachdem die Protokollparteien am 27. März eine legale Multi-Signatur-Übertragung durchgeführt hatten, gelang es den Angreifern weiterhin, den Zugriff auf die neuen Multi-Signaturen von zwei Signierern zu erlangen. Die Angreifer erhielten durch irreführende Transaktionsinhalte vorab unterschriebene Dokumente von legitimen Signierern, speicherten diese mit persistenten Zufallszahlen und führten sie am 1. April in großen Mengen aus, wobei sie schließlich die Administratorrechte erlangten. Bei diesem Vorfall gab es keine Offenlegung von mnemonischen Phrasen oder Schwachstellen im Smart Contract.
Dieser Vorfall ist ein weiteres schwerwiegendes Versagen der operationellen Sicherheit, nur 10 Tage nach dem Resolv-Angriff. Der Zusammenbruch von Resolv war darauf zurückzuführen, dass es keine Multi-Signatur-Mechanismen gab; während Drift zwar über Multi-Signatur verfügte, jedoch aufgrund von zu niedrigen Schwellenwerten und mangelnden zusätzlichen Sicherheitsmechanismen ebenfalls versagte. Diese beiden Vorfälle verdeutlichen, dass ein grundlegendes Redesign der privilegierten Architektur dringend erforderlich ist.
Ereignisübersicht
Quelle: @DriftProtocol
Am 1. April 2026 um 16:05 (UTC-Zeit) wurde das führende dezentrale Handelsprotokoll Drift auf Solana von einem großflächigen Angriff heimgesucht. Drift ist ein Protokoll, das Hebelhandel, Spot-Handel, Kredite und andere dezentrale Finanzdienstleistungen anbietet, dessen Architektur eine Kombination aus virtuellen automatisierten Market Makern und On-Chain-Orderbüchern ist. Kurz vor dem Angriff betrug der gesamte gesperrte Wert des Protokolls etwa 309 Millionen USD.
Quelle: @PeckShieldAlert
Etwa um 18:10 (UTC-Zeit), also ungefähr zwei Stunden nach Beginn des Angriffs, veröffentlichte das Drift-Team auf der Plattform X einen Beitrag, in dem die Benutzer aufgefordert wurden, Einzahlungen auszusetzen. Anschließend bestätigte das Team den Angriff und stellte alle Einzahlungs- und Abhebungsfunktionen ein. Mehrere Sicherheits- und On-Chain-Analysefirma, einschließlich PeckShield und Lookonchain, schätzten den Verlust auf etwa 285 Millionen USD. Die Phantom-Wallet ergriff schnell Maßnahmen und sperrte den Zugriff auf das Protokoll.
Dieser Vorfall erregte besondere Aufmerksamkeit, da er nur 10 Tage nach dem Resolv-Angriff stattfand und zu einem weiteren großflächigen Leak von Administratorschlüsseln innerhalb kurzer Zeit wurde. Beide Vorfälle haben gemeinsame Wurzeln: Die Grundursache liegt nicht in einem Fehler im Code des Smart Contracts, sondern in einem Versagen der operationellen Sicherheit.
Ursachenanalyse
Der Kern dieses Angriffs liegt darin, dass die Angreifer die kompromittierten Administratorrechte zur Manipulation der Sicherheiten ausnutzten. Während der Resolv-Vorfall als "Offenlegung eines Schlüssels mit Minting-Rechten" betrachtet werden kann, stellt der Drift-Vorfall "Offenlegung eines Schlüssels mit Markteinführungs- und Sicherheitskonfigurationsrechten" dar. Die Ausprägungen beider Vorfälle sind unterschiedlich, aber die Wurzeln sind identisch. Im Folgenden wird der Angriffsprozess schrittweise analysiert.
Quelle: Dexscreener
Das direkteste Werkzeug des Angriffs war der CarbonVote Token (CVT), ein Token mit sehr geringer Liquidität. Eine der Adressen, die von den Angreifern kontrolliert wurde (FnYXwy...LpAjjx), gab diesen Token drei Wochen vor dem Angriff aus. Die Gesamtversorgung von CVT beträgt etwa 750 Millionen, wobei die Wallet der Angreifer mehr als 80 % hält. Die Angreifer schufen auf Raydium einen minimalen Liquiditätspool im Wert von etwa 500 USD und führten dann kontinuierliche Handelsvolumina durch.
Die initializeSpotMarket-Funktion im Drift-Protokoll erlaubt es Administratoren, die Oracle-Adresse und deren Parameterquelle direkt anzugeben. Eine Überprüfung der Konfiguration des Software Development Kits für die bestehenden Spotmärkte zeigt, dass jeder Markt separat die Oracle, die Quelle der Oracle und die Felder für die Token-Prägung definiert. Das bedeutet, dass selbst Token wie CVT, die keinen Pyth-Preis haben, wenn die Angreifer die Administratorrechte erhalten, beliebige Oracle-Quellen nutzen können, um sie als Markt einzuführen.
In diesem Angriff wies der Angreifer dem CVT-Markt einen Switchboard-Preis als Oracle zu. Switchboard ist ein Oracle-Netzwerk, das die Erstellung benutzerdefinierter Preise relativ einfach macht. Die Angreifer konfigurierten einen von ihnen kontrollierten Preis, der den Wert von 785 Millionen CVT auf mehrere Hundert Millionen USD festlegte. Preisverfolgungsplattformen wie Dexscreener zeigen einen Preis von etwa 1 USD für CVT an, aber dessen tatsächliche Marktliquidität und innerer Wert sind nahezu null.
Die im Angriff verwendete Wallet (HkGz4K...ovpZES) war etwa acht Tage zuvor, am 24. März, erstmals aktiv. Diese Wallet hatte über das NEAR-Protokoll beabsichtigt, eine Vorabaufladung zu erhalten, und die On-Chain-Aufzeichnungen zeigen, dass diese Wallet bis zum Tag des Angriffs insgesamt 325 Transaktionen durchgeführt hat.
Die On-Chain-Aktivitätsgeschichte des am Angriffstag verwendeten Administratorsignierers (H7PiGq...y7ZgL) ist ebenfalls bemerkenswert. Dieser Schlüssel verzeichnete insgesamt nur 29 Transaktionen. Die erste Transaktion fand am 31. März um 15:05 (UTC-Zeit) statt, also am Tag vor dem Angriff; die letzte Transaktion fand am 1. April um 18:05 (UTC-Zeit) statt, also am Tag des Angriffs. Die gesamte On-Chain-Präsenz dieses Schlüssels dauerte etwa 27 Stunden. Der Grund dafür ist in den On-Chain-Aufzeichnungen klar zu erkennen.
Die Administratorrechte des Drift-Protokolls werden nicht von einem einzelnen externen Konto verwaltet, sondern durch ein Multi-Signatur-System ermöglicht. Die späteren Untersuchungen enthüllten jedoch, dass der Angriffsweg viel komplexer war als ein einfacher Multi-Signatur-Einbruch. Etwa neun Tage vor dem Angriff erstellten die Angreifer vier persistenten Zufallszahl-Konten. Zwei davon waren mit den Signierern des Drift-Sicherheitskomitees verbunden, die anderen beiden wurden von den Angreifern kontrolliert. Persistente Zufallszahlen sind ein Mechanismus auf Solana, der es ermöglicht, die etwa einminütige Gültigkeitsdauer des Block-Hashes in normalen Transaktionen zu umgehen, was es ermöglicht, Unterschriften im Voraus zu sammeln und später auszuführen. Es wird angenommen, dass die Angreifer diesen Mechanismus ausnutzten, um durch irreführende Transaktionsinhalte vorab unterschriebene Dokumente von legitimen Signierern zu erhalten.
Vier Tage später führte das Drift-Team aufgrund von Änderungen der Mitglieder des Sicherheitskomitees eine geplante Multi-Signatur-Übertragung durch. Diese Übertragung war Teil eines regulären Betriebsprozesses, aber die Angreifer passten sich erfolgreich an diese Veränderung an.
Am Tag vor dem Angriff erstellten die Angreifer ein neues persistenten Zufallszahl-Konto für einen der Signierer im nach der Migration aktualisierten Multi-Signatur (6UJbu9...Pvu924). Zu diesem Zeitpunkt hatten die Angreifer bereits den effektiven Zugriff auf zwei Fünftel der Signierer im aktualisierten Multi-Signatur wiedererlangt. Dies zeigt, dass die Angreifer tief in das System eingedrungen sind und sogar in der Lage sind, mit unerwarteten Änderungen wie der Multi-Signatur-Migration umzugehen.
Am Tag des Angriffs führte das Drift-Team einen routinemäßigen Testabzug aus dem Versicherungstopf durch. Etwa eine Minute später führten die Angreifer schnell zwei vorab signierte Transaktionen mit persistenten Zufallszahlen aus.
Quelle: solscan
Die erste Transaktion führte die Befehle VaultTransactionCreate, ProposalCreate und ProposalApprove in der Multi-Signatur Squads aus, schuf einen bösartigen Vorschlag zur Übertragung der Administratorrechte und zeichnete die erste Genehmigung auf.
Unmittelbar danach führte die zweite Transaktion mithilfe der persistente Zufallszahlen die Befehle ProposalApprove und VaultTransactionExecute aus. Der Schwellenwert von zwei Fünfteln wurde sofort erreicht, und da die Zeitverriegelung auf null Sekunden eingestellt war, wurde die Transaktion sofort ausgeführt. Zu diesem Zeitpunkt wurde der Befehl UpdateAdmin im Drift V2-Programm aufgerufen, um die Administrationsadresse an den Angreifer (H7PiGq...y7ZgL) zu übertragen.
Der entscheidende Punkt hier ist, dass beide Transaktionen zuvor vollständig unterzeichnet wurden und am Tag des Angriffs in großen Mengen eingereicht wurden. Zu diesem Zeitpunkt hatten die Signierer wahrscheinlich nicht vollständig verstanden, was sie unterzeichneten. Der Begriff "Transaktionsmissverständnis", den das Drift-Team verwendet, deutet darauf hin, dass die Signierer dazu verleitet wurden, eine böswillige Übertragungs-Transaktion zu unterzeichnen, die sich als Routinebetrieb tarnte. Die Rolle der persistenten Zufallszahlen besteht darin, diese Vorab-Unterschriften unbegrenzt zu speichern, sodass die Angreifer sie zu einem von ihnen gewählten Zeitpunkt ausführen können.
Der ersetzte Administrator-Signierer rief anschließend das Drift V2-Programm (dRifty...cn33UH) auf und führte zwei Operationen aus.
Quelle: solscan
Erstens registrierten die Angreifer durch den Befehl initializeSpotMarket den CVT als neuen Spotmarkt auf Drift. Dabei wurde ein neues Spotmarkt-Konto (BY3WYn...FVU1Cf) und zwei CVT-Token-Konten erstellt, und die abgeleitete Adresse des Drift-Tresorprogramms (PDA, JCNCMF...XXJfrw) wurde als Token-Eigentümer festgelegt.
Drift betreibt ein Multi-Asset-Collateral-System, was bedeutet, dass Token, die auf dem neuen Spotmarkt registriert sind, sofort als Sicherheiten verwendet werden können. Damit sie als qualifizierte Sicherheiten gelten, müssen die Parameter initial_asset_weight und maintenance_asset_weight des Marktes auf positive Werte größer als null eingestellt werden, während die Standardinitialwerte niedrig oder nah an null sind. Die Analyse der Angriffs-Transaktion (4a5962R...st82X) zeigt, dass updateSpotMarketMarginWeights (oder die äquivalente Aktualisierung der Risikoparameter) mit initializeSpotMarket in derselben Transaktion gebündelt ausgeführt wurde, wobei die Angreifer das Sicherheitengewicht von CVT auf den maximalen Wert setzten.
Dies offenbarte einen entscheidenden Designfehler aus der Perspektive der tiefen Verteidigung: Die Operationen wie Markteinführung, Angabe der Oracle-Quelle, Konfiguration des maximalen Sicherheitengewichts und Deaktivierung des Abhebungsschutzes können alle in einer einzigen Transaktion abgeschlossen werden. Der Gewichtungsrabattfaktor, der zur Verhinderung von konzentrierten Risiken bei großen Positionen dient, verliert seine tatsächliche Wirksamkeit, nachdem das Gewicht selbst auf den maximalen Wert gesetzt wurde. Wäre das Programm mit einer Obergrenze für das Gewicht neuer Märkte oder mit einem separaten Zeitverriegelungsmechanismus für Gewichtungsänderungen ausgestattet gewesen, so wäre dieser einmalige Angriff, der alle Abwehrmaßnahmen zunichte macht, nicht möglich gewesen.
Quelle: solscan
Zweitens riefen die Angreifer in derselben Transaktion fünfmal die updateWithdrawGuardThreshold-Anweisung auf und erhöhten das Abhebungslimit des Hauptvermögensmarktes auf extreme Höhen. Die Limits aller Märkte wurden auf einen einheitlichen Wert von etwa 500 Billionen eingestellt, was praktisch den Schwellenwert des Abhebungsschutzmechanismus ins Unendliche schob und somit die Sicherheitsfunktion zur Verhinderung von abnormal hohen Abhebungen außer Kraft setzte.
Diese Transaktion (4a5962R...st82X) zerstörte gleichzeitig die drei Kernlinien der Verteidigung von Drift.
Erstens wurde das Preismechanismus durch die Zuteilung eines von den Angreifern kontrollierten Switchboard-Preises als Oracle untergraben. Zweitens wurde das Sicherheitengewicht auf den maximalen Wert gesetzt, wodurch ein Token ohne inneren Wert als hochwertige Sicherheit anerkannt wurde. Drittens wurde die Schwelle des Abhebungsschutzmechanismus auf etwa 500 Billionen angehoben, was im Wesentlichen den Abbruchmechanismus für abnormale Abhebungen beseitigte.
Inklusive der Änderungen der Administrationsrechte haben die Angreifer das gesamte Sicherheitsarchitektur des Protokolls mit nur zwei Transaktionen zerstört. Aus der Perspektive der Codeprüfung bringt dies ein tiefes Paradoxon mit sich: Der Contract-Code von Drift funktioniert genau so, wie es die Prüfung bestätigt hat. initializeSpotMarket registrierte das neue Markt gemäß den Vorgaben, wies die Oracle-Quelle zu und stellte die Gewichtungsparameter ein; updateWithdrawGuardThreshold änderte die Limits wie vorgesehen. Die Wurzel des Problems liegt im Design des Systems selbst – das Design erlaubt es, die gesamte Angriffs-Kette in einer einzigen Transaktion abzuschließen. Dies gehört nicht mehr zum Bereich der Codeprüfung, sondern fällt in den Bereich des Design von privilegierten Architekturen und Parameterbeschränkungen.
Letztendlich hinterlegten die Angreifer etwa 785 Millionen CVT als Sicherheiten durch ein neu erstelltes Drift-Nutzerkonto. Der von den Angreifern kontrollierte Switchboard-Preis bewertete diesen Wert auf mehrere Hundert Millionen USD, während das auf den maximalen Sicherheitenwert eingestellte Gewicht nahezu die gesamte Bewertung als gültige Sicherheiten anerkannte. Das Margin-System von Drift funktioniert genau wie vorgesehen. Das Problem liegt darin, dass jeder Parameter, der in dieses System eingegeben wurde, von den Angreifern böswillig manipuliert wurde.