INTRODUCTION

Blockchains technologies are relatively new and there are many news stories of people losing money through compromises in the components of blockchain ecosystems. Blockchain technologies are not invulnerable and have actually many known vulnerabilities just as with any software.

This article describes the most common components of a blockchain ecosystem and the vulnerabilities that they can contain. The greater number of features blockchain offers, the larger the attack surface becomes.

Example:-

Ethereum

IT has a virtual machine called the EVM (Ethereum Virtual Machine), has a virtual machine called the EVM. The EVM specification defines over 140 different instructions that smart contract programmers can use. There have been many real-world cases of decentralized applications, also known as DApps, leveraging vulnerable smart contracts that resulted in stolen funds. It is also worth noting that vulnerabilities can exist in any component of a blockchain ecosystem, not just smart contracts.

BLOCKCHAIN ECOSYSTEM COMPONENTS

A blockchain ecosystem contains multiple components. There is usually core blockchain software that consists of client software such as Go Ethereum or Parity in the case of Ethereum.

Blockchain systems usually contain a wallet, which can be implemented in software or hardware. A node and software wallet may be bundled together in the same software.

Cryptocurrency exchanges

A cryptocurrency is a digital currency that is secured by cryptography. Exchanges can use hardware security modules to secure private keys. These exchanges frequently support over a hundred different cryptocurrencies. An exchange requires at least one blockchain node for each supported cryptocurrency. These nodes allow the exchange to perform transactions across various cryptocurrencies, and monitor transactions done on the blockchain to know when it has received cryptocurrencies.

Core Blockchain Vulnerabilities

1. Denial of Service :- Proof-of-work block chains with a block target that automatically adjusts, may be vulnerable to a denial of service attack. If no minimum target is defined, an uncaught floating-point underflow may occur and the block target may be rounded to zero, thus making new blocks impossible to mine and rendering the blockchain useless.
2. Underlying Cryptosystem Vulnerabilities : – Blockchain wallets usually work with a public and private key pair for signature and are as secure as the underlying cryptosystem they use. The public-key algorithm are :-
3. ECDSA
4. EdDSA
5. Schnorr
6. ElGama

To reduce the attack surface, it is necessary to use a library that implements the required cryptosystem with side-channel attack protections.

3. Improper Blockchain Magic Validation :- A blockchain’s magic value is used to uniquely identify a chain, thus binding transactions to a specific chain. Node software must check whether received transactions have the expected magic value, attributable to the current chain. If there is no such check, then an attacker can replay a transaction originally performed on another chain, thus creating transactions meant for another chain.
4. Public-key and Address Mismatch :- A blockchain wallet’s public key can usually be derived from the wallet’s address. However, some implementations truncate the public key to derive the address. If addresses are not bound to a specific key pair, then this can become a problem, because multiple key pairs exist with the same wallet address.

Smart Contract Vulnerabilities

1. Reentrancy :- A reentrancy vulnerability can be exploited when a contract function F whose purpose is to withdraw funds, synchronously calls another untrusted contract’s default function
2. Arithmetic Issues :- The Solidity smart contract language does not catch integer overflows by default. If uncaught, then overflows can lead to unexpected behavior. Unsigned integers are represented with 256 bits in Solidity. Therefore, an arithmetic operation on an unsigned integer that causes the result to be greater than 2²⁵⁶ −1 or less than 0 may be exploited.
3. Visibility Issues :- The default visibility is public for functions in Solidity. If a function’s visibility is not explicitly marked, then a developer can easily conclude that the function is private while it is actually public, causing unexpected behavior such as letting an attacker calls supposedly private code.
4. Weak Randomness :- Generating random numbers in smart contracts is a hard problem. Smart contract developers who need random numbers may be tempted to use predictable chain data as a source of randomness.

 Conclusion

Blockchains are not invulnerable, and one should use a mix of dedicated tools for smart contracts and general software analysis tools, such as static code analyzers for core blockchain, to automatically detect simple issues. Good practices, such as software testing, also apply to blockchain development. Thorough code reviews or third party security audits should be performed to maximize detection of more complex vulnerabilities.