Smart contracts have some advantages and disadvantages over traditional programming. A smart contract creates a record on the blockchain for every transaction and allows anyone to verify that the operation happened correctly. The disadvantage is that a contract’s storage and code is completely public. This years challenge tasks us with reading the storage of a smart contract.
In order someone to keep a secret from others on the blockchain, there has to be some processor off the blockchain, referred to as an oracle. This oracle will monitor for events emitted by a contract, process the event, and then call a function in the contract with the result. These events are only emitted when the block is mined.
There are a few other differences compared to traditional programming. Transactions are there forever, so someone else can observe how functions were called, what events were emitted, or what the state was at a particular time. Additionally, when functions outside of a contract are called, the contract is handing control over to a third party, whose potentially untrustworthy, which can cause flaws like re-entrancy.
Here are some good resources on Ethereum security and attacks.
David Wong and Mason Hemmel gave a talk at Black Hat Asia 2018 about common vulnerabilities found in Ethereum contracts.
Additionally, here is a good read on privacy on the blockchain.
Below are the flows for a few operations the victim might make.
- Attacker infects victim through an unknown vector
- Ransomware sends encrypted encryption key and other information to attacker’s server
- Ransom contract is deployed for the victim
- Ransom contract registers with the Registry Contract
- Registry emits AuthEvent for the off chain oracle to validate
- Oracle calls back into Registry contract with the result
- If successful, the Registry calls authCallback in Escrow, so Escrow recognizes the victim ID
- Registry calls authCallback in Ransom contract
- Ransom contract registers with Escrow, setting victim’s address, ransom amount and victim ID
- Victim calls payRansom, sending encrypted file and Ether to pay the ransom
- Escrow saves encrypted file, and calls requestKey from Ransom contract
- Ransom contract will call decryptKey and passes the encrypted encryption key
- Escrow will emit a DecryptEvent with encrypted encryption key and encrypted file
- Oracle will attempt to decrypt file and callback into Escrow contract with the result
- If successful, Escrow will subtract ransom amount from amount victim send and add it to the amount the attacker has access to. The Escrow will also delete the encrypted file and save the decrypted encryption key, and calls the fulfillContract in the Ransom contract. If the decryption fails, then the Escrow contract will send the Ether back to the victim.