Lightning Griefing: Channels anderer Nodes ausschalten

Mit steigender Adoption des Lightning-Netzwerks wächst auch die Anzahl der Augen, die das Protokoll verfolgen und auf Schwachstellen testen. Dass es bei einem neuen P2P-Netzwerk hin und wieder zu Problemen kommen kann, dürfte niemanden wundern. Schließlich ist das Motto des Lightning-Netzwerks nicht zu unrecht “#reckless“.

Durch ungeschicktes und leichtsinniges Verhalten kann es durchaus dazu kommen, dass Node-Betreiber Bitcoin in den Channels ihres Nodes verlieren. Beispielsweise durch das Wiederherstellen eines Backups, das nicht aktuell ist.

Dass es aber nicht nur durch eigenes Fehlverhalten zu Problemen kommen kann, haben Joost Jaeger, Jestopher und Clark Burkhardt nun in der Praxis bewiesen. Der von Joost Jaeger bereits im letzten September in der Theorie beschriebene Angriff ermöglicht es einer dritten Partei einen Channel zwischen zwei anderen Nodes lahm zu legen.

Jaeger, der erst kurz zuvor sein Arbeitsverhältnis bei Lightning Labs beendet hatte, postete eine Zusammenfassung der Schwachstelle auf Twitter.

Das Problem

Lightning-Zahlungen funktionieren über HTLCs (Hashed Time Locked Contracts). Über diese Contracts werden die Channelkonditionen nach jeder Zahlung aktualisiert. Bleibt eine Zahlung weder bestätigt noch abgelehnt, bleibt der HTLC der Zahlung im Channel liegen. Je nach Channel-Konfiguration kann jedoch nur eine maximale Anzahl an HTLCs (standard 483 ) gleichzeitig im Channel liegen. Ein Angreifer kann viele kleine Zahlungen zwischen zwei Channelpartnern initiieren, die nicht aufgelöst werden (sogenannte Hodl-Invoices) und das Limit der HTLCs eines Channels ausreizen.

Lightning Griefing
via Joost Jaeger

Ist ein Channel am Limit seiner HTCLs angekommen, wird er inaktiv und kann keine weiteren Zahlungen weiterleiten. Ebenso kann der Channel nicht kooperativ geschlossen werden, da er mit HTLCs gefüllt ist. Es muss also ein Force-Close geschehen um die im Channel gebundene Liquidität wiederzuerlangen. Das fatale dabei: Jede einzelne HTLC, die noch im Channel liegt, wird mit einer On-Chain-Transaktion aufgelöst. Das bedeutet für den Channelbesitzer bis zu 483 Einzeltransaktionen. Weil die Transaktionen im nächsten Block bestätigt werden müssen, muss eine extrem hohe Transaktionsgebühr fällig. Bei 483 Einzeltransaktionen mit 250sat/vbyte wird eine Summe von 3.400.000 sats für die Transaktionsgebühren nötig. Zusätzlich werden nach jedem Force-Close die ehemalige Kapazität des Channels für einen Zeitraum von bis zu 2 Wochen gelockt.

Aufgrund dieser Umstände kann ein Angreifer zwar kein Bitcoin stehlen, doch hohen Schaden anrichten. Beispielsweise könnte eine Lösegeld-Zahlung gefordert werden um die HTLCs aufzulösen und den Channel wieder freizugeben. Da die Kosten für solch einen Angriff bei annähernd null liegen, würden sich solche Angriffe nicht nur auf große Nodes lohnen.

Ein anderer Einsatz könnte das Ausschalten von Channels anderer Routing-Nodes sein, um den Routing-Traffic über den eigenen Node zu erhöhen und so mehr Routing-Gebühren einzunehmen.

Lösungen

Zum aktuellen Zeitpunkt ist noch keine der verfügbaren Lightning-Implementationen vor diesem Angriff geschützt. Und das obwohl Jaeger mit “Circuit Breaker” direkt einen Lösungsansatz vorgeschlagen hat.

Mit Circuit-Breaker können jedem Peer eine maximale Anzahl an HTLCs pro Channel zugewiesen werden. Das bedeutet, dass ein vertrauenswürdiger Peer eine höhere Anzahl an HTLC-Slots einnehmen kann als ein neuer, weniger vertrauenswürdiger Node.

Auch eine vorgeschlagene Lösung von Bitmex-Research “Stake-Certificates” funktioniert über ein Reputationssystem. Dieses würden über UTXO-Besitz-Zertifikate funktionieren, bei denen der Besitzer anhand von UTXOs identifiziert wird. Diese Zertifikate würden nötig, um HTLCs zu versenden.

Bisher ist noch kein Angriff auf diese Art und Weise bekannt geworden. Die Schwierigkeit der Umsetzung ist dabei nicht besonders hoch. Zwar benötigt der Angreifer ein gewisses Verständnis vom Lightning-Netzwerk und Programmierkenntnisse – einmal programmiert könnte es aber für jeden Lightning-Node-Betreiber einfach sein, Channels anderer Nodes auszuschalten.

Dass dieses Problem noch keine standardisierte Lösung in LND und C-Lightning hat, zeigt, dass es mehr Aufmerksamkeit braucht um gelöst zu werden. Wir konnten keine öffentliche Stellungsnahme der beiden Entwickler zu diesem Thema finden. Derzeit sind mehr als 99% aller Lightning Channel durch diese Schwachstelle angreifbar.

Mehr zu diesem Angriff erklärt Jestopher in einer Präsentation von BTC-Kindergarten:

Schreibe einen Kommentar