Inhaltsverzeichnis
Durch die Analyse von Angriffen gegen einen Ethereum-Client kannst du das Notwendige identifizieren und priorisieren um Sicherheitsmaßnahmen zu überlegen.
Es kommt immer wieder vor, dass mich einige kritisch Fragen, welche Angriffe theoretisch auf Ethereum-Clients möglich wären oder bereits erfolgreich durchgeführt wurden. Da ich bereits selber die gleichen Fragen schon öfters hatte und im Web recherchiert und einige Ethereum-Entwickler bei einem Getränk dazu befragte, habe ich hier ein paar Szenarien angeführt.
Welche Angriffsszenarien kann es auf einen Ethereum-Client geben?
- Eclipse-Angriffe, die versuchen, Client-Netzwerkressourcen zu erschöpfen oder ihre Knotenerkennung zu täuschen.
- Angriffe auf nicht authentifizierte JSON-RPC-Schnittstellen durch schadhaftes JavaScript im Web-Browser, welcher DNS-Bindung verwendet.
- Alle Arten von Social-Engineering-Angriffen.
- Schädliche Code-Snippets im Open-Source-Repositories.
- Gezielte Ausnutzung von Konsensfehlern bei der EVM-Implementierungen. (Ethereum Virtual Machine)
Was sind Eclipse-Angriffe auf einen Ethereum-Client?
Eclipse-Angriffe auf Ethereum-Client oder -Knoten, sind Angriffe die das Peer-to-Peer-Netzwerk für die Nachbarschaftserkennung ausnutzen. Eine Nachbarschaftsbeziehung (Gossip Protokoll) hat mehrere eingehende und ausgehende TCP-Verbindungen. Sodass eine Transaktion in Millisekunden an das gesamte Netzwerk propagiert werden kann. Eclipse-Angreifer kapseln alle eingehenden und ausgehenden Verbindungen des Opfers (Ethereum-Client) und isoliert so das Opfer von den übrigen Kollegen im Netzwerk. Der Angreifer kann dann die Sicht des Opfers auf die Ethereum-Blockchain filtern oder die Rechenleistung des Opfers als Teil komplexerer Angriffe nutzen.
Viele Forscher haben sich mit diesem Thema intensiv auseinandergesetzt und die Erkenntnisse sehr detailliert beschrieben:
https://www.usenix.org/node/190891
https://eprint.iacr.org/2018/236.pdf
Was ist JSON-RPC überhaupt?
JSON (JavaScript Object Notation) ist ein leichtes Format für den Datenaustausch. JSON ist ein
sprachunabhängiges Textformat, das für Menschen einfach zu lesen, zu schreiben, zu analysieren und zu generieren ist. Für Systeme ist es ideal für den Datenaustausch. Wie damals XML (Extensible Markup Language) eine Auszeichnungssprache zur Darstellung hierarchisch strukturierter Daten im Format einer Textdatei, die sowohl von Menschen als auch von Maschinen lesbar ist. https://de.wikipedia.org/wiki/Extensible_Markup_Language
JSON-RPC ist ein zustandsloses, leichtes RPC-Protokoll (Remote Procedure Call), das JSON als Datei Format verwendet. Die JSON-RPC -Spezifikation definiert mehrere Datenstrukturen und die zugehörigen Regeln ihre Verarbeitung.
https://de.wikipedia.org/wiki/JavaScript_Object_Notation
Eine JSON-RPC-API wird für die Kommunikation zwischen Ethereum-Clients und DApps-Clients verwendet.
https://de.wikipedia.org/wiki/JSON-RPC
Was ist ein Social-Engineering Angriff?
Siehe dazu: https://www.searchsecurity.de/definition/Social-Engineering
Was ist Schädlicher Code?
Laut Kaspersky: „Bei schädlichem Code handelt es sich um gefährlichen Computercode oder Webskripte, der bzw. die Systemschwachstellen schaffen, die wiederum zu Backdoors, Sicherheitsverletzungen, Informations- und Datendiebstahl sowie anderen potenziellen Gefahren für Dateien und System führen können.„
Meiner Erfahrung nach ist es ein allgemeines Mantra, dass Open Source aufgrund seiner Verfügbarkeit für eine offene Prüfung tendenziell sicher ist. Ich stimme dem zu. Gleichzeitig ist es kein Geheimnis, dass ständig Schwachstellen entdeckt werden. Obwohl es Open Source ist und regelmäßig geprüft wird.
An dokumentierten Nachweisen dafür scheint es nicht viel zu geben. Sicher ist es passiert, aber aufgrund der Natur von Open Source, wo jeder, der über ein gewisses Maß an Wissen verfügt, eine Anforderung zur Aktualisierung der Codebase stellen kann, wird immer die Frage gestellt, ob etwas, das böswillig wird, vorsätzlich oder einfach ein Fehler war. Die Heartbleed-Schwachstelle in OpenSSL wurde zwei Jahre lang nicht bemerkt. Sie wurde jedoch letztendlich vom Benutzer, der die Änderung hochgeladen hat und dem Administrator, der die Änderung genehmigt hat, als Fehlschlag gemeldet.
Im Jahr 2003 wurde von einem unbekannten Angreifer versucht, eine Hintertür in den Linux-Kernel zu zwingen. Sie nutzten damals die Methoden der Quellcodeverwaltung, um den Code direkt in ein sekundäres Code-Repository einzufügen, anstatt zu versuchen, den Code zur Peer-Review einzureichen.
Da absolut jeder eine Änderung des Open Source-Codes beantragen kann, wird es viele Fälle von üblen Spielen geben. Wenn die Anwendung groß genug ist, um darüber berichten zu können, sind in der Regel zahlreiche Genehmigungsschritte vorhanden, um den Code zuerst zu überprüfen.
Je größer die Anwendung wird, desto mehr potenzielle Augen werden auf den Code gerichtet. Wenn du als Hacker bösartigen Code in eine Peer-Review-basierte Quellcodeverwaltung wie Github einreichst, gehst du All-In und denkst dir: „Ich hoffe, Sie überprüfen das nicht gründlich, weil ich versuche, etwas Unangenehmes zu tun“. Es wäre viel sicherer und weniger wahrscheinlich, dass du sofort erwischt wirst und versuchst deinen schädlichen Code auf andere Weise zu verbreiten, die nicht überwacht werden sollen, wie beispielsweise bei einem Man-in-the-Middle-Angriff eine modifizierte Version der Anwendung an jemanden, der versucht, sie herunterzuladen.
Ausnutzung von Fehlern bei der EVM-Implementierung?
Implementierungen des EVM (Ethereum Virtual Machine), sollten immer gleich sein und denselben EVM-Code kompilieren.
Weil sie der Spezifikation von EVM folgen sollten.
Wenn jeder Client über eine eigene EVM verfügt, wie kann sichergestellt werden, dass der Smart Contract dasselbe Ergebnis erzielt, wenn er von einem anderen Client ausgeführt wird?
Jede eigene Implementierung des EVM, sollte der Spezifikation folgen und denselben EVM-Code kompilieren wie andere Clients.
Wenn es einen Fehler (oder ein Update) in Ethereum gibt, wie werden die Clients aktualisiert?
Es gibt mehrere Möglichkeiten, Clients zu aktualisieren. Eine davon heißt Hard Fork.
Eine Hard Fork ist eine Änderung des zugrundeliegenden Ethereum-Protokolls und erstellt neue Regeln zur Verbesserung des Systems. Die Protokolländerungen werden bei einer bestimmten Blocknummer aktiviert. Alle Ethereum-Clients müssen ein Upgrade durchführen, andernfalls werden sie nach den alten Regeln in einer inkompatiblen Kette für immer gefangen.
Kennst du Angriffsmöglichkeiten auf den Ethereum-Client? Hast du dazu Papers oder Artikel zu verlinken? Hinterlasse ein Kommentar und hilf der Ethereum Gemeinschaft Wissen zu verbreiten.
