Author: callebtc 2023-06-19 15:26:05+00:00
Published on: 2023-06-19T15:26:05+00:00
Earlier last month, the LNbits team discovered an exploit that allowed attackers to create balances by exploiting a quirk in how invoices are handled internally. This exploit has been patched in LNbits version 0.10.5, and users are urged to update as soon as possible. The team wants to describe the attack to raise awareness, as they believe similar exploits may be possible in other Lightning applications, especially those related to custodial wallets, payment processors, and account management software.The attack involves inserting a bolt-11 payment hash of payment A into a different payment, creating a malicious invoice B that tricks the backend into thinking B is equal to A. Here's how it works: the attacker creates invoice A with an amount of 1000 sat in LNbits, then creates invoice B' with an amount of 1 sat on their own node. The attacker deserializes B', inserts the payment_hash(A) into payment_hash(B), re-signs the invoice, and serializes it again, resulting in the malicious invoice B. Then, the attacker creates a new account in LNbits and pays invoice B.The LNbits backend uses payment_hash(B) to determine whether it's an internal payment or a payment via Lightning Network. Since it is assumed that payment_hash(A) commits to A, the backend finds A in its database. However, this assumption is flawed because payment hashes only commit to the preimage, not the payment details like amount. Consequently, the backend settles the payment internally by crediting A and debiting B, allowing the attacker to "create" 999 sats.To mitigate this issue, backends should either use self-generated unique "checking id's" for internal payment lookups or implement additional checks to ensure the invoice details haven't been tampered with (e.g., asserting amount(A) == amount(B)).This incident highlights two important lessons. Firstly, it demonstrates the level of sophistication displayed by LN-savvy attackers, as this attack requires a deep understanding of bolt-11 and custom tooling to produce the malicious invoice. Secondly, it emphasizes that the "payment hash" of an invoice is actually a "preimage" hash and does not commit to payment details like amount or pubkey. Developers are encouraged to refer to this field as the "preimage hash" to avoid implicit assumptions about its functionality.Overall, this incident serves as a reminder for developers working on Lightning applications to be vigilant and proactive in addressing potential exploits and vulnerabilities.
Updated on: 2023-07-14T03:05:58.144701+00:00