Various Attack Vectors That May Threaten Cryptocurrency Systems
While the promise of cryptocurrencies to revolutionize the monetary system stands clearly on the horizon, skeptics of cryptocurrency are quick to point out the attack vectors that malicious actors exploit.
While some of these attacks are orchestrated through social engineering of phishing scams, Ponzi schemes, or malicious websites that impersonate reputable ones, a more technical approach can be taken via both hardware and software avenues. Perhaps the most common to blockchain systems is the classic DDoS spam attack. The first testnet, Morden, ran between July of 2015 through November 2016 but was ultimately taken down and rebooted as the Ropsten testnet to quell Geth and Parity syncing issues among other problems. The solution worked well until February 2017, when a low-difficulty proof-of-work consensus model allowed malicious actors to inflate gas limits from 4.7 million to a bloated 9 billion. It should be noted this all took place on a test network and so the modified values related only to testnet Ether, not tied to any actual value. It is speculated that the goal of this attempt may have been to simply disrupt Ethereum development. Developers eventually deployed the Kovan test network with built-in spam-proof consensus mechanisms, and later the Rinkeby test network to continue developing in a cross-client environment.
Miners are capable of confirming what are called "spam transactions" to disrupt networks through DDoS attacks, but can also act maliciously to the network in what is known as a 51 percent attack. Specific to proof-of-work confirmation methods, 51 percent attacks happen when more than half of the mining pool attempts to confirm false transactions. As mining difficulty increases, miners tend to cluster together to make the most of their rewards by pooling their hash power. These pools of miners tend to become less decentralized as time passes. While this flies in the face of the tenets of blockchain networks as decentralized hubs, it also creates susceptibility for 51 percent attacks. A mining pool with 51 percent of the network’s computational power can invalidate legitimate blocks by confirming them faster than the rest of the network may react, allowing the malicious pool to double-spend funds. Mechanisms like proof-of-stake, which would require those making confirmations on the network stake a share of their currency in that validation process, are meant to mitigate this threat; it would be unwise for a majority shareholder to undermine the very thing in which they hold shares.
Beyond the machinations of malicious miners, issues can arise from the very language in which executable distributed code contracts (EDCCs) reside. This may be attributed to the "hard-and-fast" style of coding required to meet the demands of a constantly evolving industry. As developers seek to expand protocols and create new ones, sometimes cracks can form in the final product. Open-source systems may have many eyes on them, but sometimes the development environment fails to provide the necessary audit power to mitigate hacking attempts. The DAO hack will likely go down in history among the most significant auditing oversights. However, despite the massive issue caused by a lack of testing, it was not the only instance wherein poorly constructed code was taken advantage of to usurp crypto-resources out of a multi-signature contract.
On July 19, 2017, unsuspecting users may have awakened to see that a hacker had amassed around 153,037 Ether from wallets storing the contents of past crowdfunding efforts. The hacker had taken advantage of an issue in the Parity code that governed the multi-signature contract that stored the Ether. In two transactions, the hacker was able to change the ownership of the targeted wallet to him or herself and then move the funds out of the hacked wallet. Swift action from white hack hackers like Oleksii Matiiasevych rescued much of the funds from wallets that had yet to be attacked, saving many members of the development community a great deal of heartache while simultaneously identifying the issue.
Sometimes teams write solid code that requires another codebase to function properly and are let down. Such was the case with Augur when a critical vulnerability in the Serpent code was identified that could have possibly disrupted the production of the company's native token, REP. If it had been exploited by a hacker, the token offering would have appeared to be ongoing indefinitely, even after it ended, and all token transfers would have been disabled. Zeppelin Solutions disclosed the issue to Augur, which in turn took several steps to deploy a fix that included rewriting the REP EDCC in Solidity, performing necessary audits, informing exchanges ahead of the public, deploying the new REP token to the Ethereum blockchain, freezing all old REP by exploiting the newly discovered vulnerability, and finally migrating old balances of frozen REP to the new REP token.
There are a lot of moving pieces in blockchain development projects and attached to them is a significant amount of value. Attacks on that value may come from hackers, malicious miners, or issues in code. Some of these things are beyond control but, when possible, developers shouldn't be afraid to take a little more time to perform security audits in safe environments before releasing unready code into the wild to receive learning from a school of hard knocks.