Im Bitcoin Lightning-Netzwerk können Zahlungen blitzartig und nahezu kostenlos durchgeführt werden. Dafür braucht es immer einen oder mehrere Zahlungskanäle, über die der gewünschte Betrag "entlang versendet" wird. Bei der Art und Weise, wie diese Zahlungskanäle eröffnet werden, fand Matt Morehouse nun eine kleine Schwachstelle, die mit einem relativ simplen Denial-of-Service-Angriff (DoS, englisch für "Verweigerung des Dienstes") ausgenutzt werden kann, hießt es in seinem Blog-Artikel. Theoretisch konnte der Angriff sogar bis zum Diebstahl von Bitcoin-Beständen auf die Spitze getrieben werden.
Betreiber einer eigenen Lightning-Node, die ihre Software stets auf die neusten Versionen aktualisieren, müssen sich allerdings keine Gedanken machen. Die Schwachstelle ist bereits in den neueren Versionen diverser Lightning-Implementierungen behoben, genauer gesagt ist man ab den folgenden Versionsnummern auf der sicheren Seite:
Wer sich noch in darunter liegenden, älteren Versionen wiederfindet, sollte also möglichst bald ein entsprechendes Update durchführen. Es gibt zwar keinen akuten Grund zur Panik, allerdings sind Bestände in eigenen Zahlungskanälen unter der Schwachstelle theoretisch unsicher, zumindest unter bestimmten Bedingungen.
Ein neuer Zahlungskanal
Nachdem wir die Formalitäten aus dem Weg geräumt haben, können wir uns die doch recht interessante Schwachstelle etwas genauer anschauen. Denn es handelt sich hier um ein schönes Beispiel, warum das Übersehen von kleinen Details in einem Protokoll, die auf den ersten Blick sicherheitstechnisch nicht relevant zu sein scheinen, dennoch zu fatalen Folgen führen können.
Beim Öffnen eines neuen Lightning-Kanals gibt es einen wohl definierten Ablauf, so etwas wie eine Anleitung zur Kommunikation. Man bittet um einen neuen Kanal bei seinem gewünschten Kanal-Partner, dieser akzeptiert die Anfrage, man erstellt eine Bitcoin-Transaktion, um den Kanal zu finanzieren, und so weiter. Kurz vor Fertigstellung des neuen Zahlungskanals hat der finanzierende der beiden Teilnehmer, also derjenige, der Anfangs Bitcoin in den Kanal einzahlt, die Aufgabe, die entsprechende Transaktion auch im Bitcoin-Netzwerk zu veröffentlichen. Bis hierhin kein Problem.
Im Wartezimmer
Doch was ist, wenn der finanzierende Teilnehmer, nennen wir ihn Bob, genau dies nicht tut? Wartet er mit der Veröffentlichung der Finanzierungs-Transaktion, dann wartet auch der Kanal-Partner auf der anderen Seite – und zwar nach Empfehlung der Lightning-Spezifikation ganze zwei Wochen lang. Solch ein Vorfall ist zwar nervig, kann aber sicherlich auch unabsichtlich vorkommen und ist immer noch alles andere als dramatisch. Doch Bob, der bösartiges im Schilde führt, kann genau denselben Vorgang erneut in die Wege leiten und wiederholt versuchen, einen neuen Kanal mit seinem Opfer zu öffnen. Auch dieses Mal hält er die Transaktion, die im Bitcoin-Netzwerk veröffentlicht werden muss, zurück, und lässt seinen Kanal-Partner warten.
Je öfter Bob diesen "Angriff" durchführt, der eigentlich ein völlig legitimer Vorgang im Lightning-Protokoll ist, desto mehr Ressourcen muss sein Opfer aufwenden, um nach den entsprechenden Transaktionen im Bitcoin-Netzwerk Ausschau zu halten. Vorstellen kann man sich das wie im Wartezimmer beim Arzt: Wenn immer mehr Patienten warten müssen, aber niemand aufgerufen wird, ist irgendwann Schluss und die Praxis, also die Lightning-Node, ist überlastet.
Solange eine Lightning-Node also vereinfacht gesagt keine Obergrenze hat, wie viele ausstehende Kanäle im Wartezimmer Platz nehmen dürfen, kann ein potenzieller Angreifer sein Opfer komplett überfordern und eventuell sogar zum Absturz treiben.
Matt Morehouse schildert die Auswirkungen auf verschiedenste Lightning-Implementierungen, die er mit Tests auf seine eigenen Lightning-Nodes in Erfahrung bringen konnte. Beispielsweise kam es bei Eclair zu wiederholten Abstürzen, selbst nachdem der DoS-Angriff bereits beendet war. Bitcoin-Bestände wären hier also definitiv in Gefahr gewesen, da sich die Lightning-Node nicht mehr aktiv gegen Betrugsversuche hätte wehren können. Bei Core Lightning hingegen waren Bestände von vorneherein gut geschützt, da Aufgaben wie das Überwachen des Bitcoin-Netzwerks von getrennten Prozessen übernommen wird.
Fazit
Schwachstellen, wie wir sie in diesem Beitrag kennengelernt haben, sind, vor allem bei einem relativ jungen Projekt wie dem Lightning-Netzwerk, früher oder später unvermeidbar. Glücklicherweise gibt es in diesem Fall keine bekannten Schäden und ein zukünftiges Ausnutzen der Schwachstelle konnte nun frühzeitig verhindert werden. Die Schwachstelle ist allerdings auch nicht gerade neu. Morehouse hatte das Grundprinzip des Angriffs bereits vor einem Jahr entdeckt, und erst durch ausführliche Tests realisiert, dass nahezu keine der Lightning-Implementierungen dagegen geschützt ist.
Was kann man also als einfacher Betreiber einer Lightning-Node aus der Geschichte mitnehmen? Eine gute Möglichkeit, sich grundsätzlich gegen Angriffe dieser Art zu schützen, sind sogenannte Watchtower. Als zusätzliche, "zweite Node" können diese den Überblick über Aktivitäten im Bitcoin- und Lightning-Netzwerk behalten, um im Notfall bei Betrugsversuchen einzuschreiten. Hierfür sind nicht einmal zwingend externe Dienstleister notwendig: Auch privat kann man sich eine zusätzliche Backup-Lösung schaffen, die einem stets den Rücken freihält. Vor allem bei höheren Beträgen, die man in eigenen Zahlungskanälen verwaltet, ist dies eine Überlegung wert.
