David A. Harding [ARCHIVE] on Nostr: 📅 Original date posted:2023-07-12 🗒️ Summary of this message: LNBits ...

📅 Original date posted:2023-07-12
🗒️ Summary of this message: LNBits discovered an exploit allowing attackers to create balances by abusing a quirk in how invoices are handled. A suggestion was made to support self-payment of invoices.
📝 Original message:
On 2023-06-19 05:26, callebtc via Lightning-dev wrote:
> Our team at LNbits discovered a rather interesting
> exploit which which would enable an attacker to create balances out of
> thin air by abusing a quirk in how invoices are handled internally.

Hi Calle,

If I understand correctly from some quick research, LNBits allows its
users to request payments from both external users and other internal
users of the same instance via the same interface, BOLT11 invoices.
Users may also generate payments to both external users and other
internal users via the same interface where they agree to the details in
a BOLT11 invoice.

To make this possible, LNBits essentially short circuits payment
attempts it believes are being made from one internal user to another
internal user. Instead of passing those through an underlying LN
implementation, LNBits attempts to handle them on its own.

The problem here is that the the short-circuit version didn't implement
all the checks specified in BOLT4, e.g. "[...] the _final node_ [...]
if the amount paid is less than the amount expected: MUST fail the HTLC"

My question is whether you think it would be worthwhile to ask
developers of the underlying LN node implementations you use to support
self-payment of their own invoices (if they don't already). I see this
having several advantages:

1. LNBits and similar systems no longer need any short circuit logic.
When user Alice requests a payment, LNBits simply calls the
underlying LN implementation's standard `requestpayment` API. When
user Bob wants to review and pay the invoice, LNBits simply call the
underlying implementation's `pay` API. Whatever the result of the
payment (success or failure), the underlying API returns that result
to LNBits so it can make the appropriate account updates.

2. As the LN protocol grows and changes, fewer changes will be needed to
LNBits and similar systems as they can continue to simply call the
appropriate APIs. For example, support for BOLT12 offers could
become trivial to add.

3. Even for people not using LNBits, being able to pay yourself is a
nice tool for experimentation with an API, especially if it doesn't
cost any fees.

The downside is that it might be a bit more complex for LN
implementations. However, if there are lots of services using LNBits
and similar systems, and I can see how that might come to be the case, I
think there's a strong argument to avoid repetition of security
essential payment processing logic in both an underlying implementation
and account management software.

Thanks for your security disclosure!,

-Dave