Sicherheitsprüfung: Halten EVM-kompatible Ketten stand?

Aufdecken verborgener Sicherheitsrisiken im EVM: Wie BlockSecs automatisiertes Werkzeug hilft, genauer hinzusehen

Sicherheitsprüfung: Halten EVM-kompatible Ketten stand?

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 der Rede 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 während ihrer Implementierung Sicherheitsprobleme? Nach unseren Recherchen ist die Antwort bejahend. Als Reaktion auf diese Bedenken hat BlockSec ein automatisiertes differenzielles Fuzzing-Sicherheitstool eingeführt. Begleiten Sie uns auf einer Reise, um die Wahrheit hinter diesen EVM-kompatiblen Chains zu erkunden.

Schwachstellen in virtuellen Maschinen

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

Am Beispiel der Ethereum Virtual Machine (EVM) wird eine stackbasierte Architektur übernommen, 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 Computerprogramm ist. 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 er katastrophale Folgen für das Ökosystem der Blockchain. Tatsächlich gab es in der EVM in der Vergangenheit viele schwerwiegende Schwachstellen.

Zum Beispiel gab es im Jahr 2020 einen Schwachstellenvorfall, der durch einen vorcompilierten Vertrag verursacht wurde (d. h. CVE-2020-26241) [1]. Der dataCopy-vorcompilierte Vertrag in Geth (an der Adresse 0x00...04) führte bei der Aufrufung eine flache Kopie durch, wobei beim Kopieren großer Datenmengen nur die Zeiger statt der 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 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 vorcompilierter Verträge überschnitten. Angreifer nutzten diese Schwachstelle aus, was zu einer Chain-Gabelung führte.

BlockSecs Gegenmaßnahmen

Wie können Schwachstellen in der EVM rechtzeitig entdeckt werden? Was sind die Herausforderungen?

  1. Erstens ist es aufgrund des komplexen Designs der virtuellen Maschine schwierig, Werkzeuge zu finden, die ihre Betriebslogik vollständig verstehen können. Jedes Fachgebiet erfordert Spezialisierung, und viele Entwickler können möglicherweise nicht genügend Aufwand investieren, um die Betriebslogik 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 einführen kann.

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

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 angewandt. Durch die Ausführung derselben Testfälle auf verschiedenen Versionen der virtuellen Maschine und den Vergleich der Ausgabenergebnisse können wir potenzielle Schwachstellen und Inkonsistenzen aufdecken. Diese Methode ermöglicht es uns, subtile Unterschiede effektiv zu identifizieren, die herkömmliche Testmethoden übersehen könnten, und somit die Gesamtsicherheit des Systems zu verbessern.

Abbildung 2: Workflow für differenzielles Fuzzing

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 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 differenzielles 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 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 auf verschiedene Versionen der virtuellen Maschine anwenden. Die ausschließliche Anwendung dieser Methode hat jedoch ihre Grenzen. Historische Transaktionen sind tendenziell zu "normal", während Sicherheitstests die Aufdeckung von Eckfällen – den Ausnahmeszenarien – 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 neu, mutieren dann die Transaktionen und den Smart Contract-Code und geben sie in die virtuelle Maschine ein. Wir gewährleisten die Gültigkeit und Vollständigkeit der Testfälle aus verschiedenen Dimensionen.

Sobald diese Transaktionen generiert sind, werden sie in die differenzielle 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 in der virtuellen Maschine. Dieser Artikel wird nicht weiter darauf eingehen.

Fallstudie

Abbildung 3: Ein Beispiel für das Problem mit dem vorcompilierten Vertrag ModExp in der Aurora VM

Ich möchte einen Schwachstellenfall einer virtuellen Maschine teilen, den wir durch differenzielles Fuzzing in der Aurora VM entdeckt haben. Insbesondere bezieht er sich auf ein Problem mit dem vorcompilierten Smart Contract ModExp.

Bei der Berechnung der modularen Potenz von 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 umfasst. Es gibt jedoch ein bestimmtes Szenario, in dem die Gasberechnung auf ein Problem stößt: Wenn der Exponent y gleich 0 ist, was eine Potenzoperation nullter Ordnung anzeigt. In diesem Fall wird die Anzahl der Iterationen null, was zu einem extrem geringen Gaswert führt. Aber tatsächlich erfordert die Berechnung immer noch Ressourcen.

Fazit

Derzeit unterstützt das von BlockSec eingeführte differenzielle Fuzzing-Tool die Ausführung in den Umgebungen verschiedener Blockchain-virtueller Maschinen, einschließlich 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 umfassende EVM-Chain-Sicherheitslösung von BlockSec (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 Precompile könnte zu Speicherbeschädigung in der EVM führen

[2] Beschädigung von RETURNDATA über datacopy

Über BlockSec

BlockSec ist ein führendes Blockchain-Sicherheitsunternehmen, das 2021 von einer Gruppe weltweit renommierter Sicherheitsexperten gegründet wurde. Das Unternehmen hat sich der Verbesserung der Sicherheit und Benutzerfreundlichkeit für die aufstrebende Web3-Welt verschrieben, um deren Massenadoption zu fördern. Zu diesem Zweck bietet BlockSec Audits von Smart Contracts und EVM-Chains, die Phalcon-Plattform für sicherheitsorientierte Entwicklung und proaktive Bedrohungsabwehr, die MetaSleuth-Plattform für die Nachverfolgung von Geldern und Untersuchungen sowie die MetaDock-Erweiterung für Web3-Entwickler zum effizienten Surfen in der Krypto-Welt.

Bis heute hat das Unternehmen über 300 angesehene 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 in US-Dollar erhalten.

✉️Geschäftsberatung: [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