As digitalization progresses, the security of the information we store on our devices or servers every day is also becoming increasingly important.
This applies to both private individuals and companies. New technologies are therefore always put to the test in terms of information security. In this blog post, we review what information security goals blockchain can support. We then look at which potential attack scenarios on blockchain technology are possible. We differentiate between attacks on the blockchain and attacks on users.
When it comes to the properties of the blockchain, the term security is often discussed. A system is information secure if it doesn’t assume any conditions that lead to an unauthorized change or acquisition of information (Eckert, 2006). To make the requirements of information security tangible, protection goals are defined. These general goals allow organizations to categorize their own information and systems according to their need for protection. The most well-known information security goals are confidentiality, integrity, and availability, and expanded goals include authenticity, nonrepudiation, accountability, and privacy (Eckert, 2006). In this section, we examine the ability of blockchain systems to meet these goals. For each goal, we start with classic blockchains such as Bitcoin and Ethereum and then describe how the ability to meet the goal can be influenced by specific design decisions.
The protection objective of confidentiality means that unauthorized access to information on the blockchain is not possible. The blockchain is characterized by its transparency, which contributes in large part to building trust in the network. It’s therefore a conscious decision that no authorization is required to access the transaction data. The secret private keys are adequately secured using the asymmetric cryptosystems mentioned earlier. In this way, the protection objective is sufficiently fulfilled. Should a use case require transactions to be kept secret, confidentiality can be increased with the use of technologies such as zk-SNARKs. For companies, the use of private blockchains is also a good way to increase confidentiality.
The protection objective of integrity is meant to ensure that information on the blockchain is correct and that the system functions correctly. With this protection goal, the blockchain can play to its strengths. Thanks to the cryptographic methods used, the data structure is extremely robust to subsequent manipulations and changes. Strictly checking compliance with consensus rules also ensures that the system is working correctly.
For the protection goal of availability, information and systems must be available to authorized users when they want to use them. Here, too, the blockchain can score points with its special structure. Decentralized distribution ensures that a blockchain is never offline, but history has shown that transactions can be delayed when the network is congested. Thus, the scaling problem can be seen as an obstacle to the complete fulfilment of the protection objective of availability.
In the case of authenticity as a protection goal, it must be ensured that a communication partner is really the person they are believed to be. This works with proof of identity. At the same time, a communication partner must be sure that the information received is authentic and comes from the identified entity. The blockchain can ensure this goal by use of private keys. They can be used to create signatures that serve as proof of identity, and since these signatures are based on the content of the message, the recipient can be sure that the message is also authentic. However, bear in mind that users in blockchain systems usually hide behind pseudonyms. These must be linked to real names to link the network participants to real people.
The protection objective of accountability states that it’s possible to assign who triggered an action (e.g., service, process) in a system and is responsible for it. Here, too, the advantage of blockchain is that every action in the network is documented. Not only in transactions, but also in the use of smart contracts, it’s possible to check who initiated or called a contract.
The blockchain can also shine when it comes to the protection goal of nonrepudiation. To achieve this goal, it shouldn’t be possible to deny communication that happened with third parties. In the system, every transaction is meticulously recorded and stored in a way that can’t be manipulated, so a transaction that has taken place can’t be denied. Even in a blockchain system, where transactions are externally encrypted, the parties involved have access to a transaction and can prove that it has been carried out.
Privacy as a protection objective requires that communication processes are secret and anonymity is guaranteed. Pseudonymity can also be used here. Above all, this goal strengthens data protection. Privacy conflicts with other objectives, such as accountability and nonrepudiation. If privacy is desired, the blockchain can fulfill the goal with its pseudonymity. However, it should be noted that the requirements of the General Data Protection Regulation (GDPR) are not complied with under all circumstances, especially when it comes to the storage of personal data. In particular, the “right to be forgotten,” which requires that all data stored about a user can be deleted at any time, is at odds with the character of blockchain technology.
As we saw when we examined the suitability of blockchain in terms of protection goals, the technology can meet almost all security objectives very well in a suitable context. Adaptations for specific cases can be implemented through various design decisions in the development and configuration of the system. This includes, for example, the use of a private or permissioned blockchain. In this context, however, it’s useful to keep in mind the blockchain trilemma, which was presented by Vitalik Buterin in a blog post: https://vitalik.eth.limo/general/2017/12/31/sharding_faq.html.
The blockchain trilemma is the fact that a blockchain technology can only ever fulfill a maximum of two of the three properties of decentralization, scaling, and security. This means that if a blockchain is to be distributed in a decentralized manner and at the same time be fast, limitations on its security must be accepted. So, to realize a faster transaction speed in a large network, it would be necessary to save on the verification and validation process for the transactions. If you want to run a secure blockchain system, you must choose between decentralization and scaling. For example, Bitcoin and Ethereum in their current forms represent a decentralized and secure network with sufficient participants and a detailed validation and verification process. Both blockchains become slow and don’t scale sufficiently when there is a lot of traffic on the network. However, if the decision is made to focus on security and scale, it’s not possible to operate a large network. This is where a permissioned blockchain would be the right choice.
Despite the good performance of blockchain technology in terms of the protection goals of information security, blockchain doesn’t offer foolproof security. In the following section, we’ll introduce you to possible attack scenarios.
For attackers, there are two basic approaches to compromising the blockchain. In the first approach, the attacker targets the infrastructure of the blockchain systems. These attacks are very difficult to carry out in reality, but they are still theoretically possible. We’ll introduce you to the attacks on the blockchain in the first section. The second approach is to bypass the security mechanisms of the blockchain and directly attack the user to gain unauthorized access to the system. We describe these attacks on the user in the second section.
Attacks on the Blockchain
Attacks on the blockchain are considered successful if they enable double-spending (i.e., a break in the consensus on the network). Attackers have many motives to harm a blockchain. In most cases, financial interests are in the foreground, but sometimes, they may want to harm the project itself—for example, to negatively influence the price of a cryptocurrency. The attacks are almost always directed at the network. Attacks on the cryptographic methods used are considered practically unfeasible. Such attacks would only be feasible with the development of much more powerful computers such as quantum computers, and such attacks would also not only affect cryptocurrencies but all our communication on the internet. In the following sections, we present the types of attacks on the blockchain that are most often discussed.
The 51% Attack
The 51% attack, also known as majority attack, is the most famous of all attacks on the blockchain. This type of attack is a problem, especially in PoW. To perform one, a miner or mining pool must provide more than 50% of the computing power on the network. In general, such an attack is possible with less computing power, but the probability of success is lower. With the majority of power in the network, the attacker can decide what happens on the network, and a new transaction could be denied confirmation and thus prevented from execution. The attacker could also reject other miners’ blocks by not adding them to their own blockchain. In addition, double-spending would be possible by resetting transactions that have already been executed. However, resetting older transactions would still be difficult, as all subsequent blocks would then have to be recalculated. Very old transactions and blocks from a certain checkpoint are also hard coded into the source code of the client software.
Such an attack is more realistic than you might think. We have already mentioned in the mining pools section that the pool Ghash.io had crossed the 51% mark on the Bitcoin network in the past. Smaller blockchain projects are more likely to deal with 51% attacks. In May 2018, the Bitcoin Gold cryptocurrency fell victim to this type of attack, and there was $18 million in damage due to double spending.
For the larger networks such as Bitcoin and Ethereum, 51% attacks are considered very expensive. The pools themselves have no interest in harming the network and therefore deliberately remain below a critical boundary for the network, but there is no effective protection against 51% attacks in PoW. However, many projects try to prevent increasing centralization through protection mechanisms against ASIC miners. Another protective measure against the 51% attack is the switch to the PoS alternative consensus mechanism.
Percentage Attacks in Proof-of-Stake
Attacks that are similar to the 51% attack also exist in PoS systems such as Ethereum. As with PoW, the appearance of these attacks in projects with many participants is very unrealistic because such attacks are very expensive and the attackers would end up harming themselves. Nevertheless, if one or more attackers could account for 33% of the total stake, they would prevent the confirmation (finalization) of blocks on Ethereum, as this requires a two-thirds majority. In this case, the attacker would simply not confirm any blocks. Ethereum solves this with an approach called an inactivity leak. In this case, inactive participants of the consensus mechanism are punished until the size of their stake is no longer the majority or they actively participate again.
With over 50% of the total stake, attackers could cause even more mischief and control which local fork a blockchain chooses. With over 66%, attackers would have majority voting power in the blockchain and could confirm any block they wanted and thus take over the network. The hope is that the high cost would deter such attacks or that honest validators would step in and lock the attackers out of the network.
Sybil Attack
Sybil attacks are not only a threat to the blockchain but to P2P networks in general. In a Sybil attack, a participant creates a lot of false identities and makes it look like they are independent instances. To the outside world, the fake identities look like normal users, but in reality, they are all controlled by the same attacker. This procedure is also known from social networks, where fake accounts are used to select or comment on certain posts to make them appear relevant. In a Sybil attack in the blockchain, an attacker creates many full nodes, which they run as independent nodes to isolate other nodes in the network. If a victim’s node has only the attacker’s nodes as peers, then they can pass fake blocks or incorrect transactions to the isolated nodes. The isolated nodes then have no way of finding out what is happening in the real network. In this way, doublespending is also possible, as the attacker could pretend to pay the victim for a service that was never made in the real network. With enough fake identities, it would even be possible to cut off entire parts of the network.
Sybil attacks are more likely in small networks. In large networks such as Bitcoin or Ethereum, it would take too much effort to create fake identities.
In the case of PoW blockchain, the mining mechanism can also effectively prevent the creation of new blocks. Fake nodes would also need computing power, which would be very costly. Sybil attacks can also be prevented by requiring nodes to build a reputation before they can operate on the network or by incurring a cost to create an identity. Both reputation and initial costs are used in PoS systems.
Race Attack
As the name suggests, a race attack is all about speed. In this scenario, an attacker double-spends by sending a transaction to two people at the same time, for example, with Bitcoin. However, it uses the same output (UTXO) in each of the transactions, so the attacker spends the same bitcoins twice. Both recipients initially receive the transaction from the attacker and don’t know that the transaction is currently in a race with another transaction. If, for example, the recipients are traders, they may now be inclined to hand over a product that has already been sold. However, only the transaction that first receives the required confirmations from the network will ultimately be persistently stored on the blockchain, and the slower transaction will be rejected by the network after some time. The chance of success of such an attack becomes even greater if the attacker has a direct P2P connection to the victim’s node. This allows the attacker to send one of the transactions directly to a victim without any detours while broadcasting the other transaction to the network. The network doesn’t notice the wrong transaction until later.
This type of attack can be made more difficult by the fact that your own node doesn’t accept incoming connections from nodes from which it expects to pay. In addition, a recipient should wait until a transaction has at least six confirmations to make sure that it finds its way into the blockchain.
Finney Attack
A Finney attack is very similar to a Sybil attack. The name Finney most likely sounds familiar to you by now: the attack is named after cryptographer Hal Finney, a pioneer of blockchain technology. He was the first to describe the attack on a Bitcoin forum.
A Finney attack only works if the attacker is a miner or has the right to create a block. The attacker, let’s just call them A, creates a block. In this, they record a transaction with which they transfer a certain amount of cryptocurrency from their address A to an address B. However, B is also in their possession and doesn’t broadcast this completed block to the network but holds it back. Now, they transfer the same output to victim C that they have already included in their block. They send the transaction to the network but ideally directly to C. In this scenario, C could again be a merchant who, after seeing the transaction, sends the goods to A. Once this is done, A broadcasts its previously created block to the network. This invalidates the transaction to C since the output was already considered in the transaction to B. A now owns the commodity and still owns the shares of the cryptocurrency at address B.
A Finney attack is very theoretical and requires very good timing. There is no known case yet in which a Finney attack has been used live. A Finney attack can also be avoided if the recipient of a transaction waits until it has enough confirmations, namely at least six.
Denial-of-Service Attack
We have already briefly discussed DoS attacks in the previous sections. They were the reason that a maximum block size was introduced in Bitcoin. DoS attacks are not a phenomenon of the blockchain; they are also known to happen on the Internet. Here, for example, servers are bombarded with requests so that they can no longer perform their tasks properly. In a DoS attack on the blockchain, nodes are overwhelmed with information and work so that they can’t keep up with the processing of regular transactions. This is realized through bloated or computationally intensive transactions. Satoshi Nakamoto had already taken DoS attacks into account in his concept and planned to prevent them through PoW and the introduction of transaction fees.
DoS attacks have historically posed a serious threat to blockchains. In the case of Bitcoin, in September 2018, a vulnerability in the client software was repaired that could have been exploited by attackers for a DoS attack. To do this, they would have had to construct a transaction that tries to output the same output twice in a certain way. This would have resulted in an error message on the nodes, which would have failed as a result. Fortunately, the vulnerability was discovered before it could be exploited by an attacker.
The Ethereum blockchain has also had problems with DoS attacks. In 2016, attackers exploited an assembly operation called EXTCODESIZE. With this, it was possible to instruct nodes to read the size of a contract at an address from their memory. The execution of the operation was a comparatively time-consuming task for the nodes, but it costs very little in transaction fees. The attackers broadcast transactions to the network, each calling this operation 50,000 times. While this slowed down the network, it didn’t cause any other damage. An Ethereum Improvement Proposal (EIP) was later used to align costs to prevent this attack in the future.
In the case of Ethereum, another “cheap” operation was exploited for attacks. The attackers used a smart contract to create numerous empty contract accounts using operation SUICIDE. The creation of such accounts costs money, which is paid in the form of gas. This is necessary because the accounts also consume memory in the blockchain. To reward users when they delete the code in unused contract accounts to free up memory, operation SUICIDE was introduced. When users delete the contents of their contract accounts, they get back a large part of the gas used. The attackers were able to create huge amounts of contract accounts very cheaply using this method. The actions required for creation and deletion have noticeably overloaded and slowed down the network, and in the meantime, there is no longer any remittance of gas for destroyed accounts that were not previously used. Operation SUICIDE was abolished with version 0.5.0 of Solidity.
The probability of DoS attacks can be reduced by limiting transaction and block sizes. This ensures that not an excessive amount of data is packed into the transactions and blocks. In addition, attention must be paid to a balanced transaction cost concept. Network services, which require a lot of work, must also be correspondingly expensive to make DoS attacks unattractive to attackers.
Selfish Miner Attack
The selfish miner attack was first presented by Ittay Eyal and Emin Gün Sirer in a scientific publication (Eyal and Sirer, 2013). This attack affects PoW blockchains, and it differs from the attacks already described in that it doesn’t intend to break the network rules in order to commit double spending. Rather, it’s an economic attack through which attackers want to enrich themselves on the network by behaving unfairly. In the selfish miner attack, a miner or mining pool (which is more likely) keeps a block n that they have just mined secretly from the network. Instead of broadcasting it, the selfish mining pool continues to build the block n+1. This gives them an advantage over the other miners in the network, as they can start the next block earlier. After a certain period, the selfish mining pool broadcasts a whole chain of created blocks to the network. This now represents the longest chain, and all blocks created by the other miners on the network are discarded. According to Eyal and Sirer, this scenario becomes dangerous when attackers have more than a third of the computing power or, in certain cases, just a quarter of the computing power.
There are differing opinions about how realistic the selfish miner scenario is. With the Bitcoin and Ethereum blockchains, large pools are closely watched by the community. The pool operators would harm themselves, as selfish miner attacks would quickly attract attention and pool members would switch to other pools. The attack described is theoretically also possible in a PoS system but, of course, adapted to the circumstances in this consensus mechanism.
Attacks on Users
We have shown that attacks on blockchain systems themselves are difficult and require a lot of effort for the attackers. It’s much easier to attack a vulnerable interface of the blockchain: the user. The attacks on the human factor don’t at any time undermine blockchain technology itself. Nevertheless, the attackers either gain access to a user’s tokens or manage to get users to send the tokens to the attacker themselves.
To accomplish this, attackers use social engineering, a technique that has been used by attackers in regular computer systems for many years. Social engineering is the art of manipulating human behavior in such a way that the person concerned doesn’t notice it. There are also positive manipulations, for example, when a doctor gets a patient to move more. A more likely occurrence in the field of information security is negative manipulation, in which people are persuaded to carry out an act that harms them.
Of course, an attacker would also have the option of hacking external programs or applications that access the blockchain, but this belongs more to the field of secure software development and won’t be covered in this book (except in the context of decentralized software).
In the following sections, we’ll describe some of the methods that have been used to attack human users of cryptocurrencies in the past.
Phishing
Phishing attacks are the most popular type of attack on the human factor in information systems. Here, the unsuspecting victims are lured to fake sites where they enter their credentials. This gives the attackers access to users’ accounts. In the blockchain environment, the procedure works similarly. The attackers want to gain access to a user’s tokens, and instead of a username and password, it’s enough for them to steal the user’s private key in blockchain applications. From this, they can calculate the corresponding
address.
In 2017, users were lured to phishing sites via fake ads on the Google search engine. The ads appeared when users searched for terms related to cryptocurrencies. In doing so, the ads pretended to lead to very well-known platforms for wallets that can be managed on websites, for example, www.myetherwallet.com or www.blockchain.info. The link in the ads was written in such a way that it was not obvious at first glance that it was a different page. For example, the links were www.myetherwaller.com or www.blockchien.info. The ads led users to sites that were copied from the original site down to the smallest detail. When logging in, users were asked to enter their private key, which was immediately transmitted to the attackers, who then had free rein to empty the contents of the wallets.
Also in 2017, an ICO called Red Pulse was conducted. Using a fake Twitter account, attackers pretended to be a Red Pulse team before the ICO and promised investors an extra bonus of tokens if they registered on a site. This was to be distributed as an airdrop, in which owners of the cryptocurrency NEO were to receive the tokens as a gift. The attached link then took victims to a page that mimicked Red Pulse’s corporate identity. On a bonus calculator, victims were even able to calculate in advance how many tokens they would receive via the airdrop if they registered. In the sign-up process, victims were then asked to provide their private key, supposedly to be able to assign the token bonus.
Even in the blockchain environment, users should pay attention to whether they are on a company’s real websites. In addition, users should avoid navigating to the landing page via links; it’s better to enter the desired address directly into the browser. Even more important, however, is the more secure handling of the private key, which must not be passed on negligently. Users find it difficult to understand the complex technology behind blockchain and the scope of certain actions, but they can protect themselves through technical options (such as hard wallets) or by getting training on the topic. A nice approach is also taken by www.myetherwallet.com, which welcomes users with a popup window with the necessary information for the safe use of the service.
Pretexting
Pretexting occurs when attackers trick their victims into believing they have a false identity or occurrence. In this way, attackers try to obtain secret information or persuade victims to take certain actions.
You’ve probably all received a fake email trying to get you to click on a link in broken English. Emails have also been used for attacks in the blockchain in the past, but the attackers took a much more targeted approach. Just before the Bee Token project’s ICO began in 2018, attackers emailed potential investors, impersonating the project’s official team. They had presumably stolen the addresses from a newsletter tool used by Bee Token. In the email, they gave the recipients hints about the launch of the ICO. However, as the blockchain address for the investment, they didn’t give the official address of the ICO but the address of the attackers. Many investors fell for the trick, and the attackers were able to raise over a million dollars.
Another pretexting attack was carried out via the Twitter platform (now X). The attackers pretended to be Ethereum inventor Vitalik Buterin by opening Twitter accounts and using Buterin’s name and profile picture. Only the account name differed from the original, but they chose a name (e.g., @VitalikButerjm) that would not be noticeably different from Buterin’s account name at a glance. The attackers replied to a real tweet by Vitalik Buterin, writing in a message that they would give away Ether. Interested parties would only have to send 0.2 Ether to a specific address to receive the giveaway. This trick was repeated very often with different accounts, so that Vitalik Buterin was forced to temporarily change his name on Twitter to “Vitalik ‘Not giving away ETH’ Buterin.”
Only a healthy dose of mistrust can protect against pretexting. In addition, dubious offers should be thought through before rash actions are carried out. However, the most important thing is to know that such attacks exist. This is the only way users can keep an eye out for them.
Malware
Another famous type of attack is malware: malicious programs that perform malicious functions on a computer. Again, attackers have displayed their creativity by reinterpreting this well-known method in the blockchain environment. In one case, via downloads of various seemingly useful tools, attackers spread the CryptoShuffler Trojan, which installed itself in computers’ registry in the background. The Trojan’s job was to monitor the computer’s clipboard. Since private keys are very long, users like to copy them to their clipboard and paste them back into the desired application to authenticate themselves. The Trojan took advantage of this, stole the private keys, and sent them to the attackers. They were now able to empty their victims’ addresses.
Of course, users can prevent this from happening by entering their private key by hand, but this is not a pleasant activity in terms of usability. Therefore, cryptocurrency users should use up-to-date antivirus software and only download programs from trusted sources. The use of a hard wallet can also provide security for authentication.
Editor’s note: This post has been adapted from a section of the book Blockchain: The Comprehensive Guide to Blockchain Development, Ethereum, Solidity, and Smart Contracts by Tobias Fertig and Andreas Schütz.
Comments