In most cases, a vulnerable blockchain is nothing to brag about. However, Kudelski Security’s FumbleChain is just that, and they’re proud of it. FumbleChain is a purposefully insecure blockchain that encourages users to learn about blockchain security.

It contains a series of challenges that each demonstrates a common blockchain vulnerability. Once you solve the problem, you receive FumbleCoin rewards. Don’t get too excited, though; these coins have no monetary value. The real rewards are the skills you learn along the way.

Never a team to back down from challenges, we took our blockchain penetration testing knowledge to FumbleChain, successfully finding every one of its vulnerabilities. The following are our results.

WARNING: The rest of this article contains solutions to FumbleChain’s vulnerability challenges. If you’re planning on performing blockchain penetration testing on FumbleChain yourself, you may want to do so before finishing this article.

.

.

.

.

.

.

.

.

.

.

.

.

.

Vulnerability #1: No Input Sanitation Enables Replay Attacks

The first vulnerability we discovered in our blockchain penetration testing efforts was the potential for replay attacks due to a lack of input sanitation, particularly in the Blockchain.py file.

What should happen: When you initiate a blockchain transaction, the network checks the magic number of the operation against the magic number associated with the blockchain. If those numbers don’t match up, the transaction is invalid.

The FumbleChain vulnerability: FumbleChain isn’t correctly performing the validation of the magic number. Therefore, you can create a transaction on any FumbleChain fork and effectively copy it to the main chain. If the wallet in the main chain contains enough funds, the operation will still execute.

We were able to create a transaction involving a mainnet wallet on the FumbleChain testnet. Then, we copied information from the JSON response and created a raw transaction on the mainnet with that information. Because the magic number isn’t included when signing a transaction, we were able to alter the new transaction’s magic number to match the mainnet and replay the transaction.

After mining six blocks, we received our stolen funds.

How to remediate: FumbleChain needs to include the magic number when creating transaction signatures. Doing so ensures that the signatures will be uniquely valid on a particular fork, and only that fork. Additionally, FumbleChain should add more logic in the Blockchain.py file to validate the magic number of transactions.

Any Forkable Blockchain Is Susceptible

FumbleChain isn’t alone in this type of vulnerability. Almost every blockchain can fall victim to replay attacks if the right precautions aren’t in place.