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:
- "Gypsy" hoards bitcoin, holding more than 1,000 bitcoin addresses and growing at a record high
- Opinion ｜ Why it is inevitable that the stablecoin introduces the KYC program
- 2019 Deloitte Global Blockchain Survey: There is no common model for blockchain industry applications, depending on industry characteristics
- Viewpoint | The virtual reality of the combination of real estate industry and digital securities
- Gartner's Top Ten Strategic Technology Trends in 2020: Blockchain will be fully scalable by 2023
- People's Daily Overseas Edition: Blockchain, "chain" to the future
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.
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)
- 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)
- 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.
- 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=0is run on any of the full-node backends and the node is offline, the vulnerability may also be use.
- 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)
- 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.
Once a funding transaction is observed, the peer (peer) must check whether the outpoint described in
`funding_created`  is the funding transaction output  described in
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
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 , and describes the requirements for waiting for confirmation .
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
Vulnerability discovery process
Rusty Russell (Blockstream) discovered this vulnerability when testing the specification itself (adding several new proposed features ).
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.
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;