Back to Blog

Sicherheitscheck: Halten EVM-kompatible Ketten stand?

Code Auditing
January 4, 2024
6 min read

Im November 2023 wurde Professor Zhou Yajin, CEO von BlockSec, eingeladen, am ersten Web3 Scholars Summit teilzunehmen, der von DRK Lab veranstaltet wurde. Während der Konferenz teilte Professor Zhou die Arbeit und Erfolge von BlockSec bei der Erkennung von Schwachstellen in der EVM (Ethereum Virtual Machine) mit. Er stellte auch das automatisierte differenzielle Fuzzing-Tool von BlockSec vor, das speziell zur Gewährleistung der Sicherheit EVM-kompatibler Chains entwickelt wurde. Dieser Artikel fasst den Inhalt des Vortrags zusammen.

Einleitung

Laut den Datenerhebungen von Defillama gibt es derzeit 238 L1- und L2-Public-Chains, von denen 144 EVM-kompatibel sind. Es stellt sich jedoch die Frage: Weisen diese EVM-kompatiblen Chains während ihrer Implementierung Sicherheitsrisiken auf? Nach unserer Recherche lautet die Antwort bejahend. Als Reaktion auf dieses Problem hat BlockSec ein automatisiertes differenzielles Fuzzing-Sicherheitstool auf den Markt gebracht. Begleiten Sie uns auf einer Reise, um die Wahrheit hinter diesen EVM-kompatiblen Chains zu entdecken.

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) wird eine stackbasierte Architektur verwendet, die Virtual ROM, Program Counter, Stack, Memory und World State (persistent) umfasst.

Eine virtuelle Maschine fungiert als Motor, der 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 hervorzuheben 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 ein von Programmierern geschriebenes Programm ist. Wie können wir jedoch sicherstellen, dass die EVM fehlerfrei ist? Schließlich können in jedem von Menschen geschriebenen Code Fehler auftreten.

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

Beispielsweise gab es im Jahr 2020 einen Schwachstellenvorfall, der durch einen vorkompilierten Vertrag verursacht wurde (d. h. CVE-2020-26241) [1]. Der dataCopy vorkompilierte Vertrag in Geth (unter der Adresse 0x00...04) führte beim Aufruf eine flache Kopie durch, wobei beim Kopieren großer Datenmengen nur die Zeiger und nicht die vollständigen Daten kopiert wurden. Dies ermöglichte es böswilligen 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 nicht zusammen mit Ethereum aktualisiert wurden. In älteren Versionen von Geth gab es eine Schwachstelle (CVE-2021-39137) [2], bei der sich die Speicherbereiche für Eingabe- und Ausgabedaten bei Aufrufen vorkompilierter Verträge überschnitten. Angreifer nutzten diese Schwachstelle aus, was zu einer Chain-Fork führte.

Gegenmaßnahmen von BlockSec

Wie lassen sich Schwachstellen in der EVM rechtzeitig erkennen? Was sind die Herausforderungen?

  1. Erstens ist es aufgrund des komplexen Designs der virtuellen Maschine schwierig, Tools zu finden, die ihre operative Logik vollständig erfassen können. Jeder Fachbereich erfordert Spezialisierung, viele Entwickler können möglicherweise nicht genügend Aufwand investieren, um die operative Logik zu verstehen und wirksame Vorsichtsmaßnahmen zu treffen.

  2. Darüber hinaus passen viele neue L1/L2-Public-Chains die EVM-virtuelle Maschine an, was potenziell neue Sicherheitsprobleme mit sich bringen kann.

Es ist klar, dass es schwierig ist, sich ausschließlich auf manuelle Audits zu verlassen, um diese Probleme in der EVM-virtuellen Maschine zu identifizieren.

Passen Sie sich an und reagieren Sie entsprechend! Angesichts dieser Herausforderungen hat BlockSec ein automatisiertes System entwickelt, um diese Probleme direkt anzugehen!

Differenzielles Fuzzing

Bei BlockSec hat unser Expertenteam einen cleveren Ansatz namens differenzielles Fuzzing angewendet. Indem wir dieselben Testfälle auf verschiedenen Versionen der virtuellen Maschine ausführen und die Ausgabeergebnisse 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, und somit die Gesamtsicherheit des Systems zu verbessern.

Abbildung 2: Arbeitsablauf des differenziellen Fuzzings
Abbildung 2: Arbeitsablauf des differenziellen Fuzzings

Grundlegendes Funktionsprinzip:

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

Spezifische Implementierungsschritte:

Der Testfall für differenzielles Fuzzing muss aus zwei Teilen bestehen: Transaktionsmetadaten und Vorzustand. Aber wie generieren wir diese Transaktionen? Wir haben zwei Ansätze, um diese Herausforderung zu bewältigen.

  1. Wiederverwendung historischer Transaktionen: Wir können die historischen Transaktionen, die auf der Blockchain aufgetreten sind, abrufen und sie in der differenziellen Fuzzing-Engine durch verschiedene Versionen der virtuellen Maschine laufen lassen. Die alleinige Abhängigkeit von dieser Methode hat jedoch ihre Grenzen. Historische Transaktionen sind tendenziell zu "normal", während Sicherheitstests die Aufdeckung von Eckfällen – den außergewöhnlichen Szenarien – erfordern. Deshalb haben wir einen zweiten Ansatz entwickelt.
  2. Coverage-guided Fuzzing: Wir generieren ungewöhnlichen Bytecode und historisch nicht gesehene Transaktionen von Grund auf, mutieren dann die Transaktionen und den Smart-Contract-Code und geben sie in die virtuelle Maschine ein. Wir stellen die Gültigkeit und Vollständigkeit von Testfällen aus verschiedenen Dimensionen sicher.

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

Der Vergleich der Ergebnisse ist nicht nur ein einfacher Zahlenvergleich, sondern berücksichtigt auch umfassend die Datenkonsistenz im persistenten und nicht-persistenten Speicher der virtuellen Maschine. Dieser Artikel wird hierauf nicht weiter eingehen.

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 von Schwachstellen in virtuellen Maschinen vorstellen, den wir mithilfe von differenziellem Fuzzing in der Aurora VM entdeckt haben. Konkret handelt es sich um ein Problem mit dem vorkompilierten Smart Contract ModExp.

Bei der Berechnung der modularen Potenzierung einer Zahl x hoch y wissen wir, dass diese Operation Rechenressourcen erfordert. In einer korrekten Implementierung berücksichtigt die Gasberechnung die Anzahl der Iterationen, da die modulare Potenzierung mehrere Iterationen beinhaltet. Es gibt jedoch ein bestimmtes Szenario, in dem die Gasberechnung ein Problem aufweisen kann: wenn der Exponent y gleich 0 ist, was auf eine Potenzierung nullter Ordnung hinweist. In diesem Fall wird die Anzahl der Iterationen null, was zu einem extrem kleinen Gaswert führt. Tatsächlich erfordert die Berechnung aber dennoch Ressourcen.

Schlussfolgerung

Derzeit unterstützt das von BlockSec gestartete differenzielle 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 wurde die von BlockSec bereitgestellte umfassende Sicherheitslösung für EVM-Chains (Audit-Services + differenzielle Fuzzing-Tools) von EOS und FileCoin anerkannt und übernommen und wird zur Sicherheit und gesunden Entwicklung ihrer Ökosysteme beitragen.

Referenz

[1] Flache Kopie im 0x4-Vorkompilat könnte zu EVM-Speicherbeschädigung führen

[2] RETURNDATA-Beschädigung über Datacopy

Über BlockSec

BlockSec ist ein wegweisendes Blockchain-Sicherheitsunternehmen, das 2021 von einer Gruppe weltweit angesehener Sicherheitsexperten gegründet wurde. Das Unternehmen widmet sich der Verbesserung der Sicherheit und Benutzerfreundlichkeit für die aufstrebende Web3-Welt, um deren Massenadaption zu fördern. Zu diesem Zweck bietet BlockSec Audit-Services für Smart Contracts und EVM-Chains, die Phalcon-Plattform für die proaktive Sicherheitsentwicklung und Bedrohungsblockierung, die MetaSleuth-Plattform für die Nachverfolgung und Untersuchung von Geldern sowie die MetaDock-Erweiterung für Web3-Entwickler, die effizient im Krypto-Bereich surfen.

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

✉️Geschäftliche Beratung: [email protected]

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

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

Sign up for the latest updates
The Decentralization Dilemma: Cascading Risk and Emergency Power in the KelpDAO Crisis
Security Insights

The Decentralization Dilemma: Cascading Risk and Emergency Power in the KelpDAO Crisis

This BlockSec deep-dive analyzes the KelpDAO $290M rsETH cross-chain bridge exploit (April 18, 2026), attributed to the Lazarus Group, tracing a causal chain across three layers: how a single-point DVN dependency enabled the attack, how DeFi composability cascaded the damage through Aave V3 lending markets to freeze WETH liquidity exceeding $6.7B across Ethereum, Arbitrum, Base, Mantle, and Linea, and how the crisis forced decentralized governance to exercise centralized emergency powers. The article examines three parameters that shaped the cascade's severity (LTV, pool depth, and cross-chain deployment count) and provides an exclusive technical breakdown of Arbitrum Security Council's forced state transition, an atomic contract upgrade that moved 30,766 ETH without the holder's signature.

Weekly Web3 Security Incident Roundup | Apr 13 – Apr 19, 2026
Security Insights

Weekly Web3 Security Incident Roundup | Apr 13 – Apr 19, 2026

This BlockSec weekly security report covers four attack incidents detected between April 13 and April 19, 2026, across multiple chains such as Ethereum, Unichain, Arbitrum, and NEAR, with total estimated losses of approximately $310M. The highlighted incident is the $290M KelpDAO rsETH bridge exploit, where an attacker poisoned the RPC infrastructure of the sole LayerZero DVN to fabricate a cross-chain message, triggering a cascading WETH freeze across five chains and an Arbitrum Security Council forced state transition that raises questions about the actual trust boundaries of decentralized systems. Other incidents include a $242K MMR proof forgery on Hyperbridge, a $1.5M signed integer abuse on Dango, and an $18.4M circular swap path exploit on Rhea Finance's Burrowland protocol.

Weekly Web3 Security Incident Roundup | Apr 6 – Apr 12, 2026
Security Insights

Weekly Web3 Security Incident Roundup | Apr 6 – Apr 12, 2026

This BlockSec weekly security report covers four DeFi attack incidents detected between April 6 and April 12, 2026, across Linea, BNB Chain, Arbitrum, Optimism, Avalanche, and Base, with total estimated losses of approximately $928.6K. Notable incidents include a $517K approval-related exploit where a user mistakenly approved a permissionless SquidMulticall contract enabling arbitrary external calls, a $193K business logic flaw in the HB token's reward-settlement logic that allowed direct AMM reserve manipulation, a $165.6K exploit in Denaria's perpetual DEX caused by a rounding asymmetry compounded with an unsafe cast, and a $53K access control issue in XBITVault caused by an initialization-dependent check that failed open. The report provides detailed vulnerability analysis and attack transaction breakdowns for each incident.

Best Security Auditor for Web3

Validate design, code, and business logic before launch. Aligned with the highest industry security standards.

BlockSec Audit