Author: Antoine Riard 2023-06-19 20:34:10+00:00
Published on: 2023-06-19T20:34:10+00:00
The email is a response to a report regarding a possible attack on LNBits backend. The attack is possible because the backend does not check if an external received HTLC `amount_msat` satisfies the invoice amount for both matching preimage and payment secret. The author suggests that custodial wallets, payment processors, and account management software based on LDK and following the API recommendations of using `create_inbound_payment` should not be affected as amount equivalence checks are handled by the implementation. The author also mentions potential safety issues with invoices that have been known since CVE-2020-26896.The email refers to an exploit discovered by the LNbits team, which allows an attacker to create balances out of thin air by abusing a quirk in how invoices are handled internally. The exploit has been patched in LNbits version 0.10.5. The attacker was able to insert a bolt-11 payment hash of payment A into a different payment, creating a malicious invoice B that can trick the backend into believing that B == A. The attacker creates invoice A of amount 1000 sat in LNbits, then creates invoice B' of amount 1 sat on their own node. They deserialize B', insert payment_hash(A) into payment_hash(B), re-sign the invoice, and serialize it again, producing malicious invoice B. The attacker creates a new account in LNbits and pays B. The LNbits backend uses payment_hash(B) to check whether this is an internal payment or a payment via LN. Since payment_hash(A) commits to A, the backend finds A in its database. However, payment hashes do not commit to any payment details like amount, only to the preimage. As a result, the backend settles the payment internally by crediting A and debiting B, allowing the attacker to "create" 999 sats.The author suggests a mitigation for this attack, which involves backends using self-generated unique "checking id's" for looking up internal payments or using additional checks to ensure that the invoice details have not been tampered with. The author also mentions two lessons from this attack. First, it highlights the level of sophistication of LN-savvy attackers, as this attack requires a fundamental understanding of bolt-11 and custom tooling. Second, the author suggests renaming the "payment hash" field in invoices to the "preimage hash" to avoid developers implicitly assuming that the hash commits to payment details like amount and pubkey.
Updated on: 2023-07-14T03:06:17.629572+00:00