When Smart Contracts Aren't So Smart

Sarah Friend and John (J) Maurelian are smart contract security gurus, at a time when most people still don’t really know what a smart contract is. The software experts, from Ethereum development studio Consensys, spend their time rooting out programming flaws that could cost blockchain users hundreds of thousands of dollars, and they’re ready to tell some of those stories. We caught up with the pair at ETHBerlin, a Berlin-based Ethereum hackathon that saw hundreds of developers gather to exchange smart contract ideas and techniques.

What’s new about smart contracts

Smart contracts are a new way to do an old thing. At their heart, they are simply programs of the kind that run on any server or client-side computer, but with some important differences.

One difference is decentralization. A smart contact doesn’t just run on one computer, but on many, in a blockchain environment. Running programs on the blockchain has the same effect as transacting digital currency on the blockchain: it keeps everyone honest.

If multiple parties run the same data through the same program and cryptographically verify the results, then it becomes more difficult for a single party to tamper with the results. Compare that to, say, a company running a program on a single server that could alter the output, or the program code, to suit its own purposes.

Let’s say you and I collaborate on a video project. I contribute 40% of the work, and you contribute 60%. We might create a smart contract that lets people pay for the video and download it online. They would pay in Ether, and the smart contract would send us each a proportion of the proceeds reflecting our contribution. Because we both ran the contract, we could be sure that one person isn’t tinkering with the results and reallocating funds.

Nevertheless, if there’s a flaw in the smart contract that gets copied and run everywhere, then an attacker could quickly exploit it. Someone could come and steal both of our funds from the smart contract and send it to themselves instead.

That’s where another key difference between smart contracts and traditional programs comes in: the direct transacting of money.

When a conventional database sends $100 to another database, it’s really just sending a symbol representing $100. Somewhere down the line, a bank has to settle that payment. On the blockchain, smart contracts move cryptocurrency, which has real value, and there is no back-end settlement. The symbol and the money are the same thing.

“It’s a programming language where money is a primitive. Money is a built-in. So the rewards for any potential vulnerability are so immediate,” says Friend.

Smart contracts are like wallets with brains; not only do they process and send this cryptocurrency according to pre-scripted rules, but they store it, too. A smart contract can hold millions of dollars-worth of Ether, which is the cryptocurrency that underpins Ethereum, one of the most popular smart contract platforms.

Because smart contracts are visible and not always easy to update, it also means that anyone spotting an error in the underlying code can exploit it. The result would be an immediate influx of tokens. It’s the blockchain equivalent of jacking a slot machine.

This combination of properties makes them appealing targets for online attackers, says Friend: “Any smart contract that holds Ether is just sitting there waiting to get eaten.”

Adventures in smart contract bugs

What might hacking a smart contract look like? That’s what the duo will describe in their talk, providing concrete examples of smart contracts that were not as smart as they looked.

The most infamous example was the hacking of the DAO, an organization set up to govern itself entirely through smart contracts. Created by decentralization startup Slock.it, it sold tokens as part of an initial crowd sale. Token holders could vote on how to spend the cash, and Slock.it’s hope was that they would vote to fund one of its first projects, a block chain-based bike lock. Instead, an attacker noticed a coding flaw in the organization’s smart contract that enabled them to drain all of its funds. That amounted to tens of millions of dollars (the figure fluctuated wildly because Ether’s price tanked as a result of the hack).

Luckily,  the nature of the contract meant that the thief couldn’t immediately send the money. The Ethereum community voted to fork the currency, effectively rewriting the accounting books and rolling everything back. That violated one of the core principles of the blockchain: transaction immutability. What happens on the blockchain is supposed to stay on the blockchain.

The decision caused a storm at the time, and led to a splitting of the Ethereum network, with an Ethereum Classic that followed the original fork. The controversy resounded through the Ethereum community. Consensys founder Joseph Lubin told us last year that the DAO’s developers should have simply taken their lumps and accepted the consequence of their bad code. 

All that fuss over one coding flaw? Imagine what would happen if smart contracts suffer the same fate as JavaScript programming. For years, self-taught web coders have learned just enough JavaScript to be dangerous, spawning a forest of web sites with buggy scripts, and paving the way for an ocean of XSS and CSRF attacks. Add immutability and direct money transfer to the mix, and it’s easy to see why people see smart contract security as such a big deal. People are realizing this, including Consensys, and that’s why they are hiring infosecurity pros, says Maurelian.

In the meantime, companies are doing their best to come up with frameworks and best practices for secure coding of smart contracts. Microsoft launched a smart contract security working group called Kinakuta in 2016, which seems to have gone dark. Consensys has worked with the community to create a set of smart contract security best practices, which it began shortly after the DAO fiasco.

“We seek to explain the pitfalls and traps that people can fall into, and try to clarify the safer paths that we learn about. It’s becoming really hard to maintain as the complexity of things that people want to achieve grows,” Maurelian says.

Computer programming may be well established and understood, but decentralized applications using money as primitives running on thousands of machines in plain view are still a new variation. The ecosystem is still evolving, Maurelian warns. Things will get better as the tooling to help automate security checks improves. It’s still far behind the automated testing and continuous integration tools that we see in today’s enterprise programming environments, he warns. There isn’t really an SDLC for smart contracts yet, and it’s going to be important to formalize things and tool up as this technology gains traction.

In the meantime, the pair have some stories to tell. There are all kinds of strange adventure stories in smart contracts, concludes Friend: “Some of them are as responsible for as much money lost as the DAO. Some of them are funny, weird, and interesting. They tell us a lot about how the Ethereum network operates.”

Come to their talk at SecTor this October to hear some of these adventures. They’ll tell you about how criminals can use a kind of reverse honeypot to scam money out of smart contracts, and how one coding flaw actually did enable a smart contract-based cross-site scripting (XSS) attack. Apparently, what’s old really is new again.



Bookmark and Share