Skip to main content

Attack Vectors and Mitigation

Process attack vectors​

The authenticity of an ICS Cluster​

According to the design of the MOI network, ICS is initiated by the node which picks up the transaction (the Operator). Considering that a faulty node initiated the ICS request, it can share a wrong validator set rendering the ICS invalid.

Defense:

  1. Whenever a node receives a request ICS proposal it also checks the authenticity of the validator set. If all conditions are met only then the node joins the Quorum.

ICS Request Attack​

Context: According to the Modulated trust design, when a node sends an ICS proposal to another peer, the peer responds backs to the proposal based on its availability. If the peer is available, it accepts the proposal and waits for a stipulated time to start the consensus engine (this wait time is yet to be decided).

Attack Case: A Malicious node may send bogus ICS Proposal requests and lock the peer for wait time. This process may occur very often, and the peer will be deadlocked for no real outcome, thereby denying services for legitimate ICS requests from other nodes in the network.

Defense: “Jail Period at network Level and Slashing”

  1. If an ineligible node is about to propose, it should be invalidated by the receiving node based on the lookup in the depositor contract and jail contract
  2. If a node receives n continuous unsuccessful ICS requests, the further ICS proposals by the said node are rejected.
  3. The node will be put under a jail period (duration is yet to be finalized) to unable the node from further creating proposals.

Distributed Denial of Service Attack​

A DDoS attack can be caused at two levels in the MOI network:

  1. Network Level: Since all nodes’ information is made available, the Attacker can make the eligible nodes unreachable or unavailable. Thus, affecting the node’s availability for ICS creation.
  2. Consensus Level (51 % attack): Since attackers need to bring down only 33% of nodes in the network, and specifically the ICS cluster, it is easy to disrupt the Quorum and inhibit the cluster from achieving the consensus on a given Tesseract.

Defense:

  1. To overcomes DDoS attacks, validator ports are not exposed publicly, and every validator node needs to follow sentry node architecture in the MOI network (similar to Tendermint).
  2. A final line of defense is “Tesseract-cementing”. As Tesseracts are confirmed, the node marks the new height for every account associated with the Tesseract. Nodes will refuse the replacement of an already confirmed Tesseract. Attempts to fork after previous confirmation of a Tesseract will immediately fail.

Block Withholding Attack​

Malicious nodes can intentionally mask, forge, or withhold important information that needs to be relayed across the network. Some of the known attacks of this nature are “The Finney Attack” and “Block Withholding Attack”.

The Finney attack: The Finney attack is a variant of the double-spending attack in which a miner delays block propagation to double-spend his transaction. The miner generates a transaction, computes a block, and chooses not to relay the block. In the meantime, he generates a duplicate of his previous transaction and sends it to a recipient. After the recipient accepts the transaction and delivers the product, the miner publishes his previous block with the original transaction in it. Therefore, the previous transaction sent to the recipient becomes invalid and the miner successfully double-spends the transaction.

Defense:

  1. Every validator in ICS will Gossip the committed Tesseract across the network, this comes with some cost in terms of network bandwidth but will help us achieve near-immediate finality and secure the network from double-spending. Also, this is affordable in the context of Modulated trust since not all nodes in the network are involved.

Consensus Delay Attack​

In this attack, an attacker may inject false blocks to add latency or prevent peers from reaching a consensus about the state of the network. Let us analyze this attack in PBFT systems:

A major component of processing a transaction is the exchange of messages and signatures among participating replicas. Especially, in the prepare and commit phase, each replica sends its signatures to every other replica.

The Sybil nodes can also send bogus signatures to the other replicas during the prepare phase and the commit phase. Since each replica is then required to verify signatures, therefore, bogus signatures will cause additional verification overhead.

If Sybil nodes continue to send such signatures, they can stall the completion of the commit phase and eventually cause a delay in the commit phase. As a result, the primary will not receive the required number of approvals for the transaction verification. This will cause consensus delay and reduce the throughput of the network.

Defense:

  1. Every validator maintains the Peer Round Details and PoL (Proof of Lock) w.r.t that peer so that signatures are validated against PoL details.

Network attack vectors (based on the nature of the network)​

DNS Attack​

For this attack, an adversary can either inject an invalid list of seeder nodes in the open-source Blockchain software, or poison DNS cache at the resolver. By default, the Blockchain software client has a list of seeders that allow the network discovery. If the attacker injects a fake list of seeders, the user will be compromised. As a result, the adversary can potentially isolate Blockchain peers and lead them to a counterfeit network.

Defense:

  1. DNS Cache can be secured by following the practices specified in DNSSEC (Secure the content on bootstrap.MOI.technology with DNSSEC and ensure that the list is updated as per the governance of the MOI protocol)

Sybil Attack​

A Sybil attack is a person creating a lot of nodes on the network, possibly thousands on a single machine, in order to get a disproportionate vote on networks where each node gets an equal vote.

Defense:

  1. Sybil Attack can be mitigated using a staking mechanism built on PBFT, voting power in PBFT can be based on the account balance. We have achieved this by designing PoX such that each validator node in the MOI network needs to commit his/her real identity, followed by enough MOI tokens and compute resources.

Eclipse Attack​

An Eclipse Attack is a means of attacking a decentralized network through which an attacker seeks to isolate and attack a specific user(s), rather than attack the whole network (as in a Sybil Attack). A successful Eclipse Attack enables a would-be bad actor to isolate and subsequently prevent their target from attaining a true picture of real network activity and the current ledger state.

Defense:

  1. Limit the number of nodes per IP Address/Machine
  2. Increase the number of outbound connections, outbound connections should be selected based on random walk mechanisms, so that inbound information is not concentrated by one node or just a few nodes.

Transaction Flooding Attack​

Transaction flooding is simply sending as many valid transactions as possible in order to saturate the network’s capacity to handle transactions. Usually, an attacker will send transactions to other accounts they control so it can be continued indefinitely.

Defense:

  1. Mempool should be organized based on transaction price thus low-value transactions are not picked by validators immediately, thus relieving them from this low-cost attack.