Antoine Riard [ARCHIVE] on Nostr: 📅 Original date posted:2023-06-19 🗒️ Summary of this message: LNbits ...
📅 Original date posted:2023-06-19
🗒️ Summary of this message: LNbits discovered an exploit allowing attackers to create balances by abusing a quirk in how invoices are handled internally, which may affect other Lightning applications. A patch has been released.
📝 Original message:
Hi calle,
Thanks for the report.
>From my understanding of what you're describing, the attack is possible
because LNBits backend does not check that an external received HTLC
`amount_msat` satisfies the invoice amount for both matching preimage and
payment secret. This sounds plausible to me.
If you're a custodial wallet, payment processor or account management
software based on LDK, and you respect the API recommendations of using
`create_inbound_payment`, you should not be affected as amount equivalence
checks are handled by the implementation:
https://github.com/lightningdevkit/rust-lightning/blob/c3c105075aeb8128699e043f777b4c89c452e54d/lightning/src/ln/channelmanager.rs#L4469
The "checking ids" sounds a workable mitigation to firewall internal
invoice state from external ones, though beware issues with id collision,
if it can be determined by the attacker.
Potential safety issues with invoices have been known since CVE-2020-26896.
Good disclosure security practice suggests having previously warned the
Lightning implementation maintainers on their respective security
communication channels to ease patch coordination if needed with
second-line vendors like wallets and processors.
Best,
Antoine
Le lun. 19 juin 2023 à 17:19, callebtc via Lightning-dev <
lightning-dev at lists.linuxfoundation.org> a écrit :
> Dear list,
>
> earlier last month, our team at LNbits discovered a rather interesting
> exploit which wich would enable an attacker to create balances out of thin
> air by abusing a quirk in how invoices are handled internally. We've
> patched this in LNbits version 0.10.5 and urge anyone to update ASAP if you
> haven't done so already. I want to describe the attack here, since my gut
> feeling is that carrying out the same exploit is possible in other
> Lightning applications. If you're working on custodial wallets, payment
> processors, account management software, etc. you probably want to read
> this.
>
> In short, 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.
>
> Here is how it goes:
>
> - Attacker creates invoice A of amount 1000 sat in LNbits
> - Attacker creates invoice B' of amount 1 sat on her own node
> - Attacker deserializes B', inserts payment_hash(A) into payment_hash(B),
> re-signs the invoice, and serializes it again, producing malicious invoice B
> - Attacker creates a new account in LNbits and pays B
>
> - LNbits backend uses payment_hash(B) to check whether this is an internal
> payment or a payment via LN
> - Backend finds A in its database since we implicitly assume that
> payment_hash(A) commits to A
>
> ** This is the critical part! Payment hashes do *NOT* commit to any
> payment details (like amount) but only to the preimage! **
>
> - Backend settles payment internally by crediting A debiting B
> - Attacker has "created" 999 sats
>
> Mitigation:
>
> The mitigation is quite simple. Backends should either use self-generated
> unique "checking id's" for looking up internal payments or use additional
> checks to make sure that the invoice details have not been messed around
> with (e.g., asserting amount(A) == amount(B)).
>
> Lessons:
>
> I think there are two lessons here. First, it's good to realize the level
> of sophistication of LN-savvy attackers. This attack clearly involves a
> fundamental understanding of bolt-11 and requires custom tooling to produce
> the malicious invoice.
>
> The second lesson is more valuable: The "payment hash" of an invoice is
> not a "payment" hash but merely a "preimage" hash – and nothing else.
> Naming this field as such increases the chance of developers implicitly
> assuming that the hash commits to payment details like amount, pubkey, etc.
> I will from now on call this simply the "preimage hash" and invite you to
> do so too.
>
> Best
>
> Calle
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230619/51635592/attachment.html>;
🗒️ Summary of this message: LNbits discovered an exploit allowing attackers to create balances by abusing a quirk in how invoices are handled internally, which may affect other Lightning applications. A patch has been released.
📝 Original message:
Hi calle,
Thanks for the report.
>From my understanding of what you're describing, the attack is possible
because LNBits backend does not check that an external received HTLC
`amount_msat` satisfies the invoice amount for both matching preimage and
payment secret. This sounds plausible to me.
If you're a custodial wallet, payment processor or account management
software based on LDK, and you respect the API recommendations of using
`create_inbound_payment`, you should not be affected as amount equivalence
checks are handled by the implementation:
https://github.com/lightningdevkit/rust-lightning/blob/c3c105075aeb8128699e043f777b4c89c452e54d/lightning/src/ln/channelmanager.rs#L4469
The "checking ids" sounds a workable mitigation to firewall internal
invoice state from external ones, though beware issues with id collision,
if it can be determined by the attacker.
Potential safety issues with invoices have been known since CVE-2020-26896.
Good disclosure security practice suggests having previously warned the
Lightning implementation maintainers on their respective security
communication channels to ease patch coordination if needed with
second-line vendors like wallets and processors.
Best,
Antoine
Le lun. 19 juin 2023 à 17:19, callebtc via Lightning-dev <
lightning-dev at lists.linuxfoundation.org> a écrit :
> Dear list,
>
> earlier last month, our team at LNbits discovered a rather interesting
> exploit which wich would enable an attacker to create balances out of thin
> air by abusing a quirk in how invoices are handled internally. We've
> patched this in LNbits version 0.10.5 and urge anyone to update ASAP if you
> haven't done so already. I want to describe the attack here, since my gut
> feeling is that carrying out the same exploit is possible in other
> Lightning applications. If you're working on custodial wallets, payment
> processors, account management software, etc. you probably want to read
> this.
>
> In short, 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.
>
> Here is how it goes:
>
> - Attacker creates invoice A of amount 1000 sat in LNbits
> - Attacker creates invoice B' of amount 1 sat on her own node
> - Attacker deserializes B', inserts payment_hash(A) into payment_hash(B),
> re-signs the invoice, and serializes it again, producing malicious invoice B
> - Attacker creates a new account in LNbits and pays B
>
> - LNbits backend uses payment_hash(B) to check whether this is an internal
> payment or a payment via LN
> - Backend finds A in its database since we implicitly assume that
> payment_hash(A) commits to A
>
> ** This is the critical part! Payment hashes do *NOT* commit to any
> payment details (like amount) but only to the preimage! **
>
> - Backend settles payment internally by crediting A debiting B
> - Attacker has "created" 999 sats
>
> Mitigation:
>
> The mitigation is quite simple. Backends should either use self-generated
> unique "checking id's" for looking up internal payments or use additional
> checks to make sure that the invoice details have not been messed around
> with (e.g., asserting amount(A) == amount(B)).
>
> Lessons:
>
> I think there are two lessons here. First, it's good to realize the level
> of sophistication of LN-savvy attackers. This attack clearly involves a
> fundamental understanding of bolt-11 and requires custom tooling to produce
> the malicious invoice.
>
> The second lesson is more valuable: The "payment hash" of an invoice is
> not a "payment" hash but merely a "preimage" hash – and nothing else.
> Naming this field as such increases the chance of developers implicitly
> assuming that the hash commits to payment details like amount, pubkey, etc.
> I will from now on call this simply the "preimage hash" and invite you to
> do so too.
>
> Best
>
> Calle
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230619/51635592/attachment.html>;