The Challenge

 “The blockchain is secure.” 

It’s on every piece of blockchain marketing. Every sales pitch includes some mention of how blockchain is transparent and secure by design. That’s nonsense of course, a kernel of truth stretched far past its intended limits. Many have already written about specific issues and instances of attacks. What’s lacking is a fuller perspective on securely implementing one’s own blockchain; how to break down the problem, what to focus on.

The fragmented information available inevitably leads to worries. Should you be more concerned about injection attacks, request forgeries or invalid blocks? What do you need from your vendors to make sure you’re not vulnerable to a supply chain attack?

When your business decides to use a blockchain, how will you know if it’s secure?

To help you answer this, we’ve compiled a few questions and checklists here to help you be more confident in what you’re doing. As you read through this article, please keep your application’s context in mind. If you read here an example of a doublespend, but your application handles parts management, consider that checking out the same item twice would be how a doublespend manifests in your case.

The Scope

“Is the cloud secure?”

We’ve all learned that to handle this deceptive question, we need to know: who does this cloud belong to, what kind of cloud is this, and what is running on it? In a similar vein, before you can tackle the security of a blockchain, you must determine what you’re working with. Here are some good questions to ask yourself:

• Do we have source code?
• What does the stack look like?
• Are there implementation guidelines?
• Are there published security incidents we should be aware of?
• How valuable is the information that’s stored here?
• Who should see this information, and who shouldn’t?
• How fungible is the information or assets held within?

The goal of answering these questions is to determine the level of support available, the blockchain’s value as a target, and how direct you can be in implementing solutions. Consequently, you should have an idea of the size and scope of your task. An NFT marketplace developed in-house will cost more to secure than a vendor implementing an advertising insights solution.

The Task

When assessing a blockchain, it’s important to break it down into its logical pieces. It’s best to read through these pieces as part of a threat modelling exercise. When breaking it down this way, it’s easier to keep the context of your goals and limitations in mind.

The Block

Attacks on individual records (i.e. blocks) are often easily exploitable, moderate in terms of damage, and infrequent in their appearance. Here are some common issues that can give way to attacks:

• A valid transaction erodes some business logic
• There is no sanitization on the input, or the sanitization is only client-side.
• The block’s hash is insecure, either through poor choice or implementation
• The block fails to check the previous block’s hash

Exploiting one of these vulnerabilities leads to issues like doublespending, overspending, overflows or block collisions. Thankfully, solving these issues is often straightforward. Most of these issues can be identified and handled using familiar tools like test cases, static code scanners, and proper QA.

The Chain

Attacks on the chain itself are often difficult to launch and rarely successful, but they are the most damaging attacks available. The defense almost always requires scaling of some sort. This arms race, combined with the payoff, means it’s a constant threat. Here are the most common vulnerabilities in the chain:

• The main chain determination mechanism is fundamentally flawed
• The main chain is too short
• The network is small and does not have scaling resources available
• In a value-held voting system, the controlling stake didn’t freeze emergency assets.
• The confirmation period is too short.

Exploiting these issues offers temporary control of the main chain, allowing blocks to be smuggled in or out, ruining the integrity of the main chain. Choosing an appropriate confirmation period is a larger topic than can be covered in this blog post, but if the confirmation period is shorter than 3 blocks or takes only a few seconds, it’s likely insufficient.

The Wallet

Wallets are both a target and a source for attacks. There are the standard Authentication & Authorization and Access Control issues, but those won’t be retread here. A diverse array of attacks can target the wallet, and they’re difficult to identify for both the attacker and the defender. The payoff is almost always the same: gaining control of other accounts.  Here are a few of the more common issues in blockchain wallet security:

• Wallet or account metadata used as an injection payload.
• Key and/or backup stored insecurely
• Wallet’s address is silently truncated in a comparison
• Initialization uses an insecure or predictable seed or algorithm
• Wallet creation doesn’t automatically trigger an associating transaction

Identifying these issues is a task that seems trivial but is prone to being missed. This is because the issue often lacks visibility, residing in a default setting somewhere. Because the exploits are often chained attacks, static and even dynamic scanners often miss them. A code review is the best way to identify the initialization-based attacks, and a pentest is the best way to uncover any injection attacks.

The Stack

While vendors are getting better in recognizing that attacks are coming from them upstream, it’s still a common issue. These vulnerabilities tend to be easy to identify, challenging to fix, and the widest ranging in terms of impact. A few things to look out for:

• CVEs, often upstream
• Outdated versions
• Weak default settings, like no MFA
• Improper configuration

Unfortunately, there’s no silver bullet for these issues. A vendor isn’t going to let you scan their codebase, so be sure to confirm their reputation. Always get a certificate to ensure somebody’s done a proper assessment of the product. If you have more control, static scanning tools can pick up a lot of these issues, but configuration choices will always require a level of human review.

The Rest

This is where considerations for features, networking and existing assets is to be considered. Networking configuration is a known quantity, so will be skipped here. Here are some common themes:

• Non-encrypted PII found in-transit
• Re-entrancy attacks on smart-contracts
• Uncollateralized loans leading to regulation non-compliance
• Smart-contract lifecycle mismanagement
• Downstream attacks, including SSRFs
• Denial of Service

No single tool is going to find all these issues. They’re expensive to locate and remediate, but usually even more expensive if they’re exploited. Crucially, these issues often have a direct cost. This is where a reliance on a limited set of tools or perspectives will hurt the most. Whoever is checking these issues needs to be very familiar with the product. Product demos, patch notes and contact with developers are required for an effective assessment. Be wary of any team or firm that doesn’t request these items.

The Results

Ideally by this point in the post, you will have a better grasp as to the extent of your blind spots. Before you rush off to plug the gaps by expanding your program, perhaps you’d like to see the most common pitfalls from those before you? Here are the top 3 problems to look out for:

1. Upstream stack vulnerabilities
2. Implementation mistakes
3. Weak control over main chain

With the abundance of scanning tools available, you might be surprised that the top issue in ensuring blockchain security is people using software with known vulnerabilities. The second most common issue likely doesn’t surprise you at all: misconfigurations and mistakes crop up everywhere. The last item is there due to two main factors: nearly every blockchain’s main chain is vulnerable in its infancy, and it’s a target of incredible value. It seems like every blockchain deployment experiences a realization that there’s a single point of failure, which represents loss of control over the chain.

Conclusion

Hopefully this blog post helps pull together the sparse information available into broader, approachable chunks. The blockchain can be secured with the tools and teams you employ today, but can only provide surface-level coverage without strong direction. With a better understanding of the task before you, you should feel more confident in shoring up your blockchain’s security. No more hand-waving answers: the next time you get asked if your blockchain is secure you’ll know which issues you face, where they lie and what you’re doing about it.