📅 Original date posted:2023-07-06
🗒️ Summary of this message: LNbits discovered an exploit that allowed attackers to create fake balances by manipulating invoices, urging users to update their software.
📝 Original message:
Um, this is a super-weird setup AFAICT.
You generate an invoice, but you don't remember anything about it? Um,
OK, stateless invoices are a thing, but there's a metadata field for
that?
Someone pays an invoice, you don't check the place it's going (which,
y'know, signed it), you check some other field?
I've never used lnbits and I'm clearly missing something...
Thanks!
Rusty.
callebtc via Lightning-dev <lightning-dev at lists.linuxfoundation.org>
writes:
> 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
Rusty Russell [ARCHIVE] /
npub1zw…hkhpx
2023-07-10 19:01:44
in reply to nevent1q…j622
Author Public Key
npub1zw7cc8z78v6s3grujfvcv3ckpvg6kr0w7nz9yzvwyglyg0qu5sjsqhkhpxPublished at
2023-07-10 19:01:44Event JSON
{
"id": "91709617ca2c66d549ea6dd4c095bc1c15679a532ffc7de5eee10f5d0e4f24ee",
"pubkey": "13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425",
"created_at": 1689015704,
"kind": 1,
"tags": [
[
"e",
"35a14bd6a10694fd6ada147bdf3f4b79bfe4dbbd80866bf03040ee430153d73c",
"",
"reply"
],
[
"p",
"9456f7acb763eaab2e02bd8e60cf17df74f352c2ae579dce1f1dd25c95dd611c"
]
],
"content": "📅 Original date posted:2023-07-06\n🗒️ Summary of this message: LNbits discovered an exploit that allowed attackers to create fake balances by manipulating invoices, urging users to update their software.\n📝 Original message:\nUm, this is a super-weird setup AFAICT.\n\nYou generate an invoice, but you don't remember anything about it? Um,\nOK, stateless invoices are a thing, but there's a metadata field for\nthat?\n\nSomeone pays an invoice, you don't check the place it's going (which,\ny'know, signed it), you check some other field?\n\nI've never used lnbits and I'm clearly missing something...\n\nThanks!\nRusty.\n\ncallebtc via Lightning-dev \u003clightning-dev at lists.linuxfoundation.org\u003e\nwrites:\n\n\u003e Dear list,\n\u003e\n\u003e 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.\n\u003e\n\u003e 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.\n\u003e\n\u003e Here is how it goes:\n\u003e\n\u003e - Attacker creates invoice A of amount 1000 sat in LNbits\n\u003e - Attacker creates invoice B' of amount 1 sat on her own node\n\u003e - Attacker deserializes B', inserts payment_hash(A) into payment_hash(B), re-signs the invoice, and serializes it again, producing malicious invoice B\n\u003e - Attacker creates a new account in LNbits and pays B\n\u003e\n\u003e - LNbits backend uses payment_hash(B) to check whether this is an internal payment or a payment via LN\n\u003e - Backend finds A in its database since we implicitly assume that payment_hash(A) commits to A\n\u003e\n\u003e ** This is the critical part! Payment hashes do *NOT* commit to any payment details (like amount) but only to the preimage! ** \n\u003e\n\u003e - Backend settles payment internally by crediting A debiting B\n\u003e - Attacker has \"created\" 999 sats\n\u003e\n\u003e Mitigation:\n\u003e\n\u003e 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)).\n\u003e\n\u003e Lessons:\n\u003e\n\u003e 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. \n\u003e\n\u003e 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.\n\u003e\n\u003e Best \n\u003e\n\u003e Calle\n\u003e _______________________________________________\n\u003e Lightning-dev mailing list\n\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev",
"sig": "e87f7c0b9bbf5db21fc2dc9f676bc119a326ed17202ced95ef6ee1d409ef77352b2a197fa85196be1b27c857b9f85eb57102cc94570e4e6b9c58471e1e91476b"
}