Lightning network security vulnerability technical details and discovery process

Recently, developer Rusty Russell disclosed for the first time the technical details of lightning network security vulnerabilities and corresponding solutions.

The following are technical details:

The lightning network node that accepts the channel must check if the funding transaction output does open the proposed channel, otherwise the attacker can claim to open a channel and then either not pay to the peer or not pay in full.

• Farce does not stop! LedgerX executives accuse CFTC of preferring its competitor Bakkt
• Exploring Bitcoin: Explaining Bitcoin's Intrinsic Investment Logic
• Where are we in the mining cycle?

Once the transaction reaches a minimum depth, it can spend money from the channel. Only when the victim tries to close the channel, and any promises or mutual transactions they have are invalid, will they notice this malicious behavior.

The Lightning Network client does not necessarily perform this check:

C-lightning: The v0.7.1 and higher clients did this correctly, but the previous version of the c-lightning client couldn't do it. (CVE-2019-12998)

1. This vulnerability can be exploited by connecting to a peer node and opening a channel with any transaction id.

Lnd: Clients with v0.7.1 and higher have solved this problem, but the previous version of lnd did not check the number. The v0.7.0 and higher clients correctly checked the scriptpubkey . The v0.6.x client part enforced the funding of ScriptPubkey , but the client before the ScriptPubkey version did not perform the relevant verification at all. (CVE-2019-12999)

1. For all previous versions of the lnd client, an attacker could attack with an incorrect number. In v0.7.0, the attacker must use the correct scriptpubkey , which will burn out the currency in the funding output.
2. For clients prior to scriptpubkey , an attacker can attack with an incorrect scriptpubkey . In the v0.6.x client, if the funting transaction reaches the required number of acknowledgments and txindex=0 is run on any of the full-node backends and the node is offline, the vulnerability may also be use.
3. Attacking a neutrino client (usually a mobile or laptop) user with an error outpoint requires the attacker to collide its fake outpoint with the real outpoint script in the BIP 158 filter. The siphash key used to create the filter is derived from blockhash. Therefore, an attacker cannot directly attack without knowing the block hash in advance. In addition, neutrino client nodes typically do not listen or have an announcement address, which means that an attacker must wait until an inbound connection is received before an attack can be performed.

Eclair: The v0.3.1 and above clients correctly solve the security problem. If the user uses the bitcoin core as the backend, the previous version of the eclair client will have security risks. The electrum user only checks the script and does not check the quantity. (CVE-2019-13000)

1. Attacking the Electrotum client user (mobile) requires the user to actively connect to the malicious lightning network node, and the attacker uses the correct scriptpubkey , which burns the currency in the funding output. Since the Eclair mobile client does not relay payments, the attacker cannot withdraw money without an offband interaction (for example, selling something to the user and using the funds in the fake channel). Operational.

solution

Once a funding transaction is observed, the peer (peer) must check whether the outpoint described in `funding_created` [1] is the funding transaction output [2] described in `open_channel` [3].

background

To open a lightning network channel, the funding peer sends an `funding_satoshis` with the proposed `funding_satoshis` (amount). The `accept_channel` replies with `accept_channel` provide the key it wishes to use for the funding transaction.

The funder then creates the funding transaction and sends the transaction id and the output number in the `funding_created` message.

Node A is the "investor" and node B is the "granter"

With this information, the “ `funding_signed` ” can create a signature on the first “committed transaction” and send it to a `funding_signed` message so that the funder can retrieve their funds in the event of a problem. . In this way, the investor can safely sign and broadcast the opening transaction. After a certain amount of confirmation (set by the "grantee"), the channel will start working (`funding_locked`).

The specification clearly describes the requirements for checking the various signatures exchanged, whether it does allow the creation of a valid commitment transaction [4], and describes the requirements for waiting for confirmation [5].

However, it does not require the recipient to actually check if the transaction is a transaction promised by the investor: including the amount and the actual scriptpubkey .

Vulnerability discovery process

Rusty Russell (Blockstream) discovered this vulnerability when testing the specification itself (adding several new proposed features [6]).

When writing the test, the channel opener provided an incorrect `funding_output_index` in the `funding_created` message, and Russell realized that the C-Lightning client would not reject it because C-Lightning only checked the `funding_txid` confirmation. Counting, even if `funding_output_index` exists, will not check!

This requirement was not mentioned in the specification, so Rusty immediately revealed the problem to the authors of other widely used clients (eclair and lnd). After investigation, they found that there is such a problem.

So, several teams made a decision together to quietly solve these problems in the new version of the client, and then after 8 weeks (most users complete the upgrade), they can reveal the problem itself, and then after four weeks, they Full disclosure of vulnerabilities.

Fortunately, this long-standing vulnerability has not been widely exploited, and it does provide an opportunity to test the entire lightning network ecosystem communication and upgrade approach.

Vulnerability schedule

2019-06-27: Rusty Russell discovers vulnerabilities and notifies LND and Eclair client authors;

2019-06-28: The CVE vulnerability number is assigned;

2019-07-02: lnd v0.7.0-beta client release;

2019-07-03: Eclair 0.3.1 client release;

2019-07-04: c-lightning 0.7.1 client release;

2019-07-06: Rusty Russell and others began to disclose vulnerabilities to other clients (rust-lightning, ptarmigan, BLW);

2019-07-30: lnd v0.7.1-beta client release;

2019-08-17: [View next date based on deployment status/problem];

2019-08-30: External disclosure of CVE vulnerabilities exists, and advise users who use old versions of clients to upgrade;

2019-09-07: It was first discovered that someone was trying to exploit this vulnerability;

2019-09-27: Full disclosure of CVE vulnerability details;

2019-09-27: Submit PR according to the specifications;

[1] https://github.com/lightningnetwork/lightning-rfc/blob/v1.0/02-peer-protocol.md#the-funding_created-message

[2] https://github.com/lightningnetwork/lightning-rfc/blob/v1.0/03-transactions.md#funding-transaction-output

[3] https://github.com/lightningnetwork/lightning-rfc/blob/v1.0/02-peer-protocol.md#the-open_channel-message

[4] https://github.com/lightningnetwork/lightning-rfc/blob/v1.0/02-peer-protocol.md#requirements-2

[5] https://github.com/lightningnetwork/lightning-rfc/blob/v1.0/02-peer-protocol.md#the-funding_locked-message

[6] https://github.com/ElementsProject/lightning-rfc-protocol-test

We will continue to update Blocking; if you have any questions or suggestions, please contact us!