Zwei ziemlich esoterische Bugs in Lightning-Software LND

Lightning Labs enthüllt zwei Bugs im Lightning-Server LND. Die beiden Bugs sind sehr speziell und wurden bisher noch nicht ausgenutzt. Updaten sollte man seinen Knoten dennoch.

Wer einen Lightning-Node mit LND betreibt, sollte sicherstellen, dass er die aktuelle Version der Software installiert hat

Connor Frommknecht von Lightning Labs forderte die Community durch die Mailing-Liste auf, die Software zu aktualisieren. Man habe eine Verletzlichkeit in allen Versionen von LND 0.10.x und tiefer entdeckt.

Gestern veröffentlichte Connor nun die Beschreibung von zwei Bugs, die dem Team durch Antoine Riard von ChaincodeLabs mitgeteilt wurden. Die beiden Bugs wurden bisher noch nicht ausgenutzt und sind sehr speziell. Doch es ist interessant, sie sich näher anzuschauen, da sie etwas über die Mechanik des Lightning-Netzwerks verraten.

Der erste Bug trägt den Namen “CVE-2020-26895: LND Low-S Tx-Relay Standardness“. Wie so oft bei Lightning wird es nicht ganz einfach, zu verstehen, was dahintersteckt.

Ein Hacker konnte gegenüber einem Lightning-Knoten, der LND benutzt, den folgenden Angriff ausführen: Er konnte den Status eines Channels aktualisieren und dafür eine Transaktion mit einer Signatur mit einem “hohen S-Wert” versehen.

Der S-Wert in der Signatur leitet sich von einer zufällig gewählten Zahl ab und ist Teil der mathematischen Formel der Signatur. An sich ist der S-Wert beliebig, doch um die Transaktions-Malleabilität zu beseitigen – bzw. das Problem zu reduzieren – hat Bitcoin Core um 2014 die “Politik” eingeführt, dass die Software nur noch niedrige S-Werte produziert und akzeptiert.

Es handelt sich dabei um keine Konsens-Regel, sondern um eine “Politik”. Das bedeutet, dass eine Transaktion, deren Signatur einen hohen S-Wert enthält, an sich gültig ist, wenn sie es in einen Block schafft. Doch da die anderen Knoten sie nicht akzeptieren und weiterleiten, fliegt die Transaktion aus dem Mempool der unbestätigten Transaktionen heraus und findet potenziell niemals den Weg zu einem Miner, der sie in einen Block einlocht.

Während die btcec-Bibliothek für onchain-Transaktionen gar nicht mehr in der Lage ist, Signaturen mit niedrigem S-Wert zu bilden, musste LND – und die anderen Lightning-Implementierungen – die Methode, Signaturen zu bilden, etwas verändern, da diese anders dekodiert werden. Dabei aber haben die Entwickler das Verbot der tiefen S-Werte übersehen, weshalb LND solche Signaturen nicht nur akzeptiert, sondern auch in der Lage ist, zu produzieren.

Der Angreifer kann das ausnutzen, wenn das Opfer einen Channel unilaterial schließt. In dem Fall wird die aktuellste Transaktion nämlich nicht vom MemPool innerhalb des Zeitfensters akzeptiert, woraufhin der Angreifer eine Transaktion bilden kann, durch die er das gesamte Guthaben des Channels absahnt.

Ihr seht – es handelt sich um einen ziemlich esoterischen Bug, der in die Tiefe der Kryptographie geht und nur in speziellen Situationen eine Bedeutung hat. Aber es geht noch weiter.

Denn kurz darauf vermeldete Connor den zweiten Bug: “CVE-2020-26896: LND Invoice Preimage Extraction“. Er hat mit dem ersten Bug gemein, dass er ziemlich komplex ist.

Und zwar geht es darum: Lightning-Transaktionen benutzen “Hash-based Time-Locks” (HTLC), um offchain etwas zwischen Knoten auszutauschen, das quasi einem garantierten Zahlungsversprechen entspricht. Ein solches HTLC wird vom Sender einer Lightning-Transaktion an andere Knoten weitergegeben, die zwischen ihm und dem Empfänger stehen. Wenn ein solcher Zwischenknoten das HTLC auflöst, muss er ein sogenanntes “Preimage” enthüllen, um einen Anspruch auf das HTLC zu erheben.

Um zu verstehen, was ein Preimage, zu deutsch Urbild, ist, muss man verstehen, was Signaturen machen: Sie nehmen eine Nachricht, generieren aus dieser den Hash, und verschlüsseln bzw. signieren diesen anschließend. Die Nachricht selbst bzw. eine Ableitung von ihr – zum Beispiel die Inversion – ist das Preimage. Dass ein Lightning-Knoten ein Preimage generiert, um ein HTLC abzuholen, ist ganz normal.

Problematisch wird es aber, wenn ein Lightning-Knoten ein Preimage bildet, das er gar nicht bilden sollte. Der genannte Bug erlaubt es nämlich, dass ein Angreifer einen LND-Knoten durch eine kollidierende Hash der Zahlung dazu zwingt, ein valides Preimage für das weiterzuleitende HTLC zu enthüllen, bevor er dieses überhaupt beansprucht. Das kann dazu führen, dass der Angreifer mehr über das Ziel der Zahlung erfährt, als er sollte, und unter bestimmten Umständen erlaubt es ihm auch, zu denken, eine Zahlungsaufforderung sei beglichen, während lediglich die Gebühren bezahlt wurden.

Dieser Bug ist beinah noch esoterischer als der erste. Schließlich ist es nicht eben trivial, eine Kollision einer Hash zu finden, und der Ertrag ist nicht gerade üppig – unter bestimmten Umständen ein Double-Spend oder eine geringfügige Minimierung der Privacy.

Die beiden Bugs wurden bisher noch nicht ausgenutzt, vermutlich, weil sie erstens zu komplex und zweitens zu speziell sind. Die Bitcoins der meisten User in einem LND-Knoten dürften von den Bugs nicht betroffen sein. Ein Update sollte man aber dennoch machen.