Social Media and the Blockchain

Social media and blockchain are two technologies that commonly make headlines. But how and do these two technologies work together?

Why Put Social Media on the Blockchain?

Social media and the blockchain are not an unknown pairing. Several different blockchain-based social media startups have been around for years now. Social media startups are attracted to blockchain technology for a variety of different reasons. Some of the main advantages of blockchain for social media include:

• Decentralization: The current major social media companies are relative monopolies in their spaces and have the ability to exert a great deal of control over the types of content posted on their platforms and disseminated to their users. Blockchain, which is designed to be a fully decentralized system, lacks the centralization of traditional social media. This decentralization makes blockchain-based social media platforms more resistant to censorship.

• Transparency: A common criticism of social media platforms is their lack of transparency. Platforms like Facebook have been the defendants in a number of different lawsuits regarding what they do with their users’ data, and many of these platforms have been accused of being arbitrary in the application of their rules regarding “acceptable” content. A blockchain is designed to be fully transparent, meaning that any rules regarding what constitutes “acceptable” content are transparent, consistent, and fairly applied.

• Incentives and Compensation: Traditional social media platforms are designed to monetize their users. These platforms collect their users’ data and sell information about them to companies selling targeting advertising. Blockchain platforms, on the other hand, have built-in methods for paying for use of its infrastructure (block rewards and transaction fees) and for rewarding creators or paying subscriptions (cryptocurrency). This eliminates the need to monetize users to make a profit.

• Anonymity: Many blockchain platforms are designed to provide a level of anonymity to their users. Instead of using real identities, blockchain accounts are identified by public keys and addresses. This anonymity can be an asset in some spaces on social media where publishing unpopular opinions or facts could endanger a journalist or writer.

• Immutability: The blockchain is designed to create a distributed and immutable digital ledger, making it difficult to modify or remove information without detection. This can be an asset in some contexts where an authoritative record would be valuable.

While all of these are potential advantages of blockchain technology for social media, the picture isn’t all positive. Many of these same factors can also be detrimental to a social media platform. For example, the anonymity of blockchain (not essential but common) can encourage trolling and abusive behavior online. Or the blockchain’s immutability could make it difficult to remediate leaks of sensitive information on social media. Social media is an interesting potential application for blockchain technology, but they aren’t a perfect fit.

The Reality of Social Media and the Blockchain

Blockchain is a relatively young technology. While the original blockchains are over a decade old, it took several years before Bitcoin and its descendants achieved widespread visibility. While many companies - both large and small - are actively investigating the potential of blockchain solutions, many projects are still in their early stages.

The same can be said of blockchain-based social media projects. Several such projects are in existence, but many have been around for only a few years. The history of social media as a whole demonstrates that it can be difficult to predict if and when certain social media sites will take off and succeed.

Some social media sites - like MySpace - were relatively early successes, while many of the major players today were ridiculed in their youth by the major players of the day. At some point, it seems very likely that a social media platform based on blockchain technology will take off. However, it is impossible to tell whether this will be any of the ones that currently exist today.

Blockchain Security vs. Crypto Hacks

The blockchain is an amazing technology that enables a whole host of applications that were not previously possible.  The ability to create and maintain a secure, decentralized digital ledger allows organizations to function without requiring trust in a centralized authority.

However, the big question in blockchain is “is it secure?”  Blockchain apologists will assure you that the blockchain is completely secure and unhackable; however, the news cycle almost constantly has stories of blockchains being hacked and cryptocurrency assets being stolen, demonstrating that the blockchain is most certainly not secure.

These positions seem mutually exclusive; however, there is a lot of truth in both of them.  Understanding how the blockchain is secure and how it is still hackable is a vital step when deciding (or continuing) to use this new technology.

Blockchain: Secure by Design

Blockchain is designed to be a completely secure protocol for implementing a decentralized and distributed ledger.  This allows the network to maintain a trustworthy record of its history without relying upon a centralized authority to do so.  In order to accomplish this, the system needs a means to authenticate its users and a way to maintain the integrity and immutability of the ledger.

Authentication in the blockchain is dependent on public key cryptography.  This type of cryptography (also called asymmetric key cryptography) uses a keypair consisting of a related private and public key.  The private key can be used to decrypt messages encrypted with the corresponding public key and to generate digital signatures that can be verified with the public key.  These digital signatures are an essential part of blockchain technology’s security since they prove that someone with access to a given private key generated a given transaction or block.

The other important feature of the blockchain is its immutability: it’s difficult or impossible to change the ledger after the fact.  This is enabled by a combination of a few different features: digital signatures protect the integrity of transactions and blocks, blockchain consensus algorithms make it difficult for an attacker to create a fake version of a block, and hash functions link the blocks in the ledger together and ensure that any modifications to blocks are detectable.  All together, these components create a ledger that is extremely resilient to modification.

The underlying design of the blockchain works, and it works well.  While some blockchains have been exploited due to built-in vulnerabilities, these vulnerabilities have always either been deviations from the original blockchain design or created by poor implementations of the blockchain protocol.  The underlying design of the blockchain is secure against attacks using modern technology.

The Cryptocurrency Security Paradox

The blockchain is theoretically secure; however, you can hardly go a month without hearing about some cryptocurrency being hacked.  So what happened? Either blockchain is secure or it isn’t.

Robbing the Bank

Cryptocurrency hacks occur because of factors outside the control of the blockchain network.  Blockchain is designed to create decentralized systems and allow people to “be their own bank”.  However, this isn’t what many cryptocurrency users do. Instead, they take advantage of cryptocurrency exchanges and online crypto wallets.

Cryptocurrency exchanges are enticing because they provide a lot of convenience to their users.  Instead of managing their own private keys, they store them with the exchange. In turn, the exchange simplifies the process of performing transactions, making trades, etc.

The downside of exchanges is that they provide a centralized target for hackers attempting to steal these valuable private keys.  Like any other website, access to your exchange account is probably managed by a username and password and maybe a two-factor authentication (2FA) system.  Usernames and passwords can be guessed or phished and many 2FA solutions can be easily defeated. If this occurs, the hacker then has access to your account and your private key.

The security model of public key cryptography is based upon your private key remaining secret.  Anyone with that key is essentially “you” on the blockchain and can perform transactions in your name (including draining your account).  As a result, hacking an exchange enables the hacks that make headlines.

Bandits on the Loose

Exchange hacks are bad enough, but they don’t account for every hack on the blockchain.  A variety of other attack vectors exist that essentially boil down to cryptocurrency users doing something unwise.

The “Blockchain Bandit” is a cryptocurrency thief that took advantage of poor habits when generating private keys for use on the blockchain.  Whether to help them remember their keys or for other reasons, users generated weak keys and used them to store value on the blockchain. The “Bandit” caught on and began automatically scanning for and stealing from these weak addresses, netting them almost 45,000 Ether.

Another mistake that has lost cryptocurrency users some Ether is poor misconfiguration of their blockchain software.  A setting (disabled by default), allowed programs to interact with the wallet software via Remote Procedure Call (RPC) and perform transactions.  Users who enabled this setting and didn’t protect it properly were prey to an attacker who scanned for open RPC ports and stole over $20 million in Ether.

Using Blockchain Securely

Blockchain technology is designed to be secure, but, like any system, it doesn’t stay secure if you give the keys away or leave the front door unlocked.  The paradox between the security of the blockchain protocol and the rampant hacks of cryptocurrency is caused by people misusing the system, not any problem with the system itself.

Blockchain security is a complicated issue, but, from a user perspective, there are simple things that can be done to improve personal security on the blockchain.  Even steps as simple as properly protecting your own secret keys (i.e. not entrusting them to an exchange) and ensuring that any blockchain software that you use is secure and updated can make a huge difference in your ability to protect your cryptocurrency assets.

Threat Modeling for the Blockchain

Blockchain technology is an exciting new technology with a great deal of potential. With this potential comes the need to explore the security of this new technology. There has been a great deal of work in this space; however, no comprehensive threat model exists that classifies all potential threats and attack vectors within the blockchain ecosystem. When discussing potential security threats to a system and attempting to analyze whether a system is secure by design, it' is extremely useful to have a framework to use in classifying known attacks and pointing out ones that potentially have been overlooked. In this post, blockchain security threats are mapped to STRIDE, a well-known threat model developed by Microsoft, to create an effective threat model for the blockchain.

STRIDE and the Blockchain

The STRIDE framework was developed by Microsoft to help in threat modeling. Each letter in the STRIDE acronym is designed to refer to one of the most common threats in cybersecurity:

• Spoofing: Spoofing refers to the ability of the attacker to masquerade as another on the system.

• Tampering: Tampering attacks violate the integrity of the data stored on the protected system.

• Repudiation: Repudiation is the ability of a user to deny that they have taken a certain action.

• Information Disclosure: Breaches of confidentiality fall under information disclosure.

• Elevated Privileges: If a user manages to gain unauthorized levels of control over the system, this is a privilege escalation attack.

  • In the context of the blockchain, we can break up elevated privileges based upon whether the attacker has unauthorized access to a user’s account, an elevated level of control over the blockchain system (i.e. in a 51% attack), or unauthorized permissioned access to a smart contract.

The STRIDE framework is useful for defining the potential effects that certain vulnerabilities or attacks can have on the security of a system. However, blockchain systems are a complete environment, including everything from the cryptographic primitives that underpin their security to the smart contracts that extend the functionality of the blockchain system.

In order to have a meaningful discussion about a blockchain threat model, it’s useful to break up the blockchain ecosystem into its various levels. For the purposes of this post, the following breakdown is used:

• Fundamentals: The underlying components used to build the blockchain.

  • Cryptographic Primitives: The hash functions and public key cryptography used to ensure data integrity and provide user authentication.

  • Data Structures: The structure of the blocks used to store transaction data and the hash functions used to chain them together.

• Protocols: The definitions of how blockchain nodes should interact when working to maintain the shared distributed ledger.

  • Consensus:

  • Block Creation:

• Infrastructure: The nodes that work to maintain the distributed ledger and the network that they use to communicate.

  • Nodes: Computers running the blockchain software and maintaining a copy of the distributed ledger.

  • Network: The underlying network that the nodes use to communicate and the protocols that define how communications occur within the blockchain ecosystem.

• Advanced: Many blockchain solutions do not limit themselves to the basic blockchain protocol defined in the Bitcoin whitepaper. These advanced components are an important component of these blockchain’s security and their threat model.

  • Smart Contracts: Smart contracts allow third-party code to be uploaded to and executed on the distributed ledger.

  • Blockchain Extensions: The basic blockchain technology can be extended by systems built either on top of it (state channels, side chains, etc.) or through connections to external systems via APIs.

With the STRIDE threat model and the framework of the blockchain ecosystem, we have what we need to begin threat modeling for the blockchain.

Blockchain Threat Modeling

The blockchain threat model is presented in the table below. Using the STRIDE model and the levels of the blockchain ecosystem, it’s possible to classify each attack vector based upon its potential effects. Each cell shows the different attacks that can be used to affect a given component of the STRIDE model at a level of the blockchain ecosystem. Each attack vector includes mouse-over text that describes how the particular effect can be accomplished by that attack.

		Spoofing Authenticity	Tampering Integrity	Repudiation Non-Repudiation	Information Disclosure Confidentiality	Denial of Service Denial of Service	Elevated Privileges Privilege Escalation
							Account Attack has unauthorized access to blockchain account.	Blockchain Attacker has unauthorized level of control over blockchain.	Smart Contract Attacker has unauthorized access to protected smart contract functionality.
Fundamentals Blockchain is based upon cryptographic primitives and the block and chain data structures.	Cryptographic Primitives Hash functions and public key cryptography are essential to access control and data integrity on the blockchain.	Private Key Compromising a user's private key allows an attacker to generate transactions on their behalf. Phishing Phishing emails can be used to steal private keys, which allows the attacker to masquerade as a legitimate user. Shor's Algorithm Shor's algorithm breaks traditional asymmetric cryptography, allowing an attacker to forge digital signatures on transactions and blocks.	Grover's Algorithm Grover's algorithm decreases the security of hash functions, making it easier for an attacker to find collisions and break blockchain immutability.		Private Key Compromising a user's private key allows an attacker to read any encrypted data meant for them. Shor's Algorithm Shor's algorithm breaks traditional asymmetric cryptography, allowing an attacker to decrypt encrypted messages.		Private Key Compromising a user's private key gives an attacker unauthorized access to their account. Shor's Algorithm Shor's algorithm breaks traditional asymmetric cryptography, allowing an attacker to guess a user's private key and access their account.
	Data Structure Blockchain has defined formats for transactions and blocks. Vulnerabilities in these data structures or how they are processed can impact blockchain security.		Transaction Malleability The hash of a transaction depends upon the transaction's digital signature. This can be regenerated by the original signer, creating an identical transaction with a different hash.
Protocol Blockchain protocols like consensus algorithms and the block creation process codify how the network interacts and maintains a decentralized, distributed ledger.	Consensus The blockchain consensus algorithm defines how the blockchain is updated in a decentralized fashion.		51% A 51% attack allows the attacker to rewrite the history of the blockchain, breaking its integrity. Long-Range In a long-range attack, the attacker generates a conflicting version of a Proof of Stake blockchain and gets it accepted, breaking the integrity of the distributed ledger. Nothing at Stake In a Nothing at Stake attack, a Proof of Stake block forger signs two conflicting versions of the blockchain.	51% In a 51% attack, the attacker rewrites the history of the blockchain, allowing them to deny that past transactions are part of the official ledger. Long-Range In a long-range attack, the attacker rewrites the history of the blockchain, allowing them to deny that past transactions are part of the official ledger.		51% A 51% attacker controls the blockchain and can refuse to add transactions to it, performing a DoS attack against its users. Artificial Difficulty Increases If an attacker suddenly withdraws a large percentage of a Proof of Stake network's mining resources, the block difficulty target is too high for the remaining nodes. Since blocks cannot be found at the desired block rate, this implements a DoS attack. Long-Range A long-range attacker controls the blockchain and can refuse to add transactions to it, performing a DoS attack against its users.		51% A 51% attack gives the attacker control of the distributed ledger. Long-Range A long-range attack gives the attacker control of the distributed ledger. Selfish Mining Selfish mining allows the attacker to create more blocks than their percentage of mining power should allow. This increases their level of control over the distributed ledger. SPV Mining SPV mining allows the attacker to create more blocks than their percentage of mining power should allow. This increases their level of control over the distributed ledger.
	Block Creation The block creation process defines how the selected block creator creates new blocks and ensures their validity.		Frontrunning Blockchains publish transactions to the entire network before adding them to the distributed ledger. An attacker who sees a transaction can create a competing one with a higher transaction fee so that it is processed before the transaction that was created first.			Transaction Flooding By flooding the blockchain network with spam transactions, an attacker uses up the blockchain's capacity, delaying the addition of other blocks to the ledger. Also, any spam transactions that are included in the ledger are retained forever, consuming storage and processing resources on the nodes.		SPV Mining SPV mining allows the attacker to create more blocks than their percentage of mining power should allow. This increases their level of control over the distributed ledger.
Infrastructure Blockchain infrastructure consists of the endpoints running blockchain software and the network that connects them.	Nodes Exploitation of the computers running the blockchain software.	Malware Malware can be used to steal private keys, which allows the attacker to masquerade as a legitimate user.	Malware Malware can be used to perform eclipse and routing attacks. It can also be used to steal private keys, allowing the attacker to create fake transactions on the user's behalf.		Malware Malware can be used to intercept communications or steal private keys, allowing an attacker to view private or permissioned data without authorization.	Failure to Update Failing to update blockchain software could mean that a user does not follow a hard fork and cannot access the blockchain. Malware Malware on a user's computer can impede access to the blockchain at a variety of levels, including filtering or blocking traffic and terminating blockchain processes. This both denies access to them and degrades the efficiency of the blockchain since the user cannot contribute to block creation.		MSP Misconfig A misconfigured Membership Services Provider (MSP) could allow an attacker to grant themselves unauthorized permissions on the blockchain.
	Network The blockchain runs on traditional networking. Attacking this network can impact the security of the blockchain.		Eclipse/Routing Eclipse and routing attacks rely on isolating users, which can be accomplished by attacking the network level. An attacker can perform double-spend against users in different isolated pieces of an eclipsed network. Network Design A poorly designed network can enable an eclipse or routing attack by limiting the number of connections between different groups of users in the network. Overwhelming communication links can also essentially isolate different portions of the network.		Network Design If a private or permissioned blockchain relies on the security of the underlying network to manage access, an attacker may be able to gain visibility by compromising network components (routers, etc.).	Eclipse/Routing Eclipse and routing attacks can be performed at the network level by destroying or filtering communication links. Isolating portions of the network from one another decreases the block rate and causes the shorter chain to be discarded when the network reconnects. Network Design A poorly designed network may not be capable of managing the overhead necessary for a blockchain system, so bandwidth limitations could impact functionality. Physical Attacks An attacker physically severing communication links or tampering with devices (routers, etc.) could cause the functionality of the blockchain solution to be degraded. PoS DoS A Denial of Service attack against the legitimate block creator in a Proof of Stake blockchain means that an opportunity to create a block may be missed. This decreases the efficiency and capacity of the blockchain. MSP DoS A Denial of Service attack against a Membership Services Provider (MSP) may deny legitimate users access to the blockchain system.		Eclipse/Routing An eclipse or routing attack allows an attacker to corrupt a user's view of the blockchain and get them to act in the attacker's interests. This can give the attacker a level of control over the blockchain greater than they should have based on their percentage of the scarce resource (computational power, stake, etc.).
Advanced The basic blockchain protocol has been extended by the creation of smart contract platforms and allowing connections to external software and devices through APIs.	Smart Contracts Smart contracts extend the functionality of the basic blockchain protocol by allowing third-party code to run on the distributed ledger.	Delegatecall Delegatecall allows a smart contract to run in the scope of another smart contract. This can give the attacker unauthorized access to protected functionality within the smart contract.	Arithmetic Integer overflow and underflow vulnerabilities can be exploited to bypass checks on transactions and other protected operations, allowing the attacker to perform unauthorized actions. Bad Randomness Generating strong randomness is difficult in smart contracts, making it possible for attackers to cause smart contracts to take unanticipated actions. Reentrancy Reentrancy vulnerabilities allow malicious smart contracts to force vulnerable ones to take unauthorized actions. Short Addresses Short address vulnerabilities trick vulnerable smart contracts into performing transactions with a greater amount of value than was authorized. Timestamp Dependence Some smart contracts are designed to take action before or after a specific time. Since time on the blockchain is flexible and dependent on block creators, a malicious block creator can force unanticipated behavior. Unchecked Returns In Ethereum, some low-level functions throw an exception and others return false and continue running upon failure. Failing to check return values may cause a smart contract to continue executing after an unexpected failure.			Access Control Some smart contracts have protected kill switches. A failure in controlling access to these functions can allow a DoS attack against these contracts. Out of Gas Ethereum limits the amount of gas that a transaction can use. Forcing a smart contract into a state where it needs more gas than the limit to run can make it incapable of running.			Access Control Poor management of access control within a smart contract can give an attacker elevated privileges within the contract. Delegatecall The use of delegatecall allows a called smart contract to run code with the privileges of the calling smart contract.
	Blockchain Extensions Blockchain extensions build on top of the blockchain protocol (like state channels and side chains) or connect blockchains to external software via APIs.	Insecure APIs Exploitation of external software or hardware with access to a blockchain account may allow an attacker to perform actions masquerading as that account's owner.					Insecure APIs Exploitation of external software or hardware with access to a blockchain account may allow an attacker to gain access to protected functionality available to that account's owner.

This blockchain threat model represents my personal attempt to classify the currently known attack vectors against blockchain systems and is designed to be a constant work in progress as new attack vectors are discovered against blockchain systems. I plan to continue to update and refine this model and would appreciate any comments or input.

Introduction to Blockchain: Extensions

Blockchain technology provides users with a number of advantages not present in traditional systems.  Blockchains are the first fully distributed and decentralized system that is capable of maintaining a shared, trusted ledger.  This allows a network to keep a record of its history and be confident that a malicious user or users is not capable of modifying this history to their own benefit.

However, blockchain technology isn’t perfect.  Bitcoin was originally designed to replace traditional payment systems (like credit cards); however, by itself doesn’t have the ability to do so.  Blockchain technology has limitations, and blockchain extensions have been developed to help mitigate or eliminate these.

Limitations of Blockchain

Blockchains has a very specific structure.  Due to the need for the network to remain synchronized and for the network to validate all transactions, transactions cannot be continuously added to the distributed ledger.  Instead, transactions are organized into blocks, which are added to the distributed ledger at regular intervals. This design limits the speed and capacity of the blockchain solution.

The speed at which transactions are added to the distributed ledger is severely limited on the blockchain.  Blockchains typically have a target block rate, that is enforced at some level by their consensus algorithm.  For example, Bitcoin has a block rate of 10 minutes, meaning, with the three block rule, you may have to wait half an hour before a transaction is considered trustworthy.  This compares unfavorably with credit cards, where a “slow” transactions is done in a minute.

Blockchains also have an issue with a maximum capacity.  In addition to the set block size, many blockchains have a set maximum block size designed to protect against Denial of Service (DoS) attacks.  With fixed-size blocks created at fixed intervals, the blockchain can only process so many transactions in a time period, and this capacity is often far below that of the payment card system.

Blockchain Extensions

Some distributed ledger technologies have abandoned the blockchain data structure in order to address these problems.  For example, IOTA uses a directed acyclic graph (DAG) as its underlying data structure, which greatly increases its transaction speed and capacity.  Some blockchains make small protocol tweaks (like increasing the block rate) to improve transaction speed and capacity. And some blockchains have begun leveraging blockchain extensions to help address these issues while maintaining the original design of the blockchain.

Sidechains

Sidechains are primarily designed to increase the capacity of the blockchain by offloading some transactions to a standalone blockchain.  There are a few different implementations of sidechains, but a common one is to “peg” a sidechain to a parent blockchain. With pegged blockchains, a user on one blockchain can send tokens to an “output address”, and the equivalent amount of tokens will be released onto the sidechain.  Pegs are bidirectional, so the user can return to the original blockchain at will.

One benefit of sidechains is the increase in capacity for the original blockchain.  Since transactions performed on the sidechain are not recorded in the blocks of the main blockchain, the total capacity of the system is increased.

Sidechains can also be used to address specific deficiencies of the parent blockchain.  For example, a sidechain could have a faster block rate than the parent chain, increasing the system’s transaction speed.  Alternatively, sidechains can increase the capabilities of the system, like the Rootstock sidechain that plans to add smart contract functionality to Bitcoin.

The main security consideration of sidechains is that the sidechain is a completely distinct system from the main chain.  It needs to have its own means of securing consensus, through a large pool of miners, stakers, etc. Otherwise, a hack of the sidechain could affect the quality of its peg with the main chain and its users’ ability to switch back and forth.

State Channels

Another blockchain extension that has been getting a lot of press is the state channel.  The most famous state channel system is probably the Lightning Network running on the Bitcoin network.  However, other state channel implementations run on other blockchains under different names.

State channels function as a second-level protocol that runs on top of a traditional blockchain implementation.  A state channel is a direct connection between users of the blockchain network. They establish the channel using a traditional blockchain transaction that establishes the balance that each has contributed to the channel (i.e. 1 BTC apiece).  After the channel is established, payments are made by creating mutually signed assertions regarding the balance of value in the channel (i.e. .75 BTC and 1.25 BTC). The channel can be closed down at any time, and another blockchain transaction is created using the most recent balance assertion to place the correct amount of cryptocurrency in each participant’s blockchain account.

The main advantages of state channels are transaction speed, scalability, and privacy.  Transactions only require the channel participants and can be completed near-instantaneously.  However, if a channel becomes too unbalanced, it may be impossible to make a payment. This is where the network of state channels can be very useful since transactions can pass through different paths to rebalance channels or perform transfers between unconnected parties.

The main security consideration of state channels is that transactions are backed by the blockchain but not recorded on it.  State channel transactions are private to the recipients, and the blockchain network has to trust that all transactions made over them are legitimate.  However, the point-to-point nature of state channels protects against double-spend attacks since the value stored in one channel is unique to that channel and cannot be used to open and perform transactions in other channels.

The Distributed Ledger Universe

This series was designed to be an introduction to blockchain technology with a focus on blockchain security.  However, the solutions discussed in these articles are not the only ones out there. Other distributed ledger implementations (like DAGs and hashgraphs) use different data structures and have different security properties.  Also, the blockchain can be extended using external devices that interact via APIs or smart contracts. When designing a distributed ledger solution, it’s important to consider all of the available technology and the security considerations associated with it.

Introduction to Blockchain: Smart Contracts

In the beginning, blockchain was designed to replace the financial system.  The distributed, decentralized ledger maintained by the blockchain network is used to record the transactions performed using the blockchain financial system.  As a result, cryptocurrencies like Bitcoin can implement complete, trustworthy financial systems without a central authority (like a bank).

The distributed, decentralized ledger offered by blockchain technology is useful for more than just recording financial transactions.  Smart contract platforms are designed to run a Turing-complete computer on top of the blockchain, allowing smart contracts to fulfill a variety of different functions.

Introduction to Smart Contracts

Smart contract platforms use the underlying blockchain technology but modifies it to use it to run arbitrary, third-party programs on top of it.  Instead of transactions including actual financial transactions, they include computer instructions designed to be run by the blockchain’s virtual machine.

Since the blockchain network is distributed and decentralized, there is no central computing platform that runs the code and updates the state of the smart contract platform with the result.  Instead, each node in the network runs its own copy of the virtual machine and executes the code contained in the transactions in each block of the blockchain. Since code is designed to be deterministic and is organized into a block before execution, the network is able to remain synchronized at all times.

Smart Contract Security

The blockchain landscape is fragmented, and so is the landscape of smart contract blockchains.  The basic blockchain solution has been adopted and adapted in many different ways, making it difficult to create a definitive list of smart contract vulnerabilities.

Since Ethereum is the best-established smart contract platform, many lists of smart contract vulnerabilities focus on this.  The Decentralized Application Security Project has compiled a list of the most common smart contract vulnerabilities on the Ethereum platform, which are explored here.

Reentrancy

Reentrancy is probably the most famous of the Ethereum smart contract vulnerabilities.  Exploitation of this vulnerability in The DAO smart contract caused Ethereum to break its blockchain’s immutability and rewrite history to erase the attack.  This controversial decision caused a split in the Ethereum network that created the Ethereum Classic cryptocurrency.

Reentrancy is possible in Ethereum due to the existence of payable fallback functions.  These functions are designed to run when value is sent to the smart contract, allowing it to update its internal ledger, perform some functions, etc.

The issue with this setup is when a vulnerable smart contract function that the attacker can control (like a refund function) can be forced to call a malicious fallback function.  Vulnerable functions use the following control flow:

1. Check transaction validity

2. Perform send

3. Update internal ledger

With this control flow, the malicious fallback function is run as a part of step 2, before the vulnerable function updates state.  If it calls the vulnerable function again, the transaction will still be considered valid (since the state isn’t updated) and run again, allowing the attacker to withdraw twice as much value as approved.

Access Control

Some smart contracts are designed to have protected functionality.  For example, you can implement wallets as smart contracts where anyone can send value to it but only the owner can extract value from it.

Some of these smart contracts have a function for claiming ownership, where the owner of the smart contract (and the one permitted to call protected functionality) is set to the person who called the function.  The issue with these functions is that sometimes people forget to set the function to check that this is the first time the function is called. If they fail to do so, the owner is whoever called the function last, not first.

Arithmetic

Arithmetic vulnerabilities like integer overflows and underflows are nothing new with blockchain.  They’ve existed in software programming for some time and have only become less common due to the existence of programming languages that make them impossible (like Python).  Unfortunately, some smart contract programming languages are now vulnerable.

Arithmetic vulnerabilities occur when certain variable types are misused.  Integer overflow vulnerabilities occur when a programmer uses too small of a variable to store a value.  Underflow vulnerabilities occur during switches between signed variables (where a one in the most significant bit means negative) and unsigned variables (where a one in the most significant bit means a large, positive number).  Performing subtraction with unsigned values always results in a positive number, which can be problematic since these tests are often performed to check the validity of a transaction.

Unchecked Return Values

An Ethereum-specific feature that can trip up novice smart contract developers is the fact that it does not have a consistent means of indicating when low-level functions fail.  Some low-level functions throw an error if they fail, which terminates execution. Other ones return a value of false and allow the code to continue running. If an programmer assumes the first case for a certain function and doesn’t check function return codes, it’s possible to put their code in an unexpected (and potentially invalid) state.

Denial of Service

Just like the underlying blockchain can be vulnerable to Denial of Service attacks, smart contracts can also be rendered non-operational by a malicious (or benign) user.  Denial of Service attacks on smart can be accomplished in a variety of different ways.

One way to attack a smart contract is to exploit an access control vulnerability.  Well-designed smart contracts include a self-destruct function that would render the contract unusable if an attacker gains access to and executes this function.

Bad Randomness

Smart contracts often need access to random numbers.  In fact, many smart contract are designed to implement gambling games, so they need the ability to generate secret random numbers.

There are several means of generating random numbers in code, and many of these are considered “best practice” in traditional applications.  However, the blockchain environment is different, making the following means of generating randomness insecure:

• “Secret” Values: Like seeding a pseudo-random number generator, some smart contracts use “secret” values to create randomness.  However, everything is public on the blockchain, so an attacker can observe this value and predict the “random” values

• “Secret Code”: Using a proprietary algorithm for generating random numbers is not a great idea but it often works.  However, it fails on blockchain for the same reason as the “secret” values.

• External Input: Using external sources of entropy is a common method of generating randomness in traditional applications.  However, any source of entropy visible to one smart contract is visible to any other, making it easy to observe and exploit.

In the end, the best way to generate random numbers on the blockchain is to use an external source of randomness that the smart contract can query.  However, this has to be done carefully to ensure that malicious smart contracts can’t see it as well.

Race Conditions

In traditional programming, race conditions are when two or more threads are competing for resources, and the behavior of the program is dependent on which one gets there first.  In the blockchain, multiple transactions may be competing for recognition by a smart contract and the result depends on whichever transaction is processed first.

For example, a contest may exist where the first person to solve a puzzle wins some prize.  A benign user solves the puzzle and submits their solution to the smart contract as a transaction.  However, transactions are not instantly processed, are publicly visible before processing, and are organized for processing based upon transaction fees.  If an attacker sees the user’s solution, copies it, and submits a transaction with a higher transaction fee, the attacker is likely to win the contest without doing any work to solve the puzzle.

Timestamp Dependence

Another way that these contests can go wrong is if they depend on the current time on the blockchain as a condition for the contest.  For example, a smart contract may run a contest where the first submission after midnight on a certain day is the winner.

On the blockchain, the current time is the time of the most recent block, and this is set by the block creator.  Further, there is some wiggle room (often up to two hours) in timestamps to deal with propagation delay, non-synchronized clocks, etc. (in fact block timestamps don’t even have to be in order).  An attacker who manages to create a valid block with a timestamp of midnight before midnight but within the acceptable window can win this contest before anyone else tries to play.

Short Addresses

Short address vulnerabilities in Ethereum are caused by variable sizes, how arguments to a function are stored in memory, and how Ethereum pads arguments that are too short.

In this attack, the attacker calls a vulnerable smart contract function designed to send value to a certain address (like the refund function from the reentrancy vulnerability).  In this call, the attacker deliberately sends a destination address that is one byte too short and a value of the correct size. The function checks the value and, if the transaction is valid, calls a function to transfer the value.

This transfer function specifies the size of its arguments and expects a destination address of a given size.  As a result, it fills the address variable with the provided address and the first byte of the provided value. Now, the value is too small, so Ethereum zero-pads it on the right, effectively multiplying it by 256.  As a result, if the new destination address is controlled by the attacker (which they can assure before they perform the attack), they receive 256 times more value than the vulnerable function authorized.

Unknown Unknowns

The final smart contract vulnerability included in the DASP list was unknown unknowns.  Blockchains in general, and smart contract platforms in particular, are a relatively new technologies.  It is extremely likely that new vulnerabilities will be discovered and take the top slots for smart contract vulnerabilities in future years.

The Final Chapter: Blockchain Extensions

The articles to date have covered the topics used by most blockchain and smart contract platforms.  However, some extensions and second-level protocols have been developed to fix the deficiencies of the blockchain.  The final article in this series will discuss some of the security considerations for these technologies.

Introduction to Blockchain: Consensus

Blockchains are designed to be distributed, decentralized networks. Part of this includes removing the central authority used in many other systems.  In a traditional financial system, banks centralize power by maintaining control of the ledger that states how much value is stored in each account. If a dispute arises over the ledger, the bank has the final authority to decide what the authoritative version is.

Blockchain is designed to remove centralizing authorities like banks.  Instead, the blockchain network maintains a shared, decentalized ledger with each node in the network maintaining a copy and updating it as each new block is created.

The challenge with this is ensuring that all nodes make the same updates to their copies of the ledger with each block.  Since the network does not have a consistent authority to create the official version of the ledger, it chooses a temporary authority to create and share each block.  The mechanism for accomplishing this is called the blockchain consensus algorithm.

Fundamentals of Consensus

The job of the consensus algorithm is to ensure that control of the blockchain is decentralized so that no one user has the ability to control the network.  The means by which this is accomplished is through making control of the blockchain network dependent on control of a scarce resource.

No matter what consensus algorithm you choose, it boils down to the fact that control of a scarce resource equals power on the blockchain.  In Proof of Work, this resource is computational power. In Proof of Stake, it’s the blockchain’s cryptocurrency.

The logic behind using a scarce resource as a analog to power on the blcokchain is that it enables the use of economic incentives to protect the blockchain.  The Law of Supply and Demand says that, if there is increased demand for a resource with a limited supply, then the price increases.

When an attacker tries to gain control of a blockchain network (to perform a 51% attack or similar), they need to acquire more of the scarce resource to do so.  As a result, they increase the demand for the resource, which increases the price to acquire it. Hopefully, the cost to acquire enough of the resource to perform a successful attack will be beyond the attacker’s resources.  If not, we have successful 51% attacks against blockchains, which has certainly happened on smaller cryptocurrency networks.

How Common Algorithms Implement Consensus

When Satoshi Nakamoto created Bitcoin, it was the only blockchain in existence.  The Bitcoin whitepaper described the Proof of Work consensus algorithm used on the Bitcoin network.  Since then, many other consensus algorithms have been developed for different blockchain implementations.  Of these, Proof of Stake also receive a lot of attention, partly due to its presence on the Ethereum roadmap.

Proof of Work

Proof of Work is the original consensus algorithm, and, as its name suggests, it involves making people do work.  In Proof of Work, miners are the ones attempting to create a new block.  The way that the block creator is selected is by implementing a race where the winner creates the block (and earns the associated rewards).

This race involves creating a valid block, where the condition for validity is that the header of the block hashes to a value less than a given threshold.  Due to the properties of hash functions, the best way of accomplishing this is by random guessing. As a result, the miners in the network try random hashes until one stumbles across a nonce that creates the desired hash output.  The first miner to find a valid block then transmits it to the rest of the network to build the next block on top of.

The main issue with Proof of Work is that the criteria for block creation is the ability to create a valid block.  There is nothing to say that two different miners can’t find different versions of the block around the same time. If this occurs, a divergent blockchain may be created with different parts of the network building on top of different blocks.  Blockchain resolves this using the longest block rule, which says that, in a conflict between two versions of the blockchain, the longer one should be accepted.

Proof of Work also tries to minimize the probability of divergent blockchains using the concept of  difficulty.  The threshold value that a valid block header’s hash must be less than can be updated in a distributed fashion.  The difficulty is updated at regular intervals so that the creation of blocks (with the current computational power of the blockchain network) occurs at the desired block rate.

Proof of Stake

Proof of Stake takes a different approach to securing the blockchain using a scarce resource.  Instead of using scarce computational power (like Proof of Work), Proof of Stake uses the blockchain’s scarce cryptocurrency.

Proof of Stake works a lot like investing in a company.  By giving some of your money to a company, you have the right to receive investor dividends.  In Proof of Stake, you promise not to spend a portion of your cryptocurrency (or stake it) in exchange for the chance to be a block creator (and earn the associated rewards).

The mechanics of how block creators are selected based on stakes varies based upon the implementation.  In some implementations, the probability of being selected is directly proportional to the size of the user’s stake.  In others, the concept of coin age is introduced, where stakers who have not been selected to create a block in some time have an increased probability of being selected.  Regardless, control of more staked cryptocurrency in Proof of Stake equates to increased control over the blockchain.

One issue with Proof of Stake is the potential for a user to create multiple versions of the same block. Since the only criteria for a block to be valid is a signature by the chosen block creator, it’s possible for a user to sign multiple versions of the same block.  In fact, this is one place where blockchain incentives break down since, if presented with two versions of the blockchain to build upon, it’s in the block creator’s best interest to build on both to ensure that whichever version eventually wins out includes the block that pays them their block reward.

Attacking Consensus

Consensus mechanisms are the key to controlling the blockchain. As a result, many attacks on the blockchain are based upon gaining this control.  If successful, an attacker can perform a double-spend attack, which allows them to complete one transaction and then remove it from the ledger at a later date.  Some attacks against consensus have been known from the beginning (like the 51% attack), while others (like long-range attacks) were developed later.

51% Attacks

51% attacks are probably the simplest way to attack a Proof of Work blockchain and occur when the economic incentives of the blockchain don’t work.  Under the longest block rule, every benign node is obligated to choose the longer option when presented with two contradictory versions of the blockchain.  If an attacker has the ability to create the longer version at will, then they control the blockchain.

In Proof of Work, this is accomplished by controlling over half of the computational power of the blockchain network. Since creation of valid blocks requires randomly searching the space of potential options, whomever can search the space more quickly can create blocks faster.

Similar attacks are possible on Proof of Stake, but it requires a greater level of control over the scarce resource.  In Proof of Work, you need 50% of the computational power to have a 100% chance of finding the next block. In Proof of Stake, you need 100% of the staked cryptocurrency to have a 100% chance of forging the next block.  Since this is unlikely, an attacker trying to control a Proof of Stake blockchain needs to accept the possibility of failure.

Long-Range Attacks

Long-range attacks can be used on Proof of Stake blockchains to give an attacker the controlling portion of the staked cryptocurrency necessary to attack the consensus algorithm.  In this attack, the attacker creates a divergent version of the blockchain all the way back to the genesis block (this assumes that they have a stake in the genesis block).

On their divergent blockchain, the attacker creates a new block whenever they are selected as the block creator. Since they are the only ones creating blocks, they’re the only ones receiving block rewards.  Over time, the attacker has the controlling stake in the divergent blockchain.

However, the divergent blockchain will only be accepted if it is longer than the “true” version of the blockchain. Since the attacker can only create blocks on their version when it’s their turn, their divergent blockchain will fall behind the main chain whenever a benign user is selected to create a block.  While this happens less frequently as they control more of the stake, the attacker’s chain is significantly behind in the beginning.

In order to catch up, the attacker deliberately passes up their opportunities to create blocks on the main chain.  Between these missed blocks and ones missed by natural causes (or due to a Denial of Service attack on the chosen block creator), the attacker’s chain has the opportunity to slowly catch up to the main chain.  When this occurs, the attacker can publish their malicious divergent blockchain and gain control of the blockchain.

Up Next: Smart Contracts

At this point, we’ve examined the security implications of each level of the original blockchain.  However, blockchain technology has advanced since the publication of the Bitcoin whitepaper The remaining two articles in this series are devoted to technology built on top of the original blockchain: smart contracts and blockchain extensions.

Introduction to Blockchain: Network

Introduction to Blockchain: Network

The blockchain is designed to store a trusted, shared distributed ledger.  This ledger represents the history of the blockchain network, so the network level is an important one when discussing the blockchain ecosystem.

In the previous post, we discussed the nodes and how they each maintain their own copy of the distributed ledger.  Since the blockchain is designed to be trustless, no other node is going to implicitly trust any other node’s copy.  They need a way to agree on the state of the ledger (consensus), and, for that, they need a way to communicate: the network.

The Blockchain Peer-to-Peer Network

Blockchains use a different network architecture than most of the web services that we’re used to.  These services use a client-server architecture, where the server acts as a single source of ground truth, and the clients connect directly to it to upload or download application data.  For example, when you use a webmail client like Gmail, your email doesn’t go directly from your computer to the recipient’s.  Instead, you upload it to the Gmail servers and the recipient downloads it from a Gmail server to read.

This system is simple and effective, yet it relies on the Gmail server to be a trusted middleman in the process.  Blockchain isn’t big on trusted middlemen, so it uses a peer-to-peer network, where each node in the network communicates directly with other nodes.  Most blockchain networks use a broadcast system where, if a node has five peers, every message that is received from one is sent to the other four.  This way, messages percolate across the network over many paths, and no one has complete control over communications.

The main implication of the peer-to-peer model for blockchain networking is that the underlying network needs to be able to support it.  Since every peer needs to be capable of connecting to every other peer, you can’t effectively have a blockchain network distributed across a network with varying trust levels without compromising either blockchain or network security.

Also, the “broadcast” communication style of the blockchain means that it requires a large amount of bandwidth to function properly.  The inability to support this can have negative impacts on blockchain security and effectiveness.

Attacking the Blockchain Network

Many of the best-known attacks against blockchain systems are at the network level.  Many people know that private key management is a problem and that smart contract vulnerabilities exist, but they’d be hard-pressed to even name the top ten most common smart contract vulnerabilities.  On the other hand, Sybil attacks and 51% attacks are commonly mentioned in blockchain security-related posts.

In this section, we’ll discuss three network-level attacks on the blockchain: Denial of Service (DoS), Eclipse, and Sybil attacks.  A 51% attack can also be considered a network-level attack, but we’ll talk about it in the next post since it’s most closely related to consensus.

Denial of Service Attacks

Blockchains are distributed, decentralized networks, so it seems like Denial of Service (DoS) attacks should be impossible.  DoS attacks target a single point of failure (like a webserver) or a bottleneck in a system and attempt to overwhelm it in order to degrade the operations of the system.  Since blockchain (theoretically) has no single points of failure, DoS attacks shouldn’t be an issue.  In practice, DoS attacks against the blockchain exist, but they attack temporary single points of failure or system bottlenecks.

One such bottleneck is the transaction capacity of the blockchain.  Most blockchains create blocks with a fixed maximum size at a fixed rate.  An attacker can create a large number of spam transactions and transmit them to the network (similar to a DoS attack on a webserver).  If the network can’t reliably identify them as spam transactions and ignore them, they’ll be added to the blockchain, taking up space that could have been used by legitimate transactions. Worse, blockchains are “forever”, so these spam transactions that make it onto the blockchain can take up storage space on nodes for the life of the blockchain.

An example of a temporary single point of failure is the creator of a given block.  Different blockchains have different methods of choosing this person, but in the end, one node puts a block together, signs it, and transmits it to the network.  In some schemes (like Proof of Stake), if a block creator misses their “slot” for creating a block, they forfeit it.  If you can force someone to forfeit a block (i.e. by a traditional DoS attack), that block is never created and the network loses some of its potential capacity.

Eclipse/Routing Attacks

Eclipse and Routing attacks are two names for essentially the same attack.  In an Eclipse attack, an attacker isolates a single node from the rest of the network by controlling all of its peer connections.  In a Routing attack, the network is split up into two or more isolated groups.  Both attacks can be used to facilitate a double-spend attack (by sending a different transaction to each isolated individual/group) or a 51% attack (by filtering the victim’s view of the network state so that they mine a version of history that’s in the attacker’s favor).

Eclipse and routing attacks can be performed by a variety of different means.  External to the blockchain ecosystem, an attacker can control a node’s connection to the network using malware or any other traditional means of performing a Man-in-the-Middle (MitM) attack.  A study found that Bitcoin is especially vulnerable to BGP routing attacks, where the attacker convinces computers that the best route from A to B is through them.

Internal to the blockchain ecosystem, an attacker can perform these attacks by controlling all of a node’s connections to their peers.  Since blockchain networks are not fully connected (nodes only connect to a small number of other nodes), it’s possible that a node can only be connected to peers controlled by an attacker.

It doesn’t matter how the attacker controls the node’s connection to the blockchain network as long as control is absolute.  If this is true, the attacker may be able to selectively drop packets from other users or send mutually exclusive versions of transactions from their own addresses to drive the isolated groups’ versions of history apart.  When the attack is completed, the longest block rule means that whichever version of the blockchain is shorter will be discarded (which is perfect for a double-spend attack).

Sybil Attacks

A Sybil attack is a simple network-level attack used to facilitate other attacks.  In a Sybil attack, the attacker creates and maintains a large number of accounts on the blockchain network.  This can be useful when performing an Eclipse/Routing attack since, if the attacker controls most of the nodes accepting connections when a node is looking for one, there is a high probability that the node will only choose attacker-controlled connections.

Up Next: Consensus

Up to this point, we’ve talked about the fundamentals of the blockchain protocol and how it works and is attacked at a node and network level.  In the next post, we’ll be discussing consensus: the way that these distributed and decentralized networks of nodes agree on their shared history.

Introduction to Blockchain: Nodes

Traditional network services work on a client-server model. To access the shared resource, you (the client) connect to a server and request the official version of the file. This makes synchronization easy (since the server knows the most recent version) but is very centralized. This can be problematic because it requires trust in the server and the server is vulnerable to Denial of Service (DoS) attacks.

Blockchain is designed to be a completely decentralized system. Every node in the blockchain network has the ability to keep a copy of the distributed ledger, and the the official version of the shared ledger is updated via blockchain consensus mechanisms (covered in detail in the fourth section of this series).

What Do Nodes Do?

Nodes are a vital part of the blockchain ecosystem because they’re the ones that do everything. As a decentralized peer-to-peer system, everyone acts as a combined client and server. As a result, the duties of nodes are protocol-specific (rather than software-specific) and numerous.

Protocol Not Software

Like many other Internet applications, a blockchain is a protocol rather than a specific piece of software. Instead of mandating that everyone run the same executable to use a service (like Skype), the only requirement is that nodes communicate based upon the rules of the service.

An example is HTTP, the protocol that defines how websites work. The structure and ordering of packets on the network is defined by the protocol, but no-one cares which software you’re running. As a result, there are a couple of different web servers (Apache, IIS, etc.) and many different web browsers (Chrome, Firefox, Safari, etc.). These servers and browsers have agreed to follow the protocol, so they’re able to communicate with one another with no issues.

Some blockchains are implemented using different software, while others have only one. When choosing blockchain software to run, it’s always a good idea to cross-compare the options.

Common Node Tasks

The purpose of the node is to implement and operate the blockchain. Each node has the ability to store a complete copy of the distributed ledger, and, if they do, to update it based upon the consensus of the network as a whole. As a result, nodes can participate in a variety of activities including transaction processing, block creation, and ledger management.

Transaction Processing

One of the most common tasks that nodes have is transaction processing. Anyone connected to the blockchain network through the node will send their transactions to the node to be added to the distributed ledger. The node is responsible for sending these transactions on to the rest of the network as well as forwarding on any transactions that it receives from other nodes to its peers in the network.

Block Creation

The blockchain is updated by adding new blocks to the existing chain. These blocks contain the data stored on the distributed ledger, and someone needs to collect this information into the block and distribute it to the rest of the network. Since there is no centralized server in blockchain, this means that the nodes are responsible for this as well. Using a blockchain consensus algorithm, a node is selected as the next block creator. They perform the tasks of creating the next block and starting its distribution (and are rewarded for their trouble).

Ledger Management

Finally, nodes are responsible for ensuring that the distributed ledger is properly stored and accessible. Every node has the potential to store a complete copy of the distributed ledger. Since not all users of the blockchain network are nodes (i.e. some people just use Bitcoin for performing transactions or investments), these nodes may occasionally be asked to send a copy of certain parts of the blockchain to a user in order to verify that a transaction made it onto the distributed ledger.

Types of Blockchain Nodes

The role distinctions in the blockchain network aren’t even as simple as node and not-node. In some cases, it’s possible to have different types of nodes. For example, Hyperledger permits a huge amount of role specialization, allowing nodes to only do the portion of the work that they are most suited to.

One of the more common distinctions between nodes on the blockchain is full and lite nodes.  As their name suggests, full nodes perform all of the job roles associated with being a node. These guys store a complete copy of the ledger and participate in consensus and block creation. A blockchain network needs a certain critical mass of full nodes in order to maintain its security and decentralization.

Lite nodes are designed to make it easy for someone to perform and verify transactions without doing everything that a full node does. In the previous post in this series, we talked about how the block headers are “chained” together using hash values. Since these headers summarize all of the transactions contained in a block, they are all you need for verification of blockchain integrity. Lite nodes download the headers and only request the actual transaction data if they want to verify that a certain transaction was included in the block. This reduces the storage and communications requirements of lite nodes at the cost of a bit of decentralization.

Security of Blockchain Nodes

Nodes are the targets of most attacks on blockchain networks. While other attacks may have more name recognition (like 51% attacks), many attackers have found that it’s more profitable to target the individual users. Some threats at the node level are security misconfigurations, phishing, and malware.

Security misconfiguration vulnerabilities occur when users modify the settings on their blockchain software without understanding the potential impacts. One example is a setting on a common Ethereum client that allowed external applications to communicate with wallet software via Remote Procedure Call (RPC). Attackers scanning for port 8545 were able to connect to the software and steal $20 million in Ether.

Phishing attacks are also extremely common for blockchain users. The Electrum wallet is especially known for being a target of phishing attacks, with over $1 million in Bitcoin being stolen by just one attacker in a matter of hours.

Finally, malware can be used on blockchain nodes for a variety of different purposes. Many of the attacks described in the remaining articles in this series can be performed using malware that targets the blockchain software on a node.

Securing Your Node

If you run a node on the blockchain, its security is completely under your control. Taking the appropriate steps to secure it like installing antivirus software, properly configuring it, and being aware of phishing scams can make a huge difference for your security and that of the blockchain network. The decentralization of a blockchain network makes it more difficult to defend against certain network-level attacks, but every secure node contributes to the health and security of the network.

Introduction to Blockchain: Fundamentals

This article is the first in a multi-part series describing how blockchain works and some of the security assumptions associated with it. Each article will describe a different level of how the blockchain’s distributed ledger operates, starting with the fundamentals.

At the most basic level, blockchain technology is composed of cryptographic algorithms. The creator of blockchain, Satoshi Nakamoto, developed a system in which the trust that we traditionally place in organizations to maintain trusted records (like banks) is transferred to the blockchain and the cryptographic algorithms that it uses.

The Cryptography Behind Blockchain

The goal of the blockchain is to create a distributed, decentralized, and trusted record of the history of the system. The most famous blockchain, Bitcoin, uses this record to store the history of transactions, so people can make and receive payments on the Bitcoin blockchain and trust that their money won’t be lost or stolen.

In order to achieve this level of trust, the blockchain uses a couple of cryptographic algorithms as building blocks. Hash functions and public key cryptography are crucial to both the functionality and security of the blockchain ecosystem.

Hash Functions

A hash function is a mathematical function that can take any number as an input and produces an output in a fixed range of numbers. For example, 256-bit hash functions (which are commonly used in blockchain), produce outputs in the range 0-2256.

In order to be considered secure, a hash function needs to be collision-resistant, this means that it’s extremely difficult (to the point of being nearly impossible) to find two inputs that create the same hash output. Accomplishing this requires a few different features:

• No weaknesses in the hash function

• A large number of possible outputs

• A one-way hash function (can’t derive the input from the output)

• Similar inputs produce very different outputs

If a hash function meets these requirements, it can be used in blockchain. However, if any of these requirements are violated, then the security of the blockchain is at risk. Blockchain relies heavily on secure hash functions to ensure that transactions cannot be modified after being stored in the ledger.

Public Key Cryptography

The other cryptographic algorithm used in blockchain technology is public key cryptography. This type of cryptography is also widely used on the Internet as well since it has so many useful properties.  With public key cryptography, you can:

• Encrypt a message so that only the intended recipient can read it

• Generate a digital signature proving that you sent a given message

• Use a digital signature to verify that a message was not modified in transit

In public key cryptography, everyone has two different encryption keys: a private one and a public one. Your private key is a random number that you generate and keep secret. It is used for decrypting messages and generating digital signatures.

Your public key is derived from your private key and, as the name suggests, is designed to be publicly distributed. It’s used for encrypting messages to you and generating digital signatures. Your address (where people sent transactions to) on the blockchain is typically derived from your public key.

The security of public key cryptography is based on two things. The first is the secrecy of your private key. If someone can guess or steal your private key, they have complete control of your account on the blockchain. This allows them to perform transactions on your behalf and decrypt data meant for you. The most common way that blockchain is “hacked” is people failing to protect their private key.

The other main assumption of public key cryptography is that the algorithms used are secure. Public key cryptography is based off of mathematical “hard” problems, where performing an operation is much easier than reversing it. For example, it’s relatively easy to multiply two numbers together but hard to factor the result. Similarly, it’s easy to perform exponentiation but hard to calculate logarithms. As a result, it’s possible to create schemes where computers are capable of performing the easy operation but not the hard one.

The security of these “hard” problems are why you’ll often see articles about quantum computers breaking blockchain. Due to how quantum computers work, factoring and logarithms aren’t much harder than multiplication and exponentiation, so traditional public key cryptography no longer works. However, other problems exist that are still “hard” for quantum computers, so the threat of quantum computers to blockchain can be fixed with a simple upgrade. 

How Blockchains are Put Together

As its name suggests, the blockchain is a collection of blocks that are chained together to create a continuous whole. In this section, we explore how this works.

Blocks

The purpose of the blockchain is to act as a distributed ledger that stores data in a secure fashion. The blocks are the place where this data is stored.

The image above illustrates the basic structure of a block in a blockchain. We’ll talk about every part of this image throughout the series, but for now focus on the green sections. Each green piece represents a transaction within the block. While a transaction may represent a literal transaction (i.e. a transfer of value) on blockchains like Bitcoin, this is not the only option. As we’ll see later, smart contract platforms store other things (like computer code) as transactions as well.

The security of the blocks in the digital ledger depends on the security of public key cryptography. Every transaction and block in the blockchain is digitally signed by its creator. This allows anyone with access to the blockchain to easy validate that every transaction is authenticated (i.e. sent by someone who owns the associated account) and has not been modified since creation. The integrity and authenticity of the blocks in the chain is also assured by the digital signature of the block creator.

Chaining

Each block is equivalent to a single page in a bank’s account ledger; it only represents a slice of the history of the network’s history. In order to combine these slides into a continuous whole, the blockchain makes use of hash functions.

In the image above, you can see the hash functions linking each block together. Each block contains the hash of the previous block as part of its block header (the section not containing transaction data).

The fact that every block is dependent on the previous one is significant because of the collision-resistance of hash functions. If someone wanted to forge block 51 in the image, they have two options: find another version of block 51 that has the same hash or forge every block after 52 as well. The first is supposed to be impossible (due to collision resistance) and the other should be difficult or impossible since the blockchain is designed to make forging even a single block difficult (more on this later).

The security of the “chain” part of blockchain is based upon the collision resistance of the hash function that it uses. If someone can find a way to generate another version of block 51 that has the same hash, the immutability assumptions of blockchain break down and you can’t trust that any transaction will remain in the distributed ledger.

What's Next...

At this point, we’ve covered the fundamental cryptographic algorithms and data structures used in blockchain. The next two articles in this series are focused on the infrastructure behind the blockchain: the nodes and how they’re networked together.

Mapping the OWASP Top Ten to Blockchain

In my Blockchain Security course, I (unsurprisingly) get a lot of students with a background in cyber security. As a result, I have been asked several times how well the Open Web Application Security Project’s (OWASP) Top Ten list for web application vulnerabilities maps to the blockchain space. In this article, we’ll explore the OWASP Top Ten list and, where possible, point out areas where blockchain technology is potentially or actually vulnerable.

Injection

In an injection attack, an attacker takes advantage of poor sanitization of user input to attack a system. If the software developer did not appropriately handle the user input, it can be crafted in a way that allows it to run unauthorized commands. For example, failing to sanitize SQL input could allow a user to bypass authentication and run unauthorized queries against the database.

Poor input sanitization is definitely a potential issue in blockchain technology. Prior to the launch of the EOS mainnet, researchers at Qihoo 360 reported a vulnerability in the EOS smart contract parsing function that allowed a buffer-out-of-bounds write1. The researchers developed a proof of concept where the vulnerability allowed them to break out of the EOS sandbox and launch a reverse shell on the infected machine. If this vulnerability had been exploited on a running network, it could have allowed the attacker to compromise every node on the network as they ran the malicious smart contract once it was included in a valid block.

Broken Authentication

Broken authentication is a general vulnerability referring to any issues in the implementation of an authentication mechanism in an application. These issues could allow an attacker to masquerade as a legitimate user on a temporary or permanent basis.

Proper implementation of authentication functionality is vital to the proper function of the blockchain system, and the wide use of public key cryptography means that a large attack surface exists.

The LISK cryptocurrency is a good example of where design oversights allowed an attack on authentication in a blockchain. In LISK, a user’s address on the blockchain is achieved by hashing their public key and truncating the result to 64 bits2. This hash and truncation method of generating addresses is common; however, the short length of LISK addresses and the fact that addresses are not immediately tied to public keys makes LISK vulnerable to attack.

Addresses in LISK are only bound to public keys when a user initiates a transaction by either sending value out of the account or voting for a delegate. As a result, many accounts that had only received value were vulnerable to attack. An attacker only has to perform 264 key generation operations to find a private/public keypair that would map to a given address. Targeting any of M addresses decreases the complexity of finding any match by a factor of M. This attack is definitely feasible, and some vulnerable accounts held millions of dollars.

Sensitive Data Exposure

Sensitive data exposure is a self-explanatory vulnerability. If an application holds valuable data that must be kept secret, this data needs to be appropriately protected.

Blockchain technology is largely vulnerable to this vulnerability due to a lack of understanding around the technology. The blockchain is immutable, meaning that any data stored on it cannot be removed (without control of every node in the network). Most blockchains are also public, allowing anyone to download and store a complete copy of the data in the ledger.

In the short term, this combination makes blockchains vulnerable to data mining efforts. Many organizations specialize in mining the blockchain for public data that can aggregated into useful information. This data can be used for law enforcement, corporate espionage, and other purposes.

In the long term, all cryptography is breakable. Quantum computing is on the horizon and, while it won’t break blockchain technology, it will allow the decryption of any data stored on the blockchain that’s encrypted with public key cryptography. If data needs to be kept private forever (like personal data protected by privacy laws), don’t put it on a public blockchain.

XML External Entities (XXE)

XML External Entities (XXE) are vulnerabilities based upon external entity references inside XML documents. The risk of these is that sensitive internal files stored on the webserver may be accessible using these references. Since blockchain is not XML-based, this vulnerability does not really apply.

Broken Access Control

Broken access control is similar to but distinct from broken authentication. In broken authentication, an attacker pretends to be an unauthorized user, while, in broken access control, a malicious user gains unauthorized access to protected functionality.

Poorly implemented access control mechanisms are one of the major vulnerabilities seen in Ethereum smart contracts. The Parity smart contract-based multi-signature wallet is known for being exploited twice due to access control vulnerabilities. In both cases, Parity smart contracts had a function designed to let the owner call it and claim ownership of the contract but didn’t check that it was only called once.

In the first attack, an attacker called this function to take control of Parity wallet contracts and drain them of the stored funds. In the second, a similar function in a library contract used by all Parity wallets was attacked. The attacker took control and then self-destructed the function, making all Parity wallets unusable and causing about 1% of all Ether to be lost forever3.

Security Misconfiguration

Security misconfigurations is another general OWASP vulnerability. It refers to using insecure default configurations of software or using configurations that make the system vulnerable to attack. As such, it is one of the most commonly seen types of vulnerabilities.

Blockchains are implemented as software running on client’s machines in a peer-to-peer network, so it makes sense that security misconfigurations could impact security. In one case, users of an Ethereum wallet configured their wallets to listen and accept external commands via RPC (port 8545). Attackers taking advantage of this vulnerability were able to steal $20 million worth of Ether4.

Cross-Site Scripting (XSS)

A website is vulnerable to a cross-site scripting attack if it includes untrusted data within a webpage without validating and sanitizing it first. This vulnerability allows an attacker to run scripts within a victim’s browser.

Cross-site scripting vulnerabilities can affect blockchain systems in a couple of different ways. Cross-site scripting vulnerabilities have been exploited in other software to allow cryptomining malware to be run on the victim’s computer.

Cross-site scripting vulnerabilities can affect blockchain security more directly if they exist in blockchain explorers. Blockchain explorers have display transaction data, which is untrusted data potentially under an attacker’s control. If an XSS vulnerability exists in a combined blockchain explorer and wallet, exploitation of the explorer could allow access to a user’s private key and control over their account5.

Insecure Deserialization

Serialization is commonly used for transmission of sets of data across a network. If deserialization code is improperly implemented, a malicious transmission could allow an attacker to exploit a vulnerable machine.

While no reported attacks have taken advantage of deserialization vulnerabilities, blockchain systems commonly use serialization for transmission of transactions. Since transaction data is under the control of (potentially malicious) users, vulnerable deserialization code could lead to compromise of blockchain systems.

Using Components with Known Vulnerabilities

Most software is built on top of or reuses other software. If these dependencies contain vulnerabilities, the software using them may be exploited by attackers targeting these vulnerabilities. The Equifax hack is a great example of how vulnerable third-party code can have significant impacts on an organization’s security.

Code reuse in Ethereum smart contracts is even more common than non-blockchain applications. In fact, less than 10% of Ethereum smart contracts do not reuse code6. Since many smart contract programmers have limited experience with the technology and the associated risks, this means that many smart contracts on the Ethereum blockchain contain known vulnerabilities due to code reuse.

Insufficient Logging and Monitoring

While secure development processes are important, they’re only half the battle. Once a system has been deployed, it is also important to log and monitor events on the system for abnormalities that may signal an attack. Failure to do so may leave the system vulnerable to exploitation via attack vectors overlooked during the design process.

The blockchain creates an immutable ledger of actions taken on the system, making it ideal for logging purposes. However, while logging is great, it’s useless is no-one is looking at the logs. Many smart contracts on the blockchain are “fire and forget” and go unmonitored by their owners, making them potentially vulnerable to exploitation without detection.

Securing the Blockchain

The OWASP Top Ten is designed to inform developers of the most common security mistakes made in web development. While blockchain systems are not traditional web applications, many of the same vulnerabilities apply. Of the vulnerabilities listed in the Top Ten list, only XXE is not directly applicable to some component of the blockchain ecosystem.

While the OWASP Top Ten is a good starting point when developing blockchain systems and smart contracts, the blockchain ecosystem creates additional potential security issues. The Decentralized Application Security Project (DASP) maintains a similar Top Ten list geared toward educating smart contract developers about the most common mistakes made on the Ethereum platform. Understanding how the blockchain ecosystem works and the security assumptions made at each level are also a vital part of ensuring holistic distributed ledger security.

Sources

[1] https://thehackernews.com/2018/05/eos-blockchain-smart-contract.html
[2] https://research.kudelskisecurity.com/2018/01/16/blockchains-how-to-steal-millions-in-264-operations/
[3] https://www.theregister.co.uk/2017/11/10/parity_280m_ethereum_wallet_lockdown_hack/
[4] https://cointelegraph.com/news/report-misconfigured-ethereum-clients-have-resulted-in-hack-of-around-20-mln
[5] https://blockpath.com/r/Interesting/comments/1g/the_transaction_that_can_xss_attack_unprepared/
[6] http://www.ccs.neu.edu/home/amislove/publications/Ethereum-IMC.pdf