Flood & Loot: A Systemic Attack On The Lightning Network
By Jona Harris and Aviv Zohar
Payment channel networks are known to be susceptible to blockchain congestion, which may not allow participants to withdraw funds in time if they are being attacked. In our latest paper we evaluate one such attack: a systemic attack on the Lightning Network that allows stealing funds that were locked in payment channels.
In this attack, an attacker forces many victims at once to flood the blockchain with claims for their funds. He is then able to leverage the congestion that they create to steal any funds that were not claimed before the deadline.
The consequences of the attack depend on the mix of Lightning implementations the attacker chooses to hit. We show that only 85 simultaneously attacked channels are enough to guarantee that the attacker gets away with some money (and this assumes there are no other blockchain transactions competing for space — which is a highly optimistic assumption).
In addition to a big picture view of the attack and its consequences, in this post we also propose several mitigation techniques.
A note of caution: The attack can allow funds to be stolen from innocent users. Do not try it at home. Unfortunately, no obvious change to the protocol eliminates it entirely. The results of this work have been shared with developers of the three main Lightning implementations before publication.
Details of the Attack
The attack exploits the mechanism that is used to forward payments across multiple lightning channels — Hash Time Locked Contracts (HTLC). In brief, HTLCs allow participants to route payments through untrusted intermediate nodes, supposedly guaranteeing that funds won’t be stolen by any of them. If such a node attempts to steal funds, its peer can claim them by publishing transactions to the blockchain, but only within a limited time frame. As we show in our work, it is relatively easy to cause innocent lightning nodes to flood the blockchain, and steal funds by exploiting this time limit.
The key idea behind HTLCs is that after they are established, payments are “pulled” by the target node from the previous node in the path by providing a secret (a preimage of a hash). Our attacker will route a payment between his own two nodes, and pull the payment at the end of the path. He will refuse to cooperate when the payment is eventually pulled from the source node — forcing the victim to do so via a blockchain transaction.
The attack is divided into 4 main phases:
I. Establishing channels
The attacker controls two lightning nodes, denoted the source node and the target node. The source node opens many channels with potential victims, possibly even multiple channels with each victim. These channels are initiated and funded by the attacker’s source node (the target node can be far from the victim, but in the figures below we simplify things and show just a short simple path).
II. Loading channels with HTLC payments
After all channels are set up, the source node starts making many HTLC payments destined to the target node, routed through each of the source node’s channels. The source node sends the maximum amount it is allowed to relay and spreads it over as many payments as it can (as many as the victim will allow).
As part of the HTLC mechanism, the target node is supposed to accept the payments by sending back a set of HTLC secrets. It avoids doing so until the source node completes forwarding all the payments.
III. Resolving payments on the last hop
After all payments were successfully routed and the HTLCs were added to the target node’s channels, the target node resolves all payments by returning the required secrets and claims these funds for himself. At that point, the target node could gracefully close his channels and leave with the funds sent by the source node. Once each victim acquires the secrets, he sends them back to the source node, asking to resolve the HTLCs and move their amount to the victim’s side of the channel. The source node refuses to resolve the payments and ignores any further messages from his victims.
IV. Waiting for expiration and collecting unspent HTLCs
At that point, each attacked channel is filled with unresolved HTLCs, whose secrets are known to the victims. Since the attacker’s source node is uncooperative, the only way the victims can receive these payments is by closing their channels and claiming the HTLCs on the blockchain. The victims have a limited amount of time (measured in blocks) to claim the payments (the time limit is there in case the nodes don’t know the secrets, in which case the funds should be claimed by the source node).
Once they expire, the HTLC outputs become spendable by the attacker. Although the victims can still claim HTLCs after expiration, specific protocol details give a great advantage to the attacker:
- The victims cannot set the fee for their transactions when they publish them. That fee was determined when the channel was opened
- The attacker can set the fee for his own transactions as he wishes and replace any victims’ transactions that remained unconfirmed after expiration (using the Replace-By-Fee policy)
By attacking many channels and forcing them all to be closed at the same time (setting the same expiration time for all HTLCs), some of the victims’ HTLC-claiming transactions will not be confirmed in time, and the attacker will steal them.
The attacker therefore gets to keep some of the funds that should have gone to the victim (the victim’s funds on his next hop were already sent towards the attacker’s target node).
Simulation Results
To show the feasibility of the attack, we simulated it on a local lightning network running over Bitcoin’s regnet. We implemented a prototype of an attacker’s node, capable of stalling the transmission of HTLC secrets, ignoring requests to resolve HTLCs and publishing fee-increased HTLC-claiming transactions. Since LND is the most popular lightning implementation today (it is reported that more than 90% of nodes on the network run LND) we used it to simulate the victim nodes. As we see in the graph below, attacking 85 channels guarantees a successful attack, even if victims’ transactions are allocated all of the space available in blocks (up to the max block weight). Each additional channel will have all of its funds stolen as well.
As the graph also suggests, when the available space in each block decreases, fewer victims are required in order to steal the same amount of HTLCs. We show that this could be the case when an attacker uses a “feerate-minimization” strategy (described below).
Attack Amplification
The fee paid by each of the victims’ transactions is derived from the channel’s feerate parameter. This feerate is determined and paid by the channel’s initiator, in our case — the attacker’s source node. The other node must accept the channel’s feerate before the channel is opened. Nodes agree to set a feerate if it matches their estimate of blockchain fees, as determined by the estimatesmartfee method of bitcoind. From the graph below we learn that feerate estimations may greatly fluctuate in a relatively short period of time. A channel’s feerate that is determined at some point may not be suitable for a later time, when the channel is unilaterally closed.
In addition to setting the initial channel feerate, the channel’s initiator can also propose a new feerate, anytime after the channel is opened, in order to adjust it to the current state of blockchain fees. The Lightning protocol states that the other party, in our case — the victim, is not allowed to make any feerate update requests. In the “feerate-minimization” strategy, the attacker uses the fee-update mechanism to lower the channel’s feerate whenever possible, i.e., when blockchain fees are low (so the other party would agree to that change), but never update it in the other direction when blockchain fees are high. Once the difference between the channel’s feerate and actual blockchain feerates becomes substantial, the attacker can start initiating all HTLC payments and launch the attack. In the following graph we see the average block space that is available to the victims when the attacker is using the feerate-minimization strategy for a period of 3 and 7 days. For example, when the attacker is trying to minimize the feerate for 7 days before starting the attack, the victims will have an average of half a block available, or more, only 58% of time (out of a 2 months period in which we collected the data)
Finding Potential Victims
In this work we also show that finding potential victims does not add a considerable amount of effort for the attacker. For a node to become a victim in the attack, it only needs to accept a request to open a channel with the attacker. A node can show its willingness to open a channel, without actually opening it, by responding with an “accept_channel” message, as described in the Lightning protocol. We conducted an experiment in which we tested the willingness of many nodes on the network to open a channel with an unknown peer. We discover that a vast majority of active nodes (~95%) are willing to open a channel upon request, and are therefore susceptible to becoming victims in our attack.
Mitigations
Multiple techniques can make the attacker’s life harder and lower the potential damage of an attack. Here are some of the mitigation techniques we propose in the full paper.
1) Reducing the maximal number of unresolved HTLCs: The maximum number of payments an attacker can route through an attacked channel is determined by the channel’s parameter “max_accepted_htlcs”. If the value of that parameter is kept low, an attacker will have to attack more channels in order to successfully steal funds.
2) Earlier closure of channels: The time (blocks) victims have to claim their funds is determined by an implementation-specific parameter. Most of the implementations use a much smaller value then they potentially can (to avoid premature closure of channels). This parameter could be increased by a constant factor or even be set dynamically, based on the current state of the channel, e.g., number of unresolved HTLCs or the total unresolved value.
3) Immediate release of HTLC claiming transactions: Some implementations wait until their published commitment is confirmed before releasing the HTLC transactions to claim their outputs. A node can, and should, release these transactions immediately along with the commitment, to allow more potential blocks to which its transactions can get into.
4) Reputation-Based Behavior: A channel’s parameters greatly affect the potential of a successful attack. Nodes can use more permissive parameters for channels with parties to which they assign “good reputation”, according to some policy.
Although there are different mitigations that can reduce the risk of the attack, eliminating the risk entirely seems to be a complicated task. We believe that in many ways the exploited vulnerabilities are inherent to the way HTLCs work, and thus the attack cannot be avoided completely without major modifications to the HTLC mechanism.
For a more detailed version, see the full paper.
