Smart contracts will make ransomware more profitable, part 1
Blockchains are not a good fit for many problems, but they are great for solving problems of trust. In the real world, if you make a contract with someone and they break it, your only recourse is a lengthy and expensive time in court. With a smart contract, both parties are held to their commitments automatically. The code executes and the contract’s conditions are fulfilled, no third party required. In industries where finding a trusted third party is next to impossible, blockchains open up a whole new set of tools. We should carefully consider who will benefit from these tools. While many people have legitimate uses for trustless systems of coordination, many others will want to use them because they themselves cannot be trusted.
Some of the industries which don’t use third parties can’t do so because their business is illegal. Dark web drug markets will continue to benefit from advances in blockchain technology, but the impact will be small compared to those criminal services which stay exclusively in the digital realm. Above DDOS-for-hire services and blackmail threats, ransomware is the criminal industry with the most to gain.
Ransomware is a kind of malware that infects your computer, encrypts your hard drive, and then demands a payment (usually in Bitcoin or Monero) to decrypt your files. Unlike most types of malware, ransomware is profitable as well as destructive. Security researchers estimate ransomware operators took in hundreds of millions of dollars in 2016, but the financial loss from payouts is only a small fraction of the damage. In 2017, a new variant of ransomware known as WannaCry infected over 200,000 computers in a few months. These infections hit a wide range of industries, shutting down factory floors and forcing some hospitals to turn away patients. This March, the city of Atlanta was hit with a ransomware attack that shut down online access to the court system, utility payments, police reports, and other essential government systems.
Though the first known incidence of ransomware was in 1989, the attack remained obscure for several decades. Without an easy way to send payments internationally, there was no way criminals could use ransomware to turn a profit. With the invention of Bitcoin, ransomware operators finally had a way to receive money in a way that governments could not shut down. However, they still faced the problem of trust. The victims of these attacks had to trust the ransomware operators to send them the decryption key after receiving the Bitcoin ransom. Given that 1 in 5 people who pay a ransom never recover their data, many people rationally choose not to pay.
Ransomware operators would benefit from being able to credibly commit to restoring people’s data. If such a guarantee existed, many more people would bite the bullet and pay to get their files back. This would make ransomware a more reliable way to make money, and contribute to the growing ransomware epidemic.
This is where smart contracts come into play. By using a smart contract, an operator can trustlessly sell their victims a decryption key for money. That is, a victim can send some money to a smart contract with a guarantee that they will either receive the decryption key to their data or get their money back. The victim does not have to trust the person who hacked their computer because they can verify that the smart contract will fairly handle the exchange.
Let’s walk through how this would work. This example is simplified and contains a flaw, so see if you can spot it.
- A hacker creates a public/private key pair. One for encrypting and one for decrypting data.
- The hacker takes control of a victim’s computer and installs the ransomware. A common delivery method is a phishing email with a malicious attachment.
- The ransomware installed on the victim’s computer encrypts all their files with the public encryption key from step 1.
- The ransomware gives the victim a message containing the public encryption key, the address of a smart contract, and instructions for sending the smart contract money. For the sake of this example, let’s say the smart contract is run on Ethereum and the demanded payment is 10 ETH. The contract takes two inputs: a victim’s payment, and the hacker’s private decryption key.
- The victim submits 10 ETH to the address. The money is locked up in the contract and will be returned to the sender after a week unless the decryption key is uploaded to the contract.
- The hacker uploads the private decryption key to the smart contract.
- The smart contract checks whether the private decryption key corresponds to the public encryption key and cryptographically verifies it. If the match is correct, then the smart contract will release the 10 ETH to the hacker. If not, the smart contract does nothing for a week and then returns the 10 ETH back to the victim.
Did you spot the flaw? We’ll explain the flaw and the workarounds in the next post. For now, assume the simplified example provides a trustless way to exchange money for the real decryption key.
With this contract the victim has a guarantee that if they pay the contract 10 ETH, they will either get the decryption key to their data, or get their 10 ETH back in a week’s time. The 1 in 5 ransomware victims that got duped into paying for decryption keys that were never delivered would have benefited from a system like this. With a smart contract-mediated sale, if the hacker never delivers, the victim gets their money back.
Why haven’t we seen criminal smart contracts in the wild?
If smart contracts would be such a money-maker for ransomware operators, why aren’t they already using them? Ironically, it’s the same reason smart contracts have seen basically zero practical use to date: Ethereum is still new and hard to use. It’s extremely difficult to write secure smart contract code, as the Parity wallet hacks made abundantly clear. Almost no one except blockchain developers actually know how to use smart contracts to do anything more complicated than sending digital assets from one person to another person.
While the immaturity of the blockchain ecosystem may protect us in the short term, this state of affairs won’t last long. Billions of dollars are being poured into the blockchain ecosystem and people are designing better tools and building friendlier interfaces. As smart contract platforms mature, criminals will (again) be some of the earliest adopters.
Just as CryptoLocker provided easy instructions for victims to buy Bitcoin, future ransomware variants will provide easy instructions for victims to use smart contracts. Naïve users won’t be able to tell a real smart contract from a fake one, but big companies with large IT teams will be able to verify that a smart contract is legitimate. These companies will be the first targets of smart contract ransomware.
Real world implementations of these smart contracts will need to be a little more complicated than the one described above. For example, victims need a way to ensure that the public encryption keys used to encrypt their data are the same ones contained in the smart contract. This can be accomplished with some clever cryptography, but it requires more work on the victim’s part. See part II of this post for a more technical explanation of how ransomware contracts could be implemented.
Maintaining barriers to practical application
Fortunately, even though ransomware contracts work in theory, there are a number of barriers to making them work in practice. Where possible, the blockchain development community should work to maintain these barriers and build new ones.
Prevent easy verification of criminal smart contracts
Almost no one will trust a complicated smart contract sent to them by a ransomware operator, and it’s not like blockchain security companies are going to give a contract like that a security audit. However, if there were a standard contract template for doing this kind of information selling / exchange, it would be a lot simpler to verify that the contract was legitimate.
It would be nice if the development community never created key-selling contract templates, but there might be legitimate reasons to do so. For example, it could be useful to incentivize whistleblowers to leak information about human rights abuses. Do such use cases justify developing a contract template that is ideal for ransomware exchanges? It’s unclear.
IT professionals can refuse to help companies pay ransoms with smart contracts
For the foreseeable future, companies will need to employ IT professionals to safely interact with smart contracts. Should tech workers refrain from helping companies pay ransoms via smart contract? There have been efforts before to organize tech workers to refuse unethical work, such as this pledge to refuse to build a Muslim database for the Trump administration. Unfortunately, many tech workers already help companies pay crypto ransoms. Even though some security professionals have received negative PR from high profile cases like Uber’s payout to ransom demands, it’s unlikely companies will change their behavior without strong incentives to do so.
The game dynamics don’t favor tech workers or companies in the long run. If key-selling smart contracts easier to rely on, more companies will decide to pay, even though this will increase the incentive for cybercriminals to launch more attacks. While this is a tragedy of the commons, paying the ransom may be rational for a company in the short term. As long as there are tech workers who are willing to help facilitate these actions, conscientious protesters won’t make much difference. If workers can’t coordinate to prevent companies giving in to ransom demands, it may take regulation or a concerted publicity campaign to incentivize companies to do the right thing.
Refrain from building fully anonymous smart contract platforms
Criminal smart contracts would be much more effective if they could hide the identity of the sender and receiver. Many companies won’t want anyone to know they paid criminals to recover data they should have had backed up in the first place, and ransomware operators have already displayed a preference for anonymous currencies. Using zk-SNARKS or the cryptonote protocol, it would be possible to build contracts that could hide the sender and receiver address. There will likely be legitimate uses for anonymous smart contracts, but the community should think seriously about whether the potential for malicious use outweighs the potential benefit from such technology.
The way forward
Smart contracts allow for censorship-resistant coordination between people without the need for a trusted third party. While this has some very positive applications, it’s notable that some of the people that have the most to gain from trustless coordination are those who should not themselves be trusted. Ultimately, we cannot stop blockchain technologies from being adopted for malicious purposes, but we can make it difficult to do so. If there are enough barriers, criminal use cases will remain marginal, and serious criminal enterprises will be forced to go elsewhere.
Edit: There is a great post on this topic by Matthew Green on his Cryptography Engineering blog that he wrote last year. Glad to see some people in the security community are already thinking about this!