On the Frontlines: Securing a Major Cryptocurrency Exchange

Neil Smithline, Security Architect, Circle twitter, linkedin
abstract slides video

Background

Cryptocurrencies are blockchain-based, decentralized (ish), are tradeable and fungible (e.g. two $1 bills are equivalent) assets, are secured by cryptography. There are ~1,658 cryptocurrencies as of March 2018.

A cryptocurrency exchange provides a place for buyers and sellers to trade cryptocurrencies. If you want to turn Bitcoin into Ethereum, they provide the connection between the people who are buying and selling.

Cryptocurrency exchanges are juicy targets because:

• Transactions are near-instant and withdrawals are final - there’s no way to get the money back (cryptographically impossible).

  • This is quite attractive for criminals, because credit card purchases can be repudiated, bank transfers can be canceled or pulled back, but you can’t do that here.

• The blockchain is anonymous - while most exchanges require you to prove your identity, once you get on to the blockchain itself it’s fairly anonymous.

• Evolving regulation and enforcement

• Truly transnational

• Massive target - December 2 market cap of top-100: $129,893,042,547.

In the rest of the talk, Neil discusses attacks on the application layer, wallets, user accounts, and on currencies themselves.

Attacks on Application Layer

At the application layer, there’s nothing unique about attacking exchanges, the standard OWASP-style web, mobile, API attacks apply: DDoS, XSS, SQLi, CSRF, credential stuffing, etc.

Attacks on Wallets

Wallets are 3rd-party code running within their firewall/VPC.

They have to trust the wallet dev team to some extent, or otherwise they shouldn’t run the wallet or support the coin.

Circle/Poloniex supports roughly 60 currencies, so they have this trust relationship with a number of third parties. There have been cases in the past where exchanges installed a malicious wallet that stole all the currency they were storing, so this isn’t a hypothetical risk.

Defenses

• Minimize exposure of wallets to valuable assets

  • Use Docker/VMs

  • Restrict wallet access to private keys when possible (only supported by some wallets)

  • Maintain minimal currency in online “hot” wallet, the rest is stored on offline “cold” wallets. This restricts a successful attacker to only being able to drain the money in “hot” wallets.

• Supply-chain security

  • Ensure you’re using “official” wallets

  • Verify the identity of wallet developers when communicating with them

Attacks on User Accounts

These types of attacks are not specific to cryptocurrency exchanges.

The core reasoning here is it’s easier to hack a user’s account than an exchange.

Stealing money from banks is much less attractive - how are you going to get the money out? Trying to transfer the money to a bank account you control will still take 3 - 5 days to settle and when the bank finds out they’ll just cancel the transaction, so the attacker won’t get the money.

Circle/Poloniex talsk with other exchanges, and they see individual people stealing $1M / month through attacking user accounts.

Example attacks they see include: phishing sites, computer/mobile device malware, fake “support” sites, email account takeovers (ATOs), SIM swapping, domain takeovers, or social engineer support staff.

Defenses

Strongly encourage (or even require) 2FA - Pester users to add 2FA, and provide strongg 2FA (ideally U2F/Yubikey or Google Authenticator rather than SMS).

They’ve added some protections that for significant operations you need to provide two 2FA codes, separated by at least one time transition, so an attacker has to steal 2 codes to do anything important.

Other protections:

• HaveIBeenPwned integration

• Maximum daily withdrawal limit

• Anti-phishing service - they partner with a company that crawls the Internet looking for phishing sites and mobile stores for copycat apps and gets them taken down.

• Lock/restrict account on significant changes, such as the removal of 2FA

• Risk-based (algorithmic triggered) withdrawal security

  • If something looks phishy, they may make you do a 2FA and/or confirm via email.

  • Other times they’ll block a transaction until they have someone in customer support manually review the transaction. This would be unthinkable in traditional banking, but is not uncommon in cryptocurrencies.

Factors they consider risky include: user with a new IP address, having a recent password/2FA change, new country, use from an email or IP with bad reputation, trading history (some criminals will put a certain amount of value in, then take the same value out, to “launder” it, as they’ll get different Bitcoins back on the withdrawal).

Attacks on Currencies

“51% double-spend attack” lets you spend the same money twice, which requires that the attacker has more hashing power than the rest of the blockchain. This attack has happened in practice: a May 2018 attack on Bitcoin Gold costed 6 different exchanges $18M and a January 2019 attack on Ethereum Classic costed $1.1M.

Defenses

• Know your customer (KYC)

• Withdrawal limits: have a fixed maximum spend/withdrawall limit (lower for new customers) and implement risk-based controls

• Track the currencies’ health carefully and respond quickly

  • Set confirmations appropriately - They don’t transfer funds util they ee at least N confirmations. The more confirmations you require seeing before giving a user the funds, the more expensive it is to do the attack.

They built a tool to show how much it would likely cost to rent the compute cost power to do a 51% attack, the overall available compute that can be rented, and other factors that may indicate how likely an attack is to occur.

Related Work

If you’re into smart contract security, check out the Decentralized Application Security Project (DASP) Top 10, it’s basically the OWASP Top 10 but for smart contracts.