Können Sie sich gegen Hacks schützen? - Die wichtigsten Erkenntnisse aus dem Livestream von Certora über sich entwickelnde Bedrohungen und was Protokolle als nächstes tun müssen

Wenn Sie jemals in der Angst gelebt haben, gehackt und Ihre Gelder von einem böswilligen Akteur abgeschöpft zu werden, hat das führende Blockchain-Sicherheitsunternehmen Certora versucht, diese Ängste am Donnerstag, den 12. Februar, durch einen Livestream mit dem Titel "How DeFi Hacks Have Changed in the Last 5 Years and What This Means for Protocols" zu lindern.

Seth Hallem, CEO von Certora, analysierte zusammen mit Ofek Ray Orlev, einem leitenden Sicherheitsforscher und Teamleiter des Unternehmens, wie sich moderne Angriffe von früheren DeFi-Exploits unterscheiden und was Protokollteams als Reaktion darauf tun sollten.

Seth kam vor acht Monaten zu Certora, nachdem er eine Karriere in statischer Analyse, Softwarequalität und Cybersicherheit aufgebaut hatte. Er wendet diese Erfahrung nun auf Web3 und DeFi an. Ofek bringt zwölf Jahre Erfahrung in der Schwachstellenforschung in offensiven und defensiven Bereichen mit. Bevor er vor zwei Jahren in die DeFi-Branche einstieg, leitete er Red Teaming und Penetrationstests bei Intel, wo er sowohl offensive als auch defensive Tools für eingebettete Systeme entwickelte.

Die Diskussion konzentrierte sich nicht auf bekannte Hacks, sondern auf zwei aktuelle und ausgefeilte Angriffe. Der erste, CPIMP, steht für Clandestine Proxy In The Middle of Proxy. Der zweite, GlassWorm, ist der erste sich selbst verbreitende Krypto-Wurm, der die NPM- und OpenVSX-Lieferkette angreift. Zusammen veranschaulichen diese Angriffe, wie sich die DeFi-Sicherheit von offensichtlichen Fehlern zu systemischen, geduldigen und vielschichtigen Kampagnen entwickelt hat.

Clandestine Proxy In The Middle of Proxy (CPIMP)-Angriff

Der CPIMP-Angriff nutzt Proxy-Initialisierungsmuster in Smart Contracts aus. Im Kern greift der Angriff die Initialisierungsphase eines Proxy-Vertrags an. Wenn ein Angreifer den ersten Initialisierungsaufruf vorwegnimmt, kann der Angreifer den Proxy mit einer bösartigen Implementierung initialisieren.

Was CPIMP besonders bemerkenswert macht, ist nicht nur seine anfängliche Etablierung, sondern auch die anschließende Persistenz und Heimlichkeit. Der bösartige Proxy imitiert die beabsichtigte Implementierung, so dass alle Tests und normalen Interaktionen weiterhin funktionieren. Entwickler und Benutzer sehen keine offensichtliche Fehlfunktion. Der Angreifer fügt zwischen den legitimen Proxy und die vorgesehene Logik einen heimlichen Proxy ein, der es dem Angreifer ermöglicht, Anrufe abzufangen und zu manipulieren, ohne sofort entdeckt zu werden.

Die böswilligen Akteure haben auch eine Persistenz über Upgrades hinweg entwickelt. Wenn Entwickler den Proxy aktualisieren, um neue Funktionen hinzuzufügen, fügt die bösartige Schicht ihren Code in die neue Implementierung ein. Einmal infiziert, fließt jede nachfolgende Aktualisierung durch die Pipeline des Angreifers. Dieses Design ermöglicht eine langfristige Kontrolle statt eines schnellen Smash-and-Grab-Angriffs.

Die Angreifer nutzten sogar eine Schwachstelle in Etherscan aus, die es ihnen ermöglichte, die angezeigte Implementierungsadresse zu fälschen, indem sie einen veralteten Speicherplatz auffüllten. Externe Beobachter, die sich auf Blockexplorer verlassen, würden die falsche Implementierung sehen, was die Erkennung weiter erschwert.

Seth und Ofek verglichen diesen Ansatz mit einem Rug Pull, betonten aber einen anderen Zeithorizont. Bei einem traditionellen Rug Pull werden die Mittel oft schnell abgezogen. CPIMP scheint darauf ausgelegt zu sein, zu warten, bis ein Protokoll groß genug ist, um eine Aktivierung zu rechtfertigen. Der Angreifer kann das kompromittierte System wie einen ruhenden Vermögenswert behandeln, der mit der Zeit reift. Diese Geduld deutet eher auf eine kampagnenartige Vorgehensweise als auf eine opportunistische Ausnutzung hin.

GlassWorm-Angriff: Extrahieren von privaten Schlüsseln aus 50 Wallet-Erweiterungen

GlassWorm verlagert das Schlachtfeld von der Onchain-Logik auf die Entwicklungslieferkette. Die Angreifer führten eine bösartige VS-Code-Erweiterung ein, die die Rechner der Entwickler infizierte. Sobald die Erweiterung installiert war, extrahierte sie private Schlüssel von etwa fünfzig Wallet-Erweiterungen. Sie suchte auch nach GitHub-Anmeldeinformationen und stellte fest, ob der infizierte Entwickler andere VS-Code-Erweiterungen unterhielt.

Wenn der Entwickler eine Erweiterung veröffentlichte, injizierte der Wurm vor der Verbreitung bösartigen Code in diese Erweiterung. Dieser Verbreitungsmechanismus verwandelte die Malware in einen echten Wurm. Jede neu infizierte Erweiterung verbreitet die Nutzlast weiter und vergrößert ihre Reichweite im gesamten Ökosystem.

Nehmen Sie sich einen Moment Zeit, um diese Informationen zu verstehen. Sie sind ein Entwickler. Ihr Rechner wird infiziert. Wahrscheinlich wird Ihnen das Geld aus der Tasche gezogen. Alle von Ihnen entwickelten Erweiterungen werden infiziert, und jeder, der sie herunterlädt, wird ebenfalls infiziert, und so weiter.

Die Bezeichnung "Glas" bezieht sich auf die Verwendung von nicht druckbaren Zeichen, um bösartigen Code zu verstecken. Die Nutzlast erschien als Leerzeilen oder Leerraum in Editoren. Herkömmliche statische Analysetools konnten den Code nicht erkennen, bevor die Forscher den Angriff identifizierten.

GlassWorm kombinierte bekannte Techniken mit neuen Innovationen. Er verwendete bewährte Strategien zur Kompromittierung der Lieferkette und Methoden zur Extraktion privater Schlüssel. Allerdings führte er einen neuartigen Befehls- und Kontrollmechanismus ein, indem er die Solana-Blockchain nutzte. Der Wurm las verschlüsselte Anweisungen, die in Transaktionsmemofelder eingebettet waren. Da die Angreifer diese Transaktionen mit ihrer eigenen Brieftasche signierten, konnten infizierte Rechner neue Anweisungen überprüfen und ausführen, ohne auf einen herkömmlichen Server angewiesen zu sein.

Diese Onchain-Befehls- und Kontrollstruktur erschwerte die Bekämpfung des Virus erheblich. Strafverfolgungs- oder Sicherheitsteams konnten nicht einfach einen zentralisierten Server beschlagnahmen. Die Angreifer nutzten außerdem die Ereignisthemen von Google Calendar als zusätzlichen Kommunikationskanal. Diese Schichten sorgten für eine Widerstandsfähigkeit und Flexibilität, die Sicherheitsforscher bei früheren Web2-Würmern nur selten beobachten konnten.

Der Wurm installierte außerdem einen versteckten VNC-Client und konfigurierte einen SOCKS-Proxy auf den infizierten Computern. Diese Fähigkeiten deuten darauf hin, dass die Angreifer mehr als nur die Brieftasche leeren wollten. Sie zielten darauf ab, umfassenden Zugang zu den Systemen der Opfer zu erhalten. Der Angriff verwischte die Grenze zwischen Web2 und Web3 und zeigte, dass die DeFi-Sicherheit nicht mehr bei Smart Contracts Halt macht.

Was können Sie tun, um sich selbst zu schützen?

Beide Redner betonten, dass Entwickler keine nihilistische Denkweise annehmen sollten. Perfekte Sicherheit gibt es nicht, aber praktische Verbesserungen reduzieren das Risiko erheblich.

Ofek riet Teams, ihre Toolchains zu überprüfen, unnötige Erweiterungen einzuschränken und Abhängigkeiten auf dem neuesten Stand zu halten. Er forderte die Entwickler auf, wirklich zu verstehen, wie ihre Bereitstellungsprozesse tatsächlich ablaufen.

Er empfahl außerdem eine Überprüfung nach der Bereitstellung. Die Teams sollten die Onchain-Speicherplätze direkt überprüfen und sich nicht nur auf Blockexplorer verlassen. Sie sollten bestätigen, dass keine unerwarteten Delegatecalls oder Initialisierungsschritte aufgetreten sind.

Seth betonte das architektonische Denken. Die Idee, dass eine Browsererweiterung ein sicherer Ort ist, um einen privaten Schlüssel zu entschlüsseln und Transaktionen zu signieren, die Geld bewegen, ist ein fehlerhaftes Konzept, das auf dem falschen Bedrohungsmodell aufbaut", sagte er und argumentierte, dass Browsererweiterungen in hochdynamischen Umgebungen laufen und keine hochwertigen kryptografischen Operationen durchführen sollten. Hardware-Sicherheitsmodule und isolierte Signierumgebungen bieten bessere Garantien.

Mert Mumtaz, CEO von Helius Labs, schloss sich dieser Meinung in einem öffentlichen Beitrag an und schrieb, dass die Idee, dass Geldbörsen Chrome-Erweiterungen sind, eine der fragwürdigsten UX-Entscheidungen der Branche darstellt.

Beide Perspektiven unterstreichen die Notwendigkeit, die Annahmen über die Sicherheit von Geldbörsen zu überdenken, da die Kapitalzuflüsse zunehmen.

Worauf sollten Sie im Jahr 2026 achten?

Mit Blick auf das Jahr 2026 erwarten beide Redner eine verstärkte Beteiligung von Institutionen am Web3. Da Regierungen und große Finanzinstitute eine stärkere Beteiligung in Betracht ziehen, werden die Protokolle strengeren Sorgfalts- und Compliance-Anforderungen unterliegen. Dokumentation, formale Überprüfung, standardisierte Verfahren und kontinuierliche Sicherheitspartnerschaften werden wahrscheinlich zu den grundlegenden Erwartungen gehören.

Auf der offensiven Seite werden Angreifer weiterhin Web2- und Web3-Techniken miteinander vermischen. Da sich die Qualität von Smart Contracts verbessert und Audits immer häufiger werden, werden Angreifer auf Social Engineering, die Exfiltration privater Schlüssel, Frontends, Governance-Prozesse und Lieferketten abzielen. Seth verglich diese Verschiebung mit dem Aufkommen von Ransomware im Web2, nachdem Unternehmen exponierte Dienste gehärtet hatten.

Protokolle sollten erwarten, dass sich Angreifer wie Unternehmen verhalten. Einige Kampagnen werden auf Transaktionsgewinne abzielen, wie z. B. Phishing und das Abziehen von Geldbörsen. Andere werden strategische Möglichkeiten verfolgen, die auf systemische Schwachstellen in Billionen-Dollar-Infrastrukturen abzielen.

Abschließende Überlegungen

Der Livestream hat einen klaren Wandel in der DeFi-Sicherheit aufgezeigt. Frühe Angriffe basierten oft auf offensichtlichen Programmierfehlern. Moderne Angriffe arbeiten mit Geduld, Ausdauer und domänenübergreifender Raffinesse. CPIMP demonstrierte, wie Angreifer sich in Proxy-Architekturen verstecken und darauf warten können, dass sich Werte ansammeln. GlassWorm hat gezeigt, wie sich die Kompromittierung der Lieferkette und die Onchain-Befehls- und Kontrollfunktion über Smart Contracts hinaus auf Entwicklerumgebungen ausdehnen können.

Protokolle können nicht jede zukünftige Technik vorhersagen. Sie können jedoch die Kosten für Angriffe durch eine disziplinierte Architektur, eine sorgfältige Bereitstellung, minimierte Bedrohungsoberflächen und eine kontinuierliche Überprüfung erhöhen. Da das Kapital und die behördliche Kontrolle zunehmen, wird sich die Sicherheit von einer punktuellen Prüfung zu einer kontinuierlichen betrieblichen Anforderung entwickeln.

Lesen Sie mehr über SolanaFloor

Die Zahl der Entwickler auf Solana hat sich seit 2020 fast verzehnfacht, da das Netzwerk im Jahr 2025 rekordverdächtige 3830 neue Entwickler begrüßt.
Solana Perps Scene ist erneut gescheitert, da Trojaner-Terminal anderswo integriert wird

Können Digital Asset Treasuries den Crash überleben?