Home » Cybersecurity » Events » Empire Hacking: Ethereum Edition 2

Empire Hacking: Ethereum Edition 2

by Evan Sultanik on January 18, 2019

On December 12, over 150 attendees joined a special, half-day Empire Hacking to learn about pitfalls in smart contract security and how to avoid them. Thank you to everyone who came, to our superb speakers, and to BuzzFeed for hosting this meetup at their office.

Watch the presentations again

It’s hard to find such rich collections of practical knowledge about securing Ethereum on the internet. For many of you, it was even harder to attend the event. That’s why we’re posting these recordings. We hope you find them useful.

Anatomy of an unsafe smart contract programming language

Our own Evan Sultanik gave an introduction to blockchains and smart contracts, followed by a dissection of Solidity: the most popular smart contract programming language.

Takeaways

Solidity harbors many unsafe features that allow even experienced, competent programmers to easily shoot themselves in the foot.
Solidity is changing quickly, which is both bad and good. Developers must keep pace with new compiler releases and beware the implications of contract upgradability.
There is an effort to introduce an intermediate representation to the compiler. Early indications suggest that it suffers from many of the same design decisions that have plagued Solidity.

Evaluating digital asset security fundamentals

Shamiq Islam of Coinbase discussed problems in the security of digital assets and their ecosystems. These problems pose unique and interesting challenges to cryptocurrency exchanges like Coinbase.

Sponsorships Available

Takeaways

The supply chain is untrustworthy. How do you validate that an asset issuer’s node, smart contract, or wallet code is authentic?
Security communications channels are immature. If you find a bug, how do you know where to report it? Conversely, how can exchanges like Coinbase become aware if a bug is found? Monitoring a Telegram chat for each asset does not scale.
[For the time being, use our directory of Blockchain Security Contacts.]
How do we know when a smart contract owner is malicious? The code itself may be secure, but the owner’s key is a single point of failure. If compromised, it can arbitrarily modify the accounting of an asset in most cases.

Contract upgrade risks and recommendations

Our own Josselin Feist compared several different strategies for upgrading smart contracts. This talk covers everything you need to know to decide how and if to implement upgradability in your contracts.

Takeaways

Upgradability is useful for developers as it allows for features to be added and bugs to be fixed after the fact. However, it also adds complexity and increases the likelihood of deployment mistakes.
Use the simplest upgrade system that suits your needs. Compared to data separation, the delegatecall proxy pattern is very fragile and adds even more complexity.
Instead of these upgradability patterns, consider contract migration. Migration is more involved, but it allows for recovery from many more scenarios.

How to buidl an enterprise-grade mainnet Ethereum client

S. Matthew English of PegaSys highlighted the trials and tribulations of implementing a new Ethereum client. Many of the insights in the talk apply just as well to any large-scale software engineering projects.

Takeaways

Building an Ethereum client is hard. The protocol itself is poorly documented, uses non-standard computer science concepts, and has continued to evolve at the same time as existing clients evolve.
Team communication, architectural design, and incremental progress validation were important factors in the successful development of PegaSys.
Pantheon is now syncing with Ethereum mainnet, has been open-sourced, and is available for download.

Failures in on-chain privacy

Ian Miers of Cornell Tech and The Zcash Foundation provided an overview of privacy issues in cryptocurrencies. Cryptocurrencies might not be as private as you thought.

Takeaways

Privacy in cryptocurrency has been misunderstood since the very beginning. It’s important that we figure it out now before it’s too late to fix.
Decoy-based approaches may seem successful in isolation, but the privacy claims they make break down in real-world scenarios.
Stronger approaches are deployed and efficient, but they still need important work to improve usability for end users.

Secure micropayment protocols

Yondon Fu of Livepeer highlighted some security requirements unique to micropayment methods. He shared how Livepeer is making micropayments securely scale.

Takeaways

Micropayments are useful for a variety of applications, in particular those with the potential for ongoing or a high volume of transactions. However, high deployment and transaction costs have stymied widespread adoption.
Security considerations for clients common to most micropayment methods include security of the hot signing key and timely transaction confirmation of additional necessary transactions, even when gas prices fluctuate.
Important considerations for probabilistic micropayments include secure random number generation and protection from replay attacks and double spends.

Designing the Gemini dollar: a regulated, upgradeable, transparent stablecoin

Brandon Arvanaghi of Gemini Trust explained the design decisions that went into the regulated, upgradable, and transparent Gemini dollar, comparing and contrasting it with other implementations.

Takeaways

Upgradability in smart contracts provides a means for response to illicit activities and bugs, but can reduce transparency and expand the attack surface.
Contract modularity, ownership distribution, and “time-locked” upgrades help mitigate these issues.
Take every opportunity to provide multi-level mitigations. Gemini ensures that even if an attacker were to compromise a contract with all of its underlying logic (Impl), its custodian/owner-contract would need to be compromised too, as it is the sole entity to confirm printed tokens.

Property testing with Echidna and Manticore for secure smart contracts

Our own JP Smith introduced the concept of property-based testing and its application to smart contracts. This includes strategies for picking good properties and testing them thoroughly.

Takeaways

Unit Testing is not always sufficient: it tests one individual case at a time, and typically focuses on known cases and failure modes. Property Testing aims to cover unknown cases by specifying generic code invariants.
Echidna is a tool for property testing smart contracts, which is extremely fast and can discover new transaction sequences that violate code properties.
When property-based testing with such tools, you’re sure to hit some conditions that a user might have typically missed in their individual unit tests.

Simple is hard: Making your awesome security thing usable

Patrick Nielsen and Amber Baldet of Clovyr went down infosec memory lane of great-ideas-that-didn’t-quite-catch-on to help attendees think about how to get people to use what they build.

See the full slide deck on SpeakerDeck.

Takeaways

A great idea or tool can often be derailed by its (lack of) usability, undermining its potential to deliver immense real-world value. Sweat the “boring stuff” if you want your worthwhile work to be worth it.
Most end users don’t change settings or look for anything beyond the default, most devs don’t want to mess with complex configs. Practice simplicity at every opportunity and do as much as you can in the background for both.
Regular people care about simplicity, stability and cost. Power users care about implementation details. Developers care about approachability, utility, and ops overhead. Businesses care about technical risk and the bottom line. Put yourself in the shoes of each; don’t expect them to change priorities just because you made something innovative or pure.
Practice what you preach; if we (in the security and “crypto” communities) use tools that are fundamentally insecure or data hungry, how can we expect others to act differently?

Attend the next Empire Hacking on February 12. Join the meetup to RSVP.