Lightning Development Kit-Versionen vor v0.2.7 und v0.1.13 setzten einige Bitcoin-Lightning-Anwendungen einem Reconnect-Angriff aus, der eine weitergeleitete Zahlung in einen Verlust verwandeln konnte. Ein bösartiger Kanal-Peer konnte ein Update bestätigen, die Verbindung erneut aufbauen und fälschlich behaupten, es nie erhalten zu haben. Vor dem Fix konnte LDK eine widersprüchliche Commitment-Transaktion signieren, ohne sie im Channel Monitor zu vermerken.
Warum das wichtig ist
Der Angriff zielte auf den Statusverwaltungsprozess hinter den Lightning-Kanälen ab. Nach der falschen Reconnect-Behauptung konnte der bösartige Peer die widersprüchliche Transaktion in Bitcoins Blockchain bestätigen und die Zahlung beim nächsten Empfänger zur Abwicklung bringen. Anschließend konnte er den eingehenden Zahlungsvertrag nach dessen Ablauf zurückfordern, sodass die weiterleitende Anwendung auf dem Schaden saß, obwohl sie das Zahlungsgeheimnis kannte, mit dem die Mittel normalerweise eingefordert werden.
Das gepatchte Verhalten erlaubt eine erneute Übertragung nur, solange die Bestätigung des Peers noch aussteht. Behauptet ein Peer, ein bereits bestätigtes Update verpasst zu haben, schließt LDK den Kanal nun zwangsweise.
Die LDK-Entwickler schlossen in v0.2.7 zudem einen separaten Diebstahlpfad im Zusammenhang mit LSPS2 Just-in-Time-Zahlungen. Eine abgefangene Zahlung konnte ihren Betrag falsch angeben, wodurch ein Liquiditätsdienst einen Kanal öffnete und mehr Bitcoin weiterleitete, als die eingehende Zahlung deckte. Entwickler müssen außerdem offen Zahlungsverträge berücksichtigen, die von älteren Versionen erstellt wurden, da deren Beträge möglicherweise nicht validiert wurden.
Marktauswirkung
Die unmittelbare Gefährdung ist operativer Natur und kein Fehler des Bitcoin-Protokolls. LDK wird in die Anwendungen kompiliert, die es nutzen, daher müssen Wallet- und Zahlungsentwickler den betreffenden gepatchten Bibliothekscode in ihre eingesetzte Software integrieren. Die Version v0.2.7 behebt das Reconnect-Problem auf dem 0.2-Zweig sowie die LSPS2-Betragsprüfung, während v0.1.13 den gemeinsamen Reconnect-Fix für den 0.1-Zweig enthält.
Teams, die Lightning-Infrastruktur betreiben, sollten ihre eingesetzten LDK-Versionen, offenen Kanäle und offenen LSPS2-Verträge überprüfen. Core Lightning ist eine separate Implementierung und nicht die in diesem Bericht betroffene Bibliothek.
Häufig gestellte Fragen
-
Welche Lightning-Schwachstelle haben die gepatchten LDK-Versionen behoben?
Ein bösartiger Kanal-Peer konnte die Verbindung erneut aufbauen und fälschlich behaupten, ein bestätigtes Update verpasst zu haben. Vor dem Fix konnte LDK eine widersprüchliche Commitment-Transaktion signieren, die vom Channel Monitor nicht erfasst wurde.
-
Welche LDK-Versionen beheben die Reconnect-Schwachstelle?
LDK v0.2.7 behebt das Problem auf dem 0.2-Zweig, während v0.1.13 den gemeinsamen Reconnect-Fix für den 0.1-Zweig enthält.
-
Wie konnte der Reconnect-Angriff einen Bitcoin-Verlust verursachen?
Der Angreifer konnte eine widersprüchliche Transaktion in Bitcoin bestätigen, die weitergeleitete Zahlung beim nächsten Empfänger abwickeln lassen und später den eingehenden Zahlungsvertrag nach Ablauf zurückfordern.
-
Welches weitere Problem behebt LDK v0.2.7?
Version 0.2.7 fixt zudem ein LSPS2-Just-in-Time-Zahlungsproblem, bei dem ein falsch angegebener Zahlungsbetrag einen Liquiditätsdienst dazu bringen konnte, mehr Bitcoin weiterzuleiten, als er erhielt.
-
Was sollten Entwickler von Lightning-Anwendungen jetzt tun?
Entwickler sollten den betreffenden gepatchten LDK-Code in eingesetzte Anwendungen integrieren und offene LSPS2-Zahlungsverträge älterer Versionen auf unvalidierte Beträge überprüfen.
CoinDesk
CZ Binance
TheBlock
Crypto News