Table of Contents
- Severity: High
- Description:
The attacker can subvert the blockchain by creating a large number of pseudonymous identities (i.e. Fake user accounts) and push legitimate entities in the minority. Such virtual nodes can act like genuine nodes to create a disproportionately large influence on the network. This may lead to several other attacks like DoS, DDoS, etc. - Recommendation:
Increase the maximum number of connections to a node and limit the number of hosts with a single IP address - Reference:
Preventing Sybil Attack in Blockchain using Distributed Behavior Monitoring of Miners
- Severity: High
- Description:
The attacker monopolizes all of the victim’s incoming and outgoing connections, isolating the victim from the rest of her peers in the network. - Recommendation:
Increase the maximum number of connections to a node and limit the number of hosts with a single IP address - Reference:
Eclipse Attacks on Bitcoin’s Peer-to-Peer Network
Low-Resource Eclipse Attacks on Ethereum’s Peer-to-Peer Network
- Severity: Low
- Description:
The attacker passively listens to network communications to gain access to private information, such as node identification numbers, routing updates, or application-sensitive data. The attacker can use this private information to compromise nodes in the network, disrupt routing, or degrade application performance. - Recommendation:
Encrypt communications using encryption protocols, such as TLS. - Reference:
The RLPx Transport Protocol
- Severity: Medium
- Description:
a denial-of-service attack (DoS attack) is a cyber-attack in which the perpetrator seeks to make a machine or network resource unavailable to its intended users by temporarily or indefinitely disrupting the services of a host connected to the Internet. Denial of service is typically accomplished by flooding the targeted machine or resource with superfluous requests in an attempt to overload systems and prevent some or all legitimate requests from being fulfilled. - Recommendation:
a. Increase the number of nodes in different regions.
b. Prevent malformed parameters from crashing the software.
c. Limit memory queue size.
- Severity: Low
- Description:
BGP hijacking (sometimes referred to as prefix hijacking, route hijacking, or IP hijacking) is the illegitimate takeover of groups of IP addresses by corrupting Internet routing tables maintained using the Border Gateway Protocol (BGP). - Recommendation:
Increase the number of nodes in different regions. - Reference:
BGP Hijacking Hijacking Bitcoin: Routing Attacks on Cryptocurrencies
KlaySwap crypto users lose funds after BGP hijack
- Severity: Low
- Description:
The Alien attack vulnerability was first discovered by SlowMist Team, also known as peers pool pollution, which refers to an attack method that induces nodes of the same kind of chain to invade and pollute each other. The main reason for the vulnerability is that the system of the same kind of chain does not identify non-similar nodes in the communication protocol. - Recommendation:
Add network identification to P2P connection protocol, such as ChainID in Ethereum, and Magic in Bitcoin. - Reference:
冲突的公链！来自 P2P 协议的异形攻击漏洞
- Severity: High
- Description:
Timejacking exploits a theoretical vulnerability in Bitcoin timestamp handling. During a timejacking attack, a hacker alters the network time counter of the node and forces the node to accept an alternative blockchain. This can be achieved when a malicious user adds multiple fake peers to the network with inaccurate timestamps. - Recommendation:
A timejacking attack can be prevented by restricting acceptance time ranges or using the node’s system time.
- Severity: Low
- Description:
The attacker passively listens to network communications to gain access to private information, such as node identification numbers, routing updates, or application-sensitive data. The attacker can use this private information to compromise nodes in the network, disrupt routing, or degrade application performance. - Recommendation:
Encrypt communications using encryption protocols, such as HTTPS.
- Severity: Medium
- Description:
Node crashes by constructing malformed data requests - Recommendation:
a. Prevent malformed parameters from crashing the software.
b. Limit memory queue size.
- Severity: Low
- Description:
The Ethereum black valentine's day vulnerability was first discovered by SlowMist Team. The hacker can steal cryptocurrency by RPC request when a remote node unlocks its wallet. - Recommendation:
a. Disable external access to the RPC interface.
b. Disable wallet functionality on public nodes. - Reference:
以太坊生态缺陷导致的一起亿级代币盗窃大案
- Severity: Low
- Description:
Cross Site Scripting (XSS) / Template injection / Third-party component vulnerability / HTTP parameter pollution / SQL injection / XXE entity injection / Deserialization vulnerability / SSRF vulnerability / Code injection / Local file contains / Remote file contains / Command execution injection / Buffer overflow / Formatted string - Recommendation:
Perform interface pentest. - Reference:
SlowMist Exchange Security Audit Program
- Severity: Low
- Description:
The hacker tricks the victim into opening a malicious webpage, connects to the cryptocurrency wallet RPC port through a cross-domain request, and then steals crypto assets. - Recommendation:
Prohibit nodes from enabling cross-domain access.
- Severity: High
- Description:
A Long-Range attack is an attack scenario where the adversary goes back to the genesis block and forks the blockchain. The new branch is populated with a partially, or even completely, different history than the main chain. The attack succeeds when the branch that is crafted by the adversary becomes longer than the main chain, hence it overtakes it. Long-Range attacks fall into three different categories, namely Simple, Posterior Corruption, and Stake bleeding. In some sense, Long-Range attacks in PoS protocols are related to selfish mining attacks of PoW protocols as the attacker in both cases is adding blocks that she keeps secret. Obviously, selfish mining attacks cannot go back to the genesis block of PoW protocols as the computational effort needed is prohibiting, therefore, the impact that they may have is limited. Nevertheless, both attacks fork the main chain and try to append forged blocks where the attacker potentially includes different transactions. - Recommendation:
The exchange or receiver should complete payment after the transaction was confirmed by enough blocks. - Reference:
A Survey on Long Range Attacks for Proof of Stake Protocols
- Severity: High
- Description:
Also referred to as Short-Range attack relies on bribing validators or miners to work on specific blocks or forks. By doing that, the attacker can present arbitrary transactions as valid and having dishonest nodes paid to verify them. By paying them an amount equal to or more than the block rewards (in case the block is reverted by the network), it provides an incentive high enough for miners to work on the attacker’s blocks or chain. This case of bribery attacks also known as P+epsilon attack states that it is possible to bribe users without having to pay them, as the system will award the bribe to the dishonest nodes by making that branch the main chain. For these cases, the attacker faces a more significant problem as in case the malicious branch is reverted for some reason (attacker cannot continue the bribe, dishonest nodes stop working on that branch) the attacker would have to pay an enormous amount of bribes as the bribes will accumulate for every maliciously minted block. In PoS systems, these kinds of attacks are feasible and can be expanded to the nothing at stake problem. - Recommendation:
In both cases, PoS tackles this issue by either enforcing a slashing condition or by releasing violators from their position. - Reference:
A Survey on Long Range Attacks for Proof of Stake Protocols
- Severity: High
- Description:
A race attack is executed when an attacker creates two conflicting transactions. The first transaction is sent to the victim, who accepts the payment (and sends a product, for instance) without waiting for confirmation of the transaction. At the same time, a conflicting transaction returning the same amount of cryptocurrency to the attacker is broadcast to the network, eventually making the first transaction invalid. - Recommendation:
The exchange or receiver should complete payment after the transaction was confirmed by enough blocks. - Reference:
blockchain-attack-vectors
- Severity: High
- Description:
Liveness Denial is a form of Denial of Service attack in PoS protocols. In this attack, some or all of the validators decide to take action and purposefully block transactions by stopping publishing blocks. By avoiding to perform their validator duties, the blockchain will come to a halt as new blocks would not be able to be validated and published in the blockchain. A liveness requirement which slowly drains the stake of inactive validators will ensure that even if the majority of validators are either offline or performing a liveness denial attack, they would not compromise the network. - Recommendation:
In cases where liveness cannot be assessed, the community will be able to decide (off-chain communication) to fork the blockchain and remove the inactive validators. In all cases, validators who conduct this type of attack jeopardize their position in the network as validators and their stake if a slashing condition exists - Reference:
A Survey on Long Range Attacks for Proof of Stake Protocols
- Severity: High
- Description:
Censorship in blockchains is big a thorny issue that has sparked many discussions as it can be considered an attack or a feature simultaneously, depending on the nature of the blockchain. Validators have control of which transactions will be added to a block which gives them the power to blacklist certain addresses. Transactions lie in the transaction pool, and validators take transactions and add them to their soon-to-be-published block. Validators might decide to remove some transactions from their blocks. In the scenario of a single validator performing the censorship, some transactions might be delayed or be invalidated due to time constraints. The danger of censorship becoming more real is amplified once the number of validators performing this attack increases. - Recommendation:
Liveness requirements, can ensure the eventual process of transactions and eliminate censorship on the blockchain. In addition to that, the protocol can punish nodes which do not create blocks in a protocol-defined order. In another more effective solution, Zero-knowledge succinct non-interactive arguments of knowledge (zk-SNARKs), can be used to hide the identity of the transaction sender - Reference:
A Survey on Long Range Attacks for Proof of Stake Protocols
- Severity: High
- Description:
A Finney attack is possible when one transaction is premined into a block and an identical transaction is created before that premined block is released to the network, thereby invalidating the second identical transaction. - Recommendation:
The exchange or receiver should complete payment after the transaction was confirmed by enough blocks. - Reference:
blockchain-attack-vectors
- Severity: High
- Description:
Vector76 is a combination of Race attack and Finney attack. In this case, a malicious miner creates two nodes, one of which is connected only to the exchange node and the other of which is connected to well-connected peers in the blockchain network. After that, the miner creates two transactions, one high-value and one low-value. Then, the attacker premines and withholds a block with a high-value transaction from an exchange service. After a block announcement, the attacker quickly sends the premined block directly to the exchange service. It along with some miners will consider the premined block as the main chain and confirm this transaction. Thus, this attack exploits the fact that one part of the network sees the transaction the attacker has included into a block while the other part of the network doesn’t see this transaction. After the exchange service confirms the high-value transaction, the attacker sends a low-value transaction to the main network, which finally rejects the high-value transaction. As a result, the attacker’s account is credited the amount of the high-value transaction. Though there’s a high chance for success with this type of attack, it’s not common because it requires a hosted e-wallet that accepts the payment after one confirmation and a node with an incoming transaction. - Recommendation:
The exchange or receiver should complete payment after the transaction was confirmed by enough blocks. - Reference:
blockchain-attack-vectors
- Severity: High
- Description:
Also called a blockchain reorganization attack. May happen even in the case of multiple confirmations but requires a huge amount of computing power from the hacker. In this case, a malicious user sends a transaction to a recipient and at the same time mines an alternative fork with another transaction that returns the same coins. Even if the recipient considers the transaction valid after n confirmations and sends a product, for instance, the recipient may lose money if the attacker releases a longer chain and gets the coins back. - Recommendation:
The exchange or receiver should complete payment after the transaction was confirmed by enough blocks. - Reference:
blockchain-attack-vectors
- Severity: High
- Description:
Also known as majority attack. In PoW systems, the entity which controls the majority of the hashing power at a specific timeframe can have complete control over the blockchain, for instance, she can fork the main chain and start mining on her branch. Slowly and steadily, the adversary will be able to outpace the main chain and have her branch take its place. Since in PoW protocols block generation is probabilistic, there are many chances to have conflicting branches, which diminish as we move past the 51% barrier. Therefore, the adversary will have the main chain, but branch reversions will often happen at that point. In PoS protocols this attack is still viable but with a slightly different impact. It is possible for one validator or a coordinated set of validators to own more than 34% (for BFT PoS) of that blockchain’s stake. In this case, a majority attack can impact the blockchain by performing finality reversion, where an already finalized block is being challenged by finalizing another competing block, causing Liveness Denial or Censorship. - Recommendation:
The exchange or receiver should complete payment after the transaction was confirmed by enough blocks. - Reference:
A Survey on Long Range Attacks for Proof of Stake Protocols
- Severity: High
- Description:
Also known as precomputation attack. It is an implementation-specific issue and affects PoS systems. By exploiting the lack of randomness in the slot leader election process, a slot leader is capable of manipulating the frequency of them being elected in subsequent blocks. This issue can be solved by enforcing randomness to the process and minimizing or even eliminating influence factors of this process which are controlled by the validators. - Recommendation:
The exchange or receiver should complete payment after the transaction was confirmed by enough blocks. - Reference:
A Survey on Long-Range Attacks for Proof of Stake Protocols
- Severity: High
- Description:
In the early version of Peercoin protocol, the user’s stake would accumulate more weight the more time it was staked without having any time restrictions. Given enough time, an attacker would have accumulated enormous amounts of stake in the system which would allow them to take over the network. The coin age mechanism worked as an amplification technique to the stake of its validators. As a mitigation technique, the coin age mechanism was capped at a certain amount of time or was completely removed. - Recommendation:
- Reference:
A Survey on Long-Range Attacks for Proof of Stake Protocols
- Severity: High
- Description:
In selfish mining attacks also known as block withholding, the adversary mines blocks in their own fork of the blockchain without publishing them to the network. Once the attacker has computed a desired number of blocks, they are released to the network and aim to revert the main chain to that of the attackers. The purpose of this attack can be twofold; a) disruption of the network by wasting resources of honest nodes and b) increase the rewards collected by the dishonest nodes. - Recommendation:
The former incentive of the attack affects purely PoW blockchains. A PoS blockchain would not be disrupted by this incentive. The latter incentive affects both protocols and can be mitigated by applying slashing conditions, or by removing violators from their position of power which will cause them to forfeit future rewards. - Reference:
A Survey on Long-Range Attacks for Proof of Stake Protocols
- Severity: High
- Description:
A block producer produces several blocks on a block height, this could be a precursor to a long-range attack or a short-range attack. - Recommendation:
Economic sanctions on producers.
- Severity: High
- Description:
Common attack methods: Analytic Attack / Implementation Attack / Statistical Attack / Brute Force / Frequency Analysis and the Ciphertext Only Attack / Known Plaintext / Chosen Ciphertext / Chosen Plaintext / Meet in the Middle / Man in the Middle / Birthday attack / Replay attack / Collision attack - Recommendation:
Don't use unknown encryption library.
- Severity: High
- Description:
Since much cryptography depends on a cryptographically secure random number generator for key and cryptographic nonce generation, if a random number generator can be made predictable, it can be used as a backdoor by an attacker to break the encryption. - Recommendation:
A cryptographically secure pseudorandom number generator (CSPRNG) or cryptographic pseudorandom number generator (CPRNG)[1] is a pseudorandom number generator (PRNG) with properties that make it suitable for use in cryptography. - Reference:
Cryptographically-secure pseudorandom number generator
- Severity: Low
- Description:
A type of attack where an attacker can use Hash(message1) and the length of message1 to calculate Hash(message1 ‖ message2) for an attacker-controlled message2, without needing to know the content of message1. - Recommendation:
Algorithms like MD5, SHA-1 and most of SHA-2 that are based on the Merkle–Damgård construction are susceptible to this kind of attack, don't use them. - Reference:
Length extension attack
- Severity: High
- Description:
Insufficient collision resistance of the hash function results in the original signature content being forged. - Recommendation:
Don't use hash algorithms like MD5, SHA-1, most of SHA-2, Curl. - Reference:
Signature Forgery Attacks on the IOTA Cryptocurrency
- Severity: High
- Description:
Also known as Double Spend attack. Double spending is one of the problems that blockchain technologies attempt to solve since their very inception. Most, if not all of the attacks in the blockchain, aim to perform a double spend at some point in their execution. In this attack scenario, an attacker attempts to spend the same currency at least two times, hence double-spend. This attack is definitely not possible in the physical terms of currency. It is not possible to buy a resource from one vendor and then spend the exact same coins to another vendor. The attacker attempts to perform a transaction, wait for the merchant to approve it, and then reverts it and spends the same currency in another transaction. In blockchains, this can be achieved by presenting a conflicting transaction possibly in a different branch. BFT systems with the use of absolute finality are considered to be robust against the double spend problem. - Recommendation:
a. Check whether a UTXO has been spent.
b. Use nonce to prevent transaction replay.
- Severity: High
- Description:
Transaction malleability is an attack that lets a person change a Bitcoin transaction’s unique ID before confirmation on the Bitcoin network. This change makes it possible for the person to pretend that a transaction didn’t happen. In the case of Bitcoin exchanges, it can be used to make a double deposit or double withdrawal. Signature Malleability The first form of malleability is in the signatures themselves. Each signature has exactly one DER-encoded ASN.1 octet representation, but OpenSSL does not enforce this, and as long as a signature isn't horribly malformed, it will be accepted. In addition for every ECDSA signature (r,s), the signature (r, -s (mod N)) is a valid signature of the same message. ScriptSig Malleability The signature algorithm used in Bitcoin does not sign any of the scriptSig to create the signature. While signing the whole scriptSig would be impossible - the signature would be signing itself - this does mean that additional data can be added such that it will be pushed on the stack prior to the required signatures and public keys. Similarly, OP_DROP can be added to leave the stack exactly as before prior to scriptPubKey execution. - Recommendation:
Check if the signature library is malleable. - Reference:
Transaction_Malleability
bip-0066-Strict DER signatures
eip-2-Homestead Hard-fork Changes
- Severity: Low
- Description:
Make tokens unavailable to token recipients by specifying the block height at which utxo can be spent. - Recommendation:
Check whether a transaction is time-locked when receiving coins. - Reference:
XMR transfer lock
- Severity: High
- Description:
Initiate a specially structured transaction to conduct a false transfer, resulting in a real top-up in the exchange. - Recommendation:
a. Check all fields in the transaction event log.
b. The exchange or receiver should complete payment after the transaction was confirmed by enough blocks. - Reference:
USDT false top-up
EOS false top-up
XRP false top-up
ETH false top-up
BTC RBF false top-up
Understanding how fake top-up attacks break through exchanges' layers of defense
Solana false top-up
THORChain false top-up
UTXO multisig false top-up
- Severity: High
- Description: A rug pull is a malicious maneuver in the cryptocurrency industry where crypto developers abandon a project and run away with investors’ funds. Rug pulls usually happen in the decentralized finance (DeFi) ecosystem, especially on decentralized exchanges (DEXs), where malicious individuals create a token and list it on a DEX, then pair it with a leading cryptocurrency like Ethereum.
- Recommendation:
Check if the dev team renounces ownership of the blockchain.