Zurück zum Blog

Sicherheitsprüfung: Halten EVM-kompatible Chains dem stand?

Code Auditing
4. Januar 2024
6 Min. Lesezeit

Im November 2023 wurde Professor Zhou Yajin, CEO von BlockSec, eingeladen, am ersten Web3 Scholars Summit teilzunehmen, der vom DRK Lab ausgerichtet wurde. Während der Konferenz teilte Professor Zhou die Arbeit und die Erfolge von BlockSec bei der Erkennung von Schwachstellen in der EVM (Ethereum Virtual Machine). Er stellte zudem das automatisierte Differenzial-Fuzzing-Tool von BlockSec vor, das speziell für die Sicherheit von EVM-kompatiblen Chains entwickelt wurde. Dieser Artikel fasst den Inhalt seines Vortrags zusammen.

Einleitung

Laut den Datenstatistiken von Defillama gibt es derzeit 238 L1- und L2-Public-Chains, von denen 144 EVM-kompatibel sind. Es stellt sich jedoch die Frage: Haben diese EVM-kompatiblen Chains bei ihrer Implementierung Sicherheitsprobleme? Nach unseren Recherchen lautet die Antwort: Ja. Als Reaktion auf diese Bedenken hat BlockSec ein automatisiertes Differenzial-Fuzzing-Sicherheitstool auf den Markt gebracht. Begleiten Sie uns auf eine Reise, um die Wahrheit hinter diesen EVM-kompatiblen Chains zu erforschen.

Schwachstellen in virtuellen Maschinen

Abbildung 1: Diagramm des Arbeitsablaufs der Ethereum Virtual Machine (EVM)
Abbildung 1: Diagramm des Arbeitsablaufs der Ethereum Virtual Machine (EVM)

Am Beispiel der Ethereum Virtual Machine (EVM): Sie verwendet eine stapelbasierte Architektur, die Virtual ROM, Programmzähler, Stack, Arbeitsspeicher und den World State (persistent) umfasst.

Eine virtuelle Maschine fungiert als Engine, die den kompilierten Binärcode von Smart Contracts interpretiert und ausführt. Die Kernkomponente vieler Blockchain-Plattformen ist die virtuelle Maschine, wobei die Ethereum Virtual Machine (EVM) besonders bemerkenswert ist. Daher spielt die virtuelle Maschine eine Schlüsselrolle bei der Ausführung von Smart Contracts, der Verarbeitung von Transaktionen und der Gewährleistung der Integrität der Blockchain.

Wir wissen, dass die EVM selbst auch ein Softwareprogramm ist, das von Programmierern geschrieben wurde. Aber wie können wir sicherstellen, dass die EVM frei von Problemen ist? Schließlich sind Fehler in jedem von Menschen geschriebenen Code möglich.

Und sobald ein Fehler in der EVM auftritt, hat dies katastrophale Folgen für das Ökosystem auf der Blockchain. Tatsächlich ist die EVM in der Vergangenheit auf viele schwerwiegende Schwachstellen gestoßen.

So gab es beispielsweise im Jahr 2020 einen Schwachstellenvorfall, der durch einen vorkompilierten Vertrag verursacht wurde (d. h. CVE-2020-26241) [1]. Der vorkompilierte Vertrag dataCopy in Geth (unter 0x00...04) führte beim Aufruf eine flache Kopie (Shallow Copy) durch, bei der beim Kopieren einer großen Datenmenge nur die Zeiger und nicht die vollständigen Daten kopiert wurden. Dies ermöglichte es bösartigen Smart Contracts, Daten zu ändern, die nicht hätten geändert werden dürfen, was zu Dateninkonsistenzen führte, wenn verschiedene Versionen der virtuellen Maschine denselben Smart Contract ausführten. Ein weiteres Beispiel ereignete sich im Jahr 2021, als bestimmte EVM-kompatible Chains kein Upgrade gemeinsam mit Ethereum durchführten. In älteren Versionen von Geth gab es eine Schwachstelle (CVE-2021-39137) [2], bei der sich die Speicherbereiche für Eingabe- und Ausgabedaten bei vorkompilierten Vertragsaufrufen überschnitten. Angreifer nutzten diese Schwachstelle aus, was zu einem Chain-Fork führte.

Gegenmaßnahmen von BlockSec

Wie entdeckt man Schwachstellen in der EVM rechtzeitig? Was sind die Herausforderungen?

  1. Erstens ist es aufgrund der komplexen Struktur der virtuellen Maschine schwierig, Tools zu finden, die ihre Betriebslogik vollständig verstehen können. Jedes Fachgebiet erfordert Spezialisierung; viele Entwickler können möglicherweise nicht genügend Aufwand betreiben, um die Betriebslogik zu verstehen und wirksame Vorsichtsmaßnahmen zu treffen.

  2. Zudem passen viele neue L1/L2-Public-Chains die EVM-virtuelle Maschine an, was potenziell neue Sicherheitsprobleme einführen kann.

Es ist eindeutig schwierig, sich bei der Identifizierung dieser Probleme in der EVM-virtuellen Maschine allein auf manuelle Audits zu verlassen.

Anpassen und entsprechend reagieren! Angesichts dieser Herausforderungen hat BlockSec ein automatisiertes System entwickelt, um diese Probleme direkt anzugehen!

Differenzial-Fuzzing

Bei BlockSec setzt unser Expertenteam einen cleveren Ansatz ein, der als Differenzial-Fuzzing bekannt ist. Indem wir dieselben Testfälle auf verschiedenen Versionen der virtuellen Maschine ausführen und die Ergebnisse vergleichen, können wir potenzielle Schwachstellen und Inkonsistenzen aufdecken. Diese Methode ermöglicht es uns, subtile Unterschiede effektiv zu identifizieren, die herkömmliche Testmethoden möglicherweise übersehen, wodurch die Gesamtsicherheit des Systems verbessert wird.

Abbildung 2: Arbeitsablauf des Differenzial-Fuzzings
Abbildung 2: Arbeitsablauf des Differenzial-Fuzzings

Grundlegendes Funktionsprinzip:

Um Differenzial-Fuzzing durchzuführen, müssen wir identische Eingaben als Testfälle vorbereiten. Diese Testfälle werden dann in die Differenzial-Fuzzing-Engine eingespeist. Durch den Vergleich der Ergebnisse der Ausführung derselben Testfälle auf verschiedenen Versionen der virtuellen Maschine können wir potenzielle Probleme identifizieren.

Spezifische Implementierungsschritte:

Der Testfall für Differenzial-Fuzzing muss aus zwei Teilen bestehen: Transaktionsmetadaten und Pre-State. Aber wie generieren wir diese Transaktionen? Wir haben zwei Ansätze, um diese Herausforderung zu meistern.

  1. Wiederverwendung historischer Transaktionen: Wir können die historischen Transaktionen abrufen, die auf der Blockchain stattgefunden haben, und sie durch verschiedene Versionen der virtuellen Maschine in der Differenzial-Fuzzing-Engine laufen lassen. Das alleinige Verlassen auf diese Methode hat jedoch Einschränkungen. Historische Transaktionen sind tendenziell zu "normal", während Sicherheitstests das Aufdecken von Grenzfällen erfordern – den außergewöhnlichen Szenarien. Deshalb haben wir uns einen zweiten Ansatz überlegt.
  2. Coverage-Guided Fuzzing: Wir generieren ungewöhnlichen Bytecode und historisch ungesehene Transaktionen von Grund auf, mutieren dann die Transaktionen und den Smart-Contract-Code und geben sie in die virtuelle Maschine ein. Wir stellen die Validität und Vollständigkeit der Testfälle aus verschiedenen Dimensionen sicher.

Sobald diese Transaktionen generiert sind, werden sie in die Differenzial-Fuzzing-Engine eingespeist und die Ergebnisse dann verglichen.

Der Vergleich der Ergebnisse ist nicht nur ein einfacher numerischer Vergleich, sondern berücksichtigt auch umfassend die Datenkonsistenz sowohl im persistenten als auch im nicht-persistenten Speicher der virtuellen Maschine. Dieser Artikel wird dies nicht weiter vertiefen.

Fallstudie

Abbildung 3: Ein Beispiel für das Problem des vorkompilierten Vertrags *ModExp* in der Aurora VM
Abbildung 3: Ein Beispiel für das Problem des vorkompilierten Vertrags ModExp in der Aurora VM

Ich möchte einen Fall einer Schwachstelle in einer virtuellen Maschine teilen, den wir durch Differenzial-Fuzzing in der Aurora VM entdeckt haben. Konkret bezieht er sich auf ein Problem mit dem vorkompilierten Smart Contract ModExp.

Bei der Berechnung der modularen Exponentiation einer Zahl x hoch y wissen wir, dass dieser Vorgang Rechenressourcen erfordert. In einer korrekten Implementierung berücksichtigt die Gas-Berechnung die Anzahl der Iterationen, da die modulare Exponentiation mehrere Iterationen umfasst. Es gibt jedoch ein spezifisches Szenario, in dem die Gas-Berechnung auf ein Problem stoßen kann: wenn der Exponent y gleich 0 ist, was einen Potenzvorgang nullter Ordnung anzeigt. In diesem Fall wird die Anzahl der Iterationen null, was zu einem extrem kleinen Gas-Wert führt. Tatsächlich erfordert die Berechnung jedoch immer noch Ressourcen.

Fazit

Derzeit unterstützt das von BlockSec eingeführte Differenzial-Fuzzing-Tool die Ausführung in den Umgebungen verschiedener Blockchain-virtueller Maschinen, darunter rbpf, ubpf, Aurora-engine, neon-evm, Moonbeam, revm, EvmOS, fevm und Polygon-zkevm, mit kontinuierlicher Erweiterung.

Mit diesem Tool haben wir 14 neue Schwachstellen entdeckt, 2 CVEs beantragt: CVE-2021–46102 und CVE-2022–23066, und über 1,3 Millionen US-Dollar an Bug Bounties erhalten.

Derzeit wird die umfassende Sicherheitslösung für EVM-Chains von BlockSec (Audit-Dienste + Differenzial-Fuzzing-Tools) von EOS und FileCoin anerkannt und genutzt und wird zur Sicherheit und gesunden Entwicklung ihrer Ökosysteme beitragen.

Referenzen

[1] Shallow copy in the 0x4 precompile could lead to EVM memory corruption

[2] RETURNDATA corruption via datacopy

Über BlockSec

BlockSec ist ein wegweisendes Blockchain-Sicherheitsunternehmen, das 2021 von einer Gruppe weltweit anerkannter Sicherheitsexperten gegründet wurde. Das Unternehmen engagiert sich für die Verbesserung der Sicherheit und Benutzerfreundlichkeit für die aufstrebende Web3-Welt, um deren Massenadoption zu erleichtern. Zu diesem Zweck bietet BlockSec Sicherheitsaudit-Dienste für Smart Contracts und EVM-Chains, die Phalcon-Plattform für Sicherheitsentwicklung und proaktive Bedrohungsabwehr, die MetaSleuth-Plattform für die Verfolgung und Untersuchung von Geldern sowie die MetaDock-Erweiterung für Web3-Entwickler, um effizient in der Kryptowelt zu navigieren.

Bis heute hat das Unternehmen über 300 geschätzte Kunden wie MetaMask, die Uniswap Foundation, Compound, Forta und PancakeSwap betreut und zweistellige Millionenbeträge in US-Dollar in zwei Finanzierungsrunden von renommierten Investoren erhalten, darunter Matrix Partners, Vitalbridge Capital und Fenbushi Capital.

✉️Geschäftliche Beratung:[email protected]

Twitter-Account von BlockSec: https://twitter.com/BlockSecTeam

Twitter-Account von Phalcon: https://twitter.com/Phalcon_xyz

Für die neuesten Informationen anmelden
Verluste von rund 3,87 Millionen USD: Hacks bei Autheo Network und UNCX | BlockSec Weekly
Security Insights

Verluste von rund 3,87 Millionen USD: Hacks bei Autheo Network und UNCX | BlockSec Weekly

Dieser Wochenbericht behandelt 3 Sicherheitsvorfälle im Zeitraum 12.10.2026–18.10.2026 mit einem geschätzten Gesamtschaden von etwa 3,87 Millionen USD. Bei Autheo Network wurde ein privater Schlüssel kompromittiert; der Schaden betrug rund 1,76 Millionen USD. Qubic Wallet verlor aufgrund einer schwachen Seed-Generierung rund 1,30 Millionen USD. Bei den Smart Token Vesting V2-Verträgen von UNCX Network führte ein Buchführungsfehler auf Ethereum, BNB Chain, Base und Robinhood Chain zu einem Schaden von rund 807 Tausend USD. Die hervorgehobene Analyse zu UNCX erklärt, wie eine fehlerhafte Berechnung der Gesamtanteile Vesting-Tranchen zusammenführte, die mit unterschiedlichen Token-zu-Anteil-Verhältnissen erstellt worden waren, und dadurch überhöhte Entnahmen aus gemeinsamen Pools ermöglichte.

Rund 542.000 $ verloren: MakerDaoBot-Exploit | BlockSec Wochenrückblick
Security Insights

Rund 542.000 $ verloren: MakerDaoBot-Exploit | BlockSec Wochenrückblick

Ethereum, 5.–11.10.2026: 1 Vorfall, ca. 542.000 $ Verlust. Über eine ungeschützte MakerDaoBot-Funktion erhielt ein bösartiger Adapter Zugriff auf Bot-Guthaben, wickelte 4 ETH-A-Auktionen ab und tauschte 200 ETH-A in WETH; 200 ETH gingen an den Angreifer.

~418 Mio. $ verloren: Bitget- und NEAR-Intents-Exploits | BlockSec Weekly
Security Insights

~418 Mio. $ verloren: Bitget- und NEAR-Intents-Exploits | BlockSec Weekly

Dieser 14-tägige Sicherheitsbericht (21.9.–4.10.26) erfasst 8 Vorfälle mit ca. 418,4 Mio. USD Verlust auf Ethereum, BNB Chain, Solana u.a. Bitget: 387,5 Mio. USD Lücke in Drittprodukt. NEAR Intents: 3,87 Mio. USD Rückerstattungsfehler, fehlender Rollback

Der beste Sicherheitsauditor für Web3

Lassen Sie Design, Code und Geschäftslogik vor dem Launch prüfen. Nach den höchsten Sicherheitsstandards der Branche.

BlockSec-Audit
Sicherheitsprüfung: Halten EVM-kompatible Chains dem stand?