Untersuchungen von SRLabs deuten darauf hin, dass Sicherheitslücken bei vielen Ethereum-Blockchain-Teilnehmern über längere Zeiträume hinweg ungepatcht bleiben, was das Blockchain-Ökosystem gefährdet.
Kryptowährungen stellen eine beliebte Alternative zu zentralisierten Zahlungssystemen dar und versprechen Transaktionen zwischen gegenseitig anonymen Parteien, die oft als „vertrauenswürdige“ Transaktionen bezeichnet werden. Genauer gesagt verlassen sich Blockchain-Teilnehmer darauf, dass die Mehrheit der Teilnehmer rationale Maßnahmen ergreift, anstatt sich auf ein einzelnes Bankinstitut oder eine einzelne Regierung verlassen zu müssen. Allerdings scheinen die erforderlichen rationalen Maßnahmen über die Bereitschaft vieler Blockchain-Benutzer hinauszugehen. Insbesondere haben wir frühe Hinweise darauf gefunden, dass Blockchain-Teilnehmer nicht ausreichend Patches bereitstellen und daher bekannte Schwachstellen aufweisen.
Einen Monat nach seiner Veröffentlichung hat ein kritischer Sicherheitspatch noch kein Drittel der Parity Ethereum-Nodes erreicht.
Ethereum ist eine Kryptowährung, die über ein Peer-to-Peer-Netzwerk entsteht. Mit einer Marktkapitalisierung von über 19 Milliarden US-Dollar ist Ethereum ein äußerst attraktives Ziel für Hacker. Jeder Teilnehmer benötigt einen Software-Client, um auf das Ethereum-Netzwerk zuzugreifen: Die häufigsten Optionen sind Parity-Ethereum (Parity) und Go-Ethereum (Geth).
Ethereum setzt auf hohe Verfügbarkeit, um Doppelausgaben zu verhindern.
Ein Hacker, der mehr als 51 % der Rechenleistung im Netzwerk kontrolliert, kann Coins doppelt ausgeben, was den Hacker bereichert und das Vertrauen in das Ökosystem untergräbt. Wenn ein Hacker eine große Anzahl von Knoten zum Absturz bringen kann, wird es einfacher, 51 % des Netzwerks zu kontrollieren. Daher stellen Softwareabstürze ein ernstes Sicherheitsrisiko für Blockchain-Nodes dar (im Gegensatz zu anderen Softwareteilen, bei denen der Hacker normalerweise nicht von einem Absturz profitiert).
Daher haben Denial-of-Service-Schwachstellen in Kryptowährungsnetzwerken einen besonders hohen Schweregrad. Sie haben das Potenzial, die erforderliche Rechenleistung für die Durchführung eines 51-Prozent-Angriffs erheblich zu reduzieren und doppelte Ausgaben zu ermöglichen. Ethereum ist darauf angewiesen, dass die Nodesoftware nur sehr schwer aus der Ferne abstürzen kann. Es ist jedoch nahezu unmöglich, perfekte Software zu erstellen, und in Blockchain-Clients treten von Zeit zu Zeit Fehler auf, die Remote-Abstürze ermöglichen.
Nicht gepatchte Parity-Ethereum-Nodes können aus der Ferne abstürzen.
Wir haben im Februar 2019 eine Schwachstelle im Parity Ethereum-Client gemeldet, die den Fernabsturz aller Parity Ethereum-Knoten vor Version 2.2.10 ermöglichen könnte. Der Absturz wird durch einen „Integer-Overflow“ während der Synchronisation der Chains zwischen zwei Knoten verursacht, der aus der Ferne ausgelöst werden kann. Da jede Node solche Verbindungsanfragen akzeptiert, um mit dem Hauptnetzwerk synchronisiert zu bleiben, ermöglicht die Schwachstelle einem Angreifer, jede im Ethereum-Netzwerk aktiven, nicht gepatchten Parity Node zum Absturz zu bringen.
Nach unseren gesammelten Daten wurden bisher nur zwei Drittel der Nodes gepatcht.
Kurz nachdem wir diese Schwachstelle gemeldet hatten, veröffentlichte Parity eine Sicherheitswarnung, in der die Teilnehmer aufgefordert wurden, ihre Nodes zu aktualisieren.
Einen Monat nach dieser Warnung verwendeten wir Daten von Ethernodes.org, um die Sicherheit der Ethereum-Nodeslandschaft zu bewerten, und stellten fest, dass etwa 40 % aller gescannten Parity Ethereum-Nodes, also 15 % aller gescannten Nodes [1], ungepatcht blieben daher anfällig für den erwähnten Angriff [2]. Ein weiterer Patch, der am 2. März 2019 veröffentlicht wurde, erreichte etwa 70 % der Parity Ethereum-Knoten, weitere 30 % waren jedoch immer noch veraltet.
Abbildung 1: Der Prozentsatz der ungepatchten Ethereum-Nodes nimmt im Laufe der Zeit langsam ab [2019]
Abbildung 1 zeigt, dass der Prozentsatz anfälliger Nodes im Laufe der Zeit langsam abnimmt. Für Parity-Ethereum haben wir gemessen, wie viele Knoten unter Version 2.2.10 (13. Februar 2019, sicherheitskritisch) und wie viele unter Version 2.3.9 (2. April 2019, nicht sicherheitskritisch) liegen. Zum Vergleich verfolgen wir Geth-basierte Nodes, die keinen konsenskritischen Patch erhalten haben (unter Patch 1.8.21, veröffentlicht am 11. Dezember 2018). Die Daten betonen, dass das Patchen relativ langsam erfolgt.
7 % der aktiven Parity Ethereum-Nodes wurden seit neun Monaten nicht gepatcht.
Bei der Verwendung derselben Daten haben wir außerdem festgestellt, dass 7 % der Parity Ethereum-Nodes auf einer Version laufen, die anfällig für eine kritische Konsensschwachstelle ist, die die Entwickler am 5. Juli 2018 behoben haben.
Um das Rückgrat des Ethereum-Netzwerks zu brechen, müssen nur eine Handvoll Nodes abstürzen. Leider ist in den Daten von ethernodes.org nicht enthalten, ob es sich bei den Nodea Miner handelt.
Wir wissen jedoch, dass sich derzeit die große Menge an Hashing-Leistung auf einige wenige Mining-Pools konzentriert. Mining-Pools teilen sich oft eine Node, um mit dem Ethereum-Netzwerk zu kommunizieren, und wir können mit Sicherheit davon ausgehen, dass diese Mining-Pools sehr sicherheitsbewusst sind und ihre Nodes auf dem neuesten Stand halten. Während dies tatsächlich bedeutet, dass die Gefahr eines Zusammenbruchs aufgrund einer Patch-Lücke derzeit gering ist, birgt diese Zentralisierung auch ein Risiko: Um das Rückgrat des Ethereum-Netzwerks zu zerstören, müssen nur eine Handvoll Knoten abstürzen, was angesichts einer Denial of Service Schwachstelle leicht machbar ist wie die, die wir gefunden haben. Wenn das Netzwerk stärker dezentralisiert wäre, würde es verhindern, dass Angriffe, die nicht mit mehr Nodes skalieren, das Netzwerk zerstören.
Um diese Situation zu lösen, benötigen wir zuverlässigere Update-Mechanismen.
Daher ist es wünschenswert (und im Einklang mit den Grundüberzeugungen von Ethereum), die Hashing-Leistung zu dezentralisieren – diese Dezentralisierung würde jedoch nur dann die Sicherheit erhöhen, wenn die neuen Mining-Nodes weiterhin sicherheitsbewusst wären. Unsere Untersuchungen deuten darauf hin, dass dies möglicherweise zu viel verlangt ist, und zeichnen ein pessimistisches Bild für eine dezentralere Zukunft. Blockchain-Ökosysteme sollten nach Möglichkeiten suchen, die Energie in ihrem Netzwerk zu dezentralisieren, ohne das Risiko einzugehen, sich bei der Aufrechterhaltung der Infrastruktur auf anfällige Nodes zu verlassen. Eine Möglichkeit, dies zu erreichen, ist ein automatisierter Aktualisierungsmechanismus, den Parity tatsächlich für seinen Ethereum-Client gewählt hat.
Selbst wenn die Miner-Knoten vorerst sicher sind, kann das Versäumnis, bekannte Schwachstellen zu schließen, zu einem Zusammenbruch des Blockchain-Ökosystems führen, wenn die Hashing-Leistung stärker dezentralisiert wird. Dieses Versäumnis bei der Aktualisierung könnte dazu führen, dass das Blockchain-Ökosystem anfälliger wird, da die Hürde für die Durchführung eines 51-Prozent-Angriffs sinkt.
Das Parity Ethereum verfügt über einen automatisierten Update-Prozess – dieser leidet jedoch unter hoher Komplexität
Parity Ethereum verfügt über einen automatischen Update-Mechanismus, was darauf hindeutet, dass die Patch-Lücke viel kleiner sein dürfte. Der automatische Aktualisierungsmechanismus von Parity Ethereum basiert jedoch auf mehreren Smart Contracts in der Blockchain. Diese Abhängigkeit von der Blockchain führt zu zwei möglichen Problemen:
Erstens sind nicht alle Benutzer mit der Blockchain synchronisiert und erhalten daher keine Informationen über die neuesten Updates. Bevor Parity zum ersten Mal automatisch aktualisiert werden kann, muss der Client große Teile der Blockchain herunterladen und synchronisiert bleiben, um zukünftige Updates zu erhalten. Infolgedessen werden veraltete Nodes während des Synchronisierungsprozesses anfällig für Angriffe und können möglicherweise nie aufholen, wenn sie nur für kurze Zeiträume genutzt werden. Sich auf einen On-Chain-Smart-Vertrag zu verlassen bedeutet auch, dass nur Clients, die mit der kanonischen Ethereum-Chain verbunden sind, Benachrichtigungen über neue Updates erhalten. Kunden, die mit kleineren, alternativen Chains verbunden sind, die nicht über die oben genannten Verträge in der Kette verfügen, sind anfällig.
Darüber hinaus ist die Update-Infrastruktur komplex, da sie nicht nur die Aktualisierung der Vertragsdaten erfordert, sondern auch zusätzlichen Aufwand während des Release-Prozesses verursacht. Aber die Parity-Betreuer müssen auch sicherstellen, dass die Daten, auf die diese Smart Contracts verweisen – herunterladbare Binärdateien – immer von allen Nodes verfügbar sind. Dies macht den automatischen Update-Prozess fehleranfällig.
Erschwerend kommt hinzu, dass der Parity Ethereum-Client bei Verwendung der Standardeinstellungen nur Updates herunterlädt, die kritisch sind. Die Schwelle, einen Patch als kritisch zu markieren, scheint ziemlich hoch zu sein: Obwohl die Parity-Sicherheitswarnung Benutzer dazu drängt, den Patch zu installieren, hat es der erwähnte Denial-of-Service-Bug nicht in die kritischen Veröffentlichungen geschafft.
Geth verfügt architekturbedingt über keinen Aktualisierungsprozess.
Der andere beliebte Ethereum-Client, Geth, verfügt über keine automatische Aktualisierungsfunktion, was eine bewusste Designentscheidung zu sein scheint. Folglich ist die Patch-Lücke für Geth-Clients größer als für Parity-Clients. Den Ankündigungen zufolge waren rund 44 % der auf ethernodes.org sichtbaren Geth-Nodes niedriger als Version v.1.8.20, ein sicherheitskritisches Update, das zwei Monate vor unserer Messung veröffentlicht wurde.
Mangelnde grundlegende Patch-Hygiene untergräbt die Sicherheit des Ethereum-Ökosystems.
Der Mangel an Patch-Hygiene bei Ethereum-Benutzern lässt darauf schließen, dass bei einer erheblichen Anzahl von Ethereum-Benutzern auch schwerwiegendere Schwachstellen über Tage, Wochen oder Monate bestehen bleiben könnten, was ihre eigene Sicherheit und die Integrität des Ethereum-Ökosystems gefährdet. Wenn eine beliebte Client-Software eine Sicherheitslücke bezüglich Remotecodeausführung enthalten würde, hätte die Schwere der Patch-Lücke schwerwiegende Folgen.
Ethereum ist als Peer-to-Peer-Netzwerk auf rational handelnde Teilnehmer angewiesen: Die aktuelle Patch-Lücke verstößt gegen diese Grundannahme, da es nicht streng rational ist, sich selbst und andere Hackerangriffen auszusetzen.
Globale vertrauenswürdige Systeme sind auf Software angewiesen, und Software weist Fehler auf. Es liegt in unserer Verantwortung als Blockchain-Benutzer, diese großen dezentralen Ökosysteme vor Infektionen zu schützen, indem wir Sicherheitsupdates installieren, sobald diese verfügbar sind. Dies erfordert sowohl mehr automatisierte Patching-Optionen als auch mehr Patching-Hygiene von Blockchain-Benutzern.
(Ob der Übergang von einer Welt, in der ein paar große Banken die Finanzsysteme kontrollieren, zu einer Welt, in der ein paar Patch-Signaturschlüssel eine ähnliche Macht ausüben, ein Fortschritt ist, das ist ein Thema für einen anderen Tag.)
Recherche von: Vincent Ulitzsch (@vinulium), Stephan Zeisberg (@stze), Martin Saar
Fußnoten
[1] Nicht alle Paritätsknoten tragen die gleiche Rechenleistung zum Ethereum-Netzwerk bei. Tatsächlich scheint die Rechenleistung stark auf eine kleine Anzahl von Nodes konzentriert zu sein. Wenn die Hauptnodes gut gewartet werden, ist die Dringlichkeit, kleinere Nodes zu patchen, etwas geringer, um einen 51-Prozent-Angriff zu verhindern.
Aufgrund der Risikokonzentration wachsen jedoch auch andere Hackerrisiken.
[2] Ethernodes.org stellte die Daten am 21. März 2019 zur Verfügung und die Version eines Nodes wird durch seinen angekündigten Header bestimmt. Die Version eines Nodes wird anhand seines angekündigten Headers identifiziert. Ethernodes.org nutzt das Erkennungsprotokoll des Ethereum-Netzwerks, um das Netzwerk zu scannen und hat zu diesem Zeitpunkt fast 11.000 Nodes entdeckt. Bitte beachte, dass in den Daten von Ethernodes.org möglicherweise Nodes fehlen, die nicht ständig online sind. Wir gehen davon aus, dass die fehlenden Nodes im Durchschnitt weniger gut gepatcht sind. Daher stellen die Patch-Gap-Schätzungen eine Untergrenze dar. Die tatsächliche Patch-Lücke ist wahrscheinlich größer.