What are Eclipse Assaults in Blockchain?

Introduction to Eclipse Assaults

An Eclipse Assault happens when an attacker is ready to isolate a goal node in a decentralized community, on this case, the Ethereum blockchain, such that every one incoming and outgoing connections undergo the attacker.

This enables the attacker to filter the node’s view of the blockchain and manipulate its actions, probably main to numerous varieties of exploitation. Eclipse Assaults exploit the peer-to-peer nature of decentralized networks and pose critical safety dangers.

This rationalization goals to research how such an assault might theoretically be executed on an Ethereum node

Meta Data

• Assault Vector: Eclipse Assault on Ethereum P2P Community
• Goal: Ethereum Node (Model <= geth v1.8.0)

Instruments and Assets:

• Two host techniques, every with a single IP deal with
• Ethereum Node ID generator
• Timing and synchronisation instruments for NTP manipulation
• Packet crafting instruments for pressured reboot

Assault Process

Pre-Assault Section

• Node ID Technology: Generate hundreds of Ethereum Node IDs utilizing minimal computational assets, due to Ethereum’s use of ECDSA public keys.
• Node ID Filtering: Rigorously choose Node IDs which can be extra doubtless to hook up with the goal primarily based on identified biases in Ethereum’s peer-connection logic.
• Preparation for Connection Monopolization: Be certain that each attacking host techniques are arrange and able to monopolize all connections to and from the goal.

Execution

Stage 1: Isolate Goal

• Pressured Reboot: Make the most of a packet crafting instrument to ship a packet-of-death to the goal Ethereum node, triggering a reboot.
• Quick Connection: Because the goal node reboots, set up outgoing connections to the goal from every of the attacker’s host techniques.
• Connection Monopolization: Occupy all connection slots on the goal node, placing the node into an eclipse state. This makes the goal node imagine that it’s nonetheless a part of the bigger Ethereum community, when in actuality it’s remoted.

Stage 2: Manipulate Goal

• Blockchain View Manipulation: Filter the goal’s view of the blockchain, enabling the attacker to control what blocks and transactions the goal sees.
• Time Manipulation: Use NTP to control the goal’s system clock, making it greater than 20 seconds sooner than actual time.

Submit-Assault Section

• Exploitation: With the goal within the eclipse state, provoke double-spending or egocentric mining assaults, leveraging the goal’s mining energy to at least one’s benefit.
• Sensible Contract Manipulation: Use the manipulated view to trick the goal into making false transactions in smart contracts successfully permitting the attacker to have interaction in fraud.

Assault Aims

• Isolate the Goal: Make the goal node solely hook up with the attacker’s nodes.
• Manipulate Blockchain View: Management the data that the goal receives about transactions and blocks.
• Exploit Vulnerabilities: Make the most of the eclipsed node’s assets for double-spending or egocentric mining.
• Sensible Contract Manipulation: Make fraudulent transactions in weak good contracts.
• Depart No Hint: Disconnect and launch all monopolized connections, reverting the goal to its regular state.

Countermeasures

• Discontinue ECDSA as a Uniform Node Identifier: One of many essential vulnerabilities that enables the Eclipse Assault to happen is the usage of the ECDSA public key as a uniform node identifier.
• Undertake a Composite Identifier: Reasonably than solely counting on the ECDSA public key, use a composite identifier comprising each the IP deal with and the general public key. This provides an additional layer of complexity for an attacker searching for to monopolize all connections to a goal node.
• Replace to Safe Variations: Variations of geth launched after v1.8 have applied a number of safety measures geared toward stopping such assaults. Due to this fact, updating to a newer model is strongly advisable for enhanced safety.