Denial of Service

Defining Denial of Service

Denial of Service or DoS attacks are when malicious parties try and overwhelm a system or network. This can be done by sending more requests than it can process or sending more traffic than the system can handle. Normal DDoS attacks target a single system or server, however blockchains are very decentralized systems so they are harder to bring down, but not impossible.

Transaction Flooding

Transaction Flooding is the most common way to perform a DoS attack on a blockchain. All transactions sit in a mempool waiting to be executed. If an attack sends countless spam transactions to the network, they can fill up the mempool with dummy transactions. This will cause legitimate transactions to sit in the mempool for much longer periods of time.

Impact

  • Node crashes: Each node on the blockchain has software running for processing the transactions received on the network. This means that the nodes must have all the resources to support the needs of the software running and if the node runs out of memory or CPU, it may crash or fail to bring it to the offline state until a restart is performed.

  • Software failure: The blockchain node has software running to process the transactions. The software has a limit to the number of transactions it can store in the memory pool, thus causing issues if the transaction floods exceed those limits.

  • Network congestion: In a blockchain network, each node that receives transactions sends a copy of it to its neighbor, thus each node receives multiple copies of the same transaction. In a transaction flooding attack large transaction volumes are already created, and the peer-to-peer network amplifies it, thus resulting in a consumption of more network bandwidth.

  • Bloated ledger: Transaction flooding DDoS attack has a permanent impact on the blockchain network in the form of the ledger being overloaded with span transactions as each node stores a copy of all the transactions to look for double-spending.


Solutions

The simplest solution to prevent DoS attacks is to ensure that all nodes have enough processing power, sufficient storage, and network bandwidth. Also, the smart contract can have a failsafe in the code the prevents any transactions from entering the mempool if the mempool exceeds a certain size. The more decentralized a blockchain network is, the hard it is to perform a DDoS attack.

Demonstration of Attack

The premise of this attack is to claim the contract by using another contract. A contract will claim the original contract and not allow for other people to claim the contract or receive their money back. It denies of all service to the original contract.

Contract Layout

This file actually has two contracts Winner of Ether (red arrow) and Attack (green arrow).

The claimContract() function (yellow arrow) allows anyone to claim the contract as long as they pay more than the current amount on the contract (similar to a bidding war).

The Attack contract requires the address of the WinnerOfEther contract. However, the Attack contract does not provide any way for another account to claim the contract. Once the Attack contract has control of the WinnerOfEther, all funds in the contract are frozen and no one can withdraw funds.

First deploy the WinnerOfEther contract. Currently the balance is 0 and there is no winner.

Then, swap to the Attack contract to get ready to deploy. In order to deploy you need the address of the WinnerOfEther contract. Copy and paste that and then deploy.

Swap to a different account and enter an amount of 10 ETH. After clicking claimContract, the balance and winner will be updated accordingly.

Swap to a different account and enter an amount that is greater than 10 ETH. Then on the Attack contract press attack.

Notice that now the balance is 11 ETH and the address is NOT the address that you sent the attack from. It is the address of the Attack contract.


Now, swap back to the first account and enter an ETH amount greater than 11 and press claimContract.

An error message will pop up not allowing any account to claim the contract.

Notice in Ganache that after the two contract creations, there are only two contract calls. The first one (value of 10 ETH) is the initial claiming of the contract. The second on is the Attack contract claiming the contract (value of 11 ETH). The third transaction never went through because the Attack contract did not allow it.

Solution

One potential solution is to add a withdraw feature. This allows for any account that every claimed the contract or sent in money to withdraw their money, as long as they are not the current holder of the contract.

Contract Layout

This contract is very similar to the one above, however it has a crucial withdraw function. This allows anyone who is not the current winner to withdraw their funds.

Swap to a different account and deploy the second contract.

Enter in 10 ETH and claimContract. You can now view the current balance and current winner.

Swap to a different account and enter in 11 ETH and claimContract. The balance and winner are both updated.

Swap back to the first account and copy the address. Enter that address into the balances field. By clicking the balances button, the balance of that account will be shown. Note: the 0x989... account is no longer the winner of the contract but they still have money invested.

On the 0x989... account press withdraw to retrieve their balance. Notice that in the previous screenshot the number next to the account was 89.989, and after withdrawing the balance of the account was 99.989.

Also notice the overall balance of the WinnerOfEther contract is 11, and in the previous screenshot it was 21.

Finally after inputting the 0x989... account into the balances field and pressing the button, the balance is 0. This means that this account no longer has any investment in the WinnerOfEther contract.

References

Behnke, Rob. “How Blockchain Ddos Attacks Work.” Halborn, 26 Oct. 2021,

https://halborn.com/how-blockchain-ddos-attacks-work/.

Duan, L., Sun, Y., Zhang, K., & Ding, Y. (2022). Multiple-layer security threats on the

Ethereum blockchain and their countermeasures. Security and Communication Networks,

2022, 1–11. https://doi.org/10.1155/2022/5307697


Nils Amiet. 2021. Blockchain Vulnerabilities in Practice. Digit. Threat.: Res. Pract. 2, 2, Article 8

(March 2021), 7 pages. https://doi.org/10.1145/3407230


Oualid, Z. “Transaction Order Dependence Attack in Smart Contract.” Get Secure World,

13 May 2022, https://www.getsecureworld.com/blog/transaction-order-dependence-attack-in-smart-contract/.