Nicht nur private Schlüssel: Wie man die Sicherheitsgrenzen von Web3 von Wallets, L2 bis zur Lieferkette schützt?

Wenn Sicherheitsrisiken von einem Punkt zu einer Kette expandieren, muss auch die Verteidigung der Benutzer von der Sicherung des privaten Schlüssels auf ein vollständiges Set von Gewohnheiten aufgerüstet werden.

Verfasser: imToken

Im vergangenen Juni erlebte die Krypto-Welt eine Reihe von Sicherheitsvorfällen, die mehrere Bereiche betrafen.

Der neueste monatliche Sicherheitsbericht von PeckShield zeigt, dass im Juni insgesamt 40 bedeutende Hackerangriffe stattfanden, mit einem Gesamtschaden von bis zu 75,87 Millionen US-Dollar. Besorgniserregend ist, dass diese Angriffe nicht auf einen bestimmten Angriffsweg konzentriert waren, sondern vielmehr Wallet-Signaturfehler, L2-Protokollanfälligkeiten und Angriffe auf die Lieferkette von Drittanbietern abdeckten, wobei mehrere Verteidigungslinien im selben Monat nacheinander versagten.

Als die Sicherheitsrisiken von Web3 von einem einzigen Zugangspunkt auf die gesamte Interaktionskette ausgedehnt wurden, mussten sich alle Benutzer eine Frage neu stellen: Sind meine Krypto-Assets wirklich sicher?

1. Die Bedeutung der Signaturimplementierung auf der Wallet-Ebene über den privaten Schlüssel hinaus

Der Sicherheitsvorfall im Juni bei der Cardano-Ökosystem-Wallet SecondFi ist das anschaulichste Beispiel.

SecondFi ist der Vorgänger der Cardano-Ökosystem-Wallet Yoroi. Vom 21. bis 23. Juni transferierten Angreifer etwa 16 Millionen ADA von den Adressen einiger SecondFi-Nutzer, was etwa 374 Wallets betraf und zum Zeitpunkt des Vorfalls etwa 2,4 Millionen US-Dollar wert war. SecondFi gab anschließend bekannt, dass sie durch Notfallmaßnahmen etwa 129 Millionen ADA, die möglicherweise betroffen waren, zusätzlich geschützt hatten.

Das Besondere an diesem Vorfall ist, dass die betroffenen Benutzer den Seed-Phrase nicht aktiv an die Angreifer übergeben haben; das Problem lag in der Signaturimplementierung auf der Wallet-Ebene. Laut der Analyse der Sicherheitsfirma BlockSec wurde fälschlicherweise der Signatur-Nonce aus öffentlichen Transaktionsnachrichten abgeleitet, wobei das erforderliche geheime Nonce-Präfix weggelassen wurde.

Das bedeutet, dass jedes Mal, wenn Benutzer mit der betroffenen Version der Wallet Transaktionen signieren, die veröffentlichten öffentlichen Signaturdaten auf der Blockchain Informationen offenbaren, die ausreichen, um den privaten Schlüssel der Adresse abzuleiten. Daher müssen Angreifer nicht in das Handy des Benutzers eindringen oder den Seed-Phrase erhalten; sie müssen lediglich die öffentlichen Blockchain-Daten analysieren, um den entsprechenden Signaturprivatschlüssel wiederherzustellen.

Aus der Sicht der Benutzer funktioniert die Wallet weiterhin normal, da der Seed-Phrase nicht in einem Popup angezeigt wird, das Passwort nicht geknackt wurde und die Transaktionen tatsächlich von der betreffenden Person initiiert wurden. Aber aus der Sicht der Kryptographie gilt: Solange die Benutzeradresse mit der betroffenen Version einige gültige Signaturen erzeugt hat, können die öffentlichen Transaktions- und Signaturdaten den Angreifern helfen, den Signaturprivatschlüssel dieser Adresse abzuleiten.

Letztendlich hängt die Sicherheit der Wallet auch davon ab, ob der private Schlüssel korrekt generiert wird, ob die Signatur strikt nach kryptographischen Standards durchgeführt wird und ob dieser kritische Code extern überprüft und validiert werden kann. Dies ist auch der Grund, warum es wichtig ist, dass die Kernkomponenten der Wallet Open Source bleiben.

Natürlich handelt es sich hierbei um einen spezifischen Implementierungsfehler einer bestimmten Wallet-Version und nicht um ein allgemeines Problem aller selbstverwalteten Wallets. Zum Beispiel wird der Kerncode von imTokens TokenCore öffentlich auf GitHub gehostet und deckt grundlegende Wallet-Funktionen wie Schlüsselverwaltung, Adressableitung und Transaktionssignatur ab.

Obwohl Open Source nicht bedeutet, dass der Code zwangsläufig keine Schwachstellen aufweist, noch dass Benutzer ihre Wachsamkeit vollständig aufgeben können, bietet Open Source zumindest eine wichtige Voraussetzung für die sensibelsten kryptographischen und signaturbezogenen Komponenten der Wallet: Sicherheitsforscher, Entwickler und die Community können den Code überprüfen, Probleme reproduzieren und kontinuierlich testen, anstatt nur auf eine nicht verifizierbare Black Box vertrauen zu müssen.

Für normale Benutzer bedeutet dies auch, dass es einige realistischere Sicherheitsprinzipien gibt.

• Zunächst sollte die Wallet immer über die offizielle Website oder den offiziellen App Store heruntergeladen und regelmäßig auf die neueste Sicherheitsversion aktualisiert werden;
• Zweitens sollten nicht alle Vermögenswerte in derselben täglichen Interaktions-Wallet aufbewahrt werden; größere langfristige Vermögenswerte können in Hardware-Wallets oder unabhängigen Cold Wallets gespeichert werden, um sie von der Hot Wallet, die häufig mit DApps verbunden ist, zu isolieren.
• Noch wichtiger ist, dass, wenn die offizielle Wallet bestätigt, dass es eine Schwachstelle bei der Schlüsselgenerierung oder der Signaturimplementierung gibt, das bloße Importieren des ursprünglichen Seed-Phrase in eine andere Wallet normalerweise das Problem nicht löst;

Denn wenn dieselbe Seed-Phrase in andere Wallets importiert wird, ändern sich die bereits exponierten Adressen und privaten Schlüssel nicht. Betroffene Vermögenswerte müssen auf eine neue Adresse übertragen werden, die niemals mit der anfälligen Version signiert wurde; für normale Benutzer ist es in der Regel sicherer, eine völlig neue Wallet und Seed-Phrase gemäß dem offiziellen Notfallprozess zu erstellen und dann die Vermögenswerte zu übertragen, anstatt die ursprüngliche Adresse wiederholt zu importieren oder zu verwenden.

2. L2 ist nicht nur „ein günstigeres Ethereum“, sondern auch eine komplexe Vertrauensschicht

Neben Wallets haben mehrere Vorfälle im Juni auch die Risiken komplexer L2-Systeme aufgezeigt.

Am 14. und 18. Juni wurden zwei veraltete Rollup-Implementierungen, die mit Aztec verbunden sind, angegriffen, was zu einem Gesamtschaden von etwa 4,35 Millionen US-Dollar führte.

Es ist wichtig zu betonen, dass die angegriffenen veralteten Implementierungen wie Aztec Connect nicht mit dem aktuellen Aztec Network Mainnet gleichzusetzen sind, aber die Probleme, die durch diese beiden Vorfälle aufgedeckt wurden, sind für den gesamten Bereich der ZK Rollups von großer Warnung.

In einem der Vorfälle nutzten die Angreifer die Diskrepanz zwischen der Anzahl der Transaktionen und den tatsächlich verarbeiteten Daten aus, um das System dazu zu bringen, einen Einzahlungsnachweis intern zu vermerken, während der entsprechende Saldenabzugsprozess auf L1 umgangen wurde.

Ein anderer Vorfall resultierte aus fehlenden Einschränkungen im Zero-Knowledge-Proof-Zirkel, wobei das System einen formal gültigen Nachweis validierte, jedoch nicht sicherstellte, dass der verwendete private Statusbaum mit dem öffentlichen Statusstamm, der auf Ethereum für die Abrechnung verwendet wird, vollständig übereinstimmte. Daher konnten die Angreifer einen Nachweis um einen gefälschten Statusbaum herum generieren und Vermögenswerte aus dem L1-Vertrag abziehen.

Solche Probleme lassen sich nur schwer mit der traditionellen Frage „Hat der Vertrag eine bestimmte Zeile mit fehlerhaftem Code?“ zusammenfassen. Schließlich kann ein Zero-Knowledge-Beweis beweisen, dass ein bestimmter Berechnungsprozess den festgelegten Regeln entspricht, vorausgesetzt, die Regeln selbst sind korrekt und vollständig. Wenn Entwickler vergessen, eine wichtige Variable einzuschränken, kann der Beweis mathematisch gültig sein, aber dennoch ein Ergebnis beweisen, das nicht mit dem tatsächlichen Abrechnungsstatus übereinstimmt.

Der anschließende Sicherheitsvorfall bei Taiko offenbarte ein weiteres Risiko in der Vertrauenskette von L2.

Am 22. Juni wurde der auf SGX basierende Nachweisvalidierungsprozess von Taiko ausgenutzt, was zu einem Verlust von etwa 1,7 Millionen US-Dollar führte. Laut der Analyse von BlockSec verwendeten Angreifer einen privaten Schlüssel für SGX-Enclaves, der zuvor in einem öffentlichen GitHub-Repository eingereicht wurde, und nutzten die Tatsache aus, dass der Validierungsvertrag auf der Blockchain den DEBUG-Modus Enclave nicht ablehnte, um einen böswilligen Beweiser als legitimes Exemplar zu registrieren.

Die Angreifer fälschten dann den L2-Zustandsnachweis, sodass der Vertrag auf Ethereum einen nicht existierenden L2-Zustand akzeptierte. Letztendlich geschah dies, weil der Schlüssel zur Signatur der vertrauenswürdigen Ausführungsumgebung öffentlich gemacht wurde und die Regeln zur Fernzertifizierung die Eigenschaften der Ausführungsumgebung nicht vollständig überprüften, wodurch ein „zertifizierter“ Nachweis seine ursprüngliche vertrauenswürdige Bedeutung verlor.

Gleichzeitig kam es bei Base vom 25. bis 26. Juni zu einem Stillstand der Blockproduktion im Mainnet. Base gab nachträglich an, dass die beiden Unterbrechungen auf denselben logischen Fehler beim Blockaufbau zurückzuführen waren: Eine fehlgeschlagene Transaktion wurde nicht korrekt bereinigt, was dazu führte, dass nachfolgende Transaktionen falsch berechnet wurden und Blöcke mit ungültigen Statusübergängen erzeugt wurden. Da andere Knoten diesen Block nicht akzeptieren konnten, stoppte das Netzwerk schließlich die weitere Fortschreitung. Base erklärte, dass die Integrität der Blockchain während des Vorfalls nicht beeinträchtigt wurde und die Benutzerfonds stets sicher waren.

Dies war kein Fall von Diebstahl von Vermögenswerten oder externen Angriffen, sondern ein technischer Fehler, der die Verfügbarkeit und Wiederherstellungsfähigkeit des Netzwerks beeinträchtigte. Aus einer breiteren Sicherheitsperspektive ist die Verfügbarkeit selbst auch ein Teil des Sicherheitsmodells von L2.

Denn für die Benutzer hängt die Sicherheit einer Kette nicht nur davon ab, ob Hacker Vermögenswerte fälschen können, sondern auch davon, ob Blöcke kontinuierlich produziert werden, ob Cross-Chain-Brücken ordnungsgemäß funktionieren, ob Knoten schnell wiederhergestellt werden können und ob Benutzer im Falle eines Systemausfalls weiterhin einen praktikablen Ausstieg haben.

Daher sollten Benutzer bei der Nutzung von L2 nicht nur die Transaktionsgebühren und die erwarteten Airdrops vergleichen. Für kleinere, neu gestartete oder sich schnell ändernde Sicherheitsmechanismen von L2 sollten sie versuchen, langfristig keine großen Vermögenswerte über den tatsächlichen Bedarf hinaus zu speichern; vor einer Cross-Chain-Transaktion sollte überprüft werden, ob die offizielle Brücke verwendet wird, und die Abhebungszeiten, Pausenmechanismen und Notausstiegsverfahren sollten bekannt sein; bei Netzwerkstillständen, Cross-Chain-Anomalien oder offiziellen Sicherheitswarnungen sollten keine wiederholten Transaktionen eingereicht oder Vermögenswerte weiter über die Brücke geleitet werden.

Eine sicherere Vorgehensweise besteht darin, Vermögenswerte mit unterschiedlichen Verwendungszwecken und Risikostufen zu diversifizieren, anstatt die gesamte Liquidität auf dasselbe L2, dieselbe Cross-Chain-Brücke oder dasselbe Ausstiegsverfahren zu setzen.

3. Verträge wurden nicht gehackt, aber Drittanbieterdienste können ebenfalls Angriffe auf Benutzer bringen

Wenn die Probleme mit Wallets und L2 immer noch in den eher grundlegenden technischen Komponenten auftreten, zeigt der Vorfall bei Polymarket, dass auch die nächstgelegene Weboberfläche für Benutzer ein Zugangspunkt für Gelder sein kann.

Am 25. Juni gab Polymarket bekannt, dass ein Drittanbieter, den sie verwenden, gehackt wurde, und die Angreifer dadurch bösartige Skripte in die Polymarket-Oberfläche injizierten, auf die einige Benutzer zugreifen konnten.

Laut Sicherheitsbehörden und On-Chain-Analysten führte der Vorfall zu einem Verlust von etwa 3 Millionen US-Dollar an Benutzervermögen, betroffen waren etwa 11 Wallets. Die gestohlenen Gelder wurden anschließend von Polygon über Cross-Chain nach Ethereum transferiert und in etwa 1893 ETH umgewandelt. Polymarket gab jedoch später bekannt, dass sie die betroffenen Abhängigkeiten entfernt hatten und den betroffenen Benutzern eine vollständige Rückerstattung anbieten würden.

Der Schlüssel zu diesem Vorfall liegt darin, dass die Benutzer möglicherweise weiterhin die korrekte Polymarket-Domain aufrufen, die aktuellen Offenlegungen jedoch nicht auf eine Schwachstelle im Kern-Smart-Contract von Polymarket hinweisen; das Problem liegt hauptsächlich in den Abhängigkeiten von Drittanbietern, die auf der Webseite geladen werden.

Dies ist auch ein Spiegelbild der Tatsache, dass die meisten Web3-Anwendungen heutzutage nicht vollständig auf der Blockchain laufen; die Webseiten, die Benutzer sehen, wie Handelsoberflächen, hängen immer noch stark von der traditionellen Internetinfrastruktur und Drittanbieter-Softwarepaketen ab. Wenn eine dieser Abhängigkeiten angegriffen wird, kann dies dazu führen, dass legitime Websites falsche Informationen anzeigen, Zahlungsadressen ersetzen oder Benutzer dazu verleiten, bösartige Transaktionen zu signieren.

Daher bedeutet „Die URL ist echt“ nicht zwangsläufig, dass „alle geladenen Codes zu diesem Zeitpunkt sicher sind“, und „Der Vertrag hat eine Prüfung bestanden“ bedeutet nicht, dass der gesamte Interaktionspfad zwischen dem Benutzer und dem Vertrag risikofrei ist. Angesichts solcher Frontend- und Lieferkettenangriffe ist es für normale Benutzer schwierig, jeden geladenen Code auf der Webseite unabhängig zu überprüfen, aber sie können dennoch potenzielle Verluste durch die Einschränkung der Berechtigungen bei einzelnen Interaktionen minimieren:

• Verwendung einer unabhängigen DApp-Interaktions-Wallet: Langfristige Spar-Wallets sollten möglichst nicht direkt mit verschiedenen DeFi-, NFT-, Prognosemarkt- und Airdrop-Webseiten verbunden werden; tägliche Interaktions-Wallets sollten nur die Mittel enthalten, die kurzfristig verwendet werden sollen, sodass der Einflussbereich im Falle eines Frontend- oder Autorisierungsproblems relativ begrenzt bleibt;
• Vor der Signatur auf die tatsächlichen Aktionen achten, nicht nur auf die Schaltflächen auf der Webseite: Wenn auf der Webseite „Anmelden“, „Abholen“ oder „Bestellung bestätigen“ steht, bedeutet das nicht, dass die Signatur, die in der Wallet erscheint, dasselbe ist;
• Bei ungewöhnlichen Webseiten nicht auf Gewohnheiten vertrauen: Wenn die Seite plötzlich verlangt, den Seed-Phrase erneut zu importieren, zusätzliche Plugins herunterzuladen oder wenn die angezeigten Transaktionsinhalte nicht mit der Webseitenbeschreibung übereinstimmen, sollte die Interaktion pausiert werden, die Situation über mehrere offizielle Kanäle des Projekts bestätigt werden und nicht mehr verwendete historische Autorisierungen überprüft oder widerrufen werden;

Aus der Perspektive der Wallet-Produkte bedeutet dies auch, dass sich die Rolle der Wallet verändert.

Sie sollte nicht nur ein Werkzeug zum Speichern privater Schlüssel und zum Anzeigen von Signaturfenstern sein, sondern auch den Benutzern helfen, die Transaktionsabsicht zu verstehen, ungewöhnliche Autorisierungen zu erkennen, Veränderungen der Vermögenswerte anzuzeigen und vor risikobehafteten Interaktionen ausreichend klare Warnungen zu geben.

Aber die Wallet kann nicht alle Risiken für die Benutzer beseitigen. Ein realistischeres Sicherheitsmodell besteht darin, dass Wallets, Protokolle, L2, Drittanbieterdienste und Benutzer gemeinsam die Angriffsfläche verringern, anstatt die gesamte Verantwortung auf eine Partei zu schieben.

Abschließend

Früher sagte man oft: Wer den privaten Schlüssel hat, hat die On-Chain-Vermögenswerte.

Dieser Satz gilt immer noch, deckt jedoch nicht den gesamten Prozess ab, den Benutzervermögen vom „Erzeugen einer Transaktionsabsicht“ bis zur „Abwicklung auf der Blockchain“ durchlaufen. Die Sicherheit von Web3 heute besteht nicht nur darin, eine Gruppe von Seed-Phrasen zu schützen, sondern den gesamten Weg vom Generieren von Schlüsseln in der Wallet, dem Anzeigen von Transaktionen, dem Ausführen von Signaturen bis zur Netzwerkvalidierung und der endgültigen Abwicklung zu schützen.

Natürlich bedeutet dies nicht, dass Benutzer alle Interaktionen auf der Blockchain meiden sollten. Für Benutzer bedeutet eine wirklich effektive Sicherheitsgewohnheit, dass sie die Verwendung von Vermögenswerten, Risikostufen und Interaktionsszenarien getrennt verwalten: Langfristige Vermögenswerte stark isolieren, tägliche Interaktionen mit kleinen Beträgen, unbekannte DApps mit niedrigen Berechtigungen und risikobehaftete Operationen mehrfach verifizieren.

Schließlich, wenn Sicherheitsrisiken von einem Punkt zu einer Kette expandieren, muss auch die Verteidigung der Benutzer von der Sicherung des privaten Schlüssels auf ein vollständiges Set von Gewohnheiten aufgerüstet werden.

Lassen Sie uns gemeinsam daran arbeiten.