This slide is a entry level introduction to blockchain security, it illustrates the current status of the issue, summarises attack methodology, and reviewed a few past hack cases.

1. Brief Introduction To Blockchain Security
Johnson Zhang
1

2. Blockchain - Hacker’s ATM Machine
“More than 980,000 bitcoins have been
stolen from exchanges, which would be
worth more than USD $15 billion at current
exchange rates.”
Reuters on 7 December 2017
“Roughly USD $1.1 billion worth of crypto-
currency was stolen in the first half of
2018.”
Carbon Black on 7 June 2018
2
Total crypto market cap: Around 250 billion

3. Hacker’s Objective
To Hackers:
Cryptocurrency = Money
How?
Steal Cryptocurrency Directly
or
Steal Private Key to Obtain Cryptocurrency
3

4. Classic Attack: 51 % Attack
● In PoW blockchain (like Bitcoin): Longest Chain Wins
○ When the node see two versions of blockchain, the longer chain
would be picked, and the shorter one would be discarded
● In theory, if the hacker can control 51% (or more) of the
overall hashpower, he can produce new blocks faster
than the public network
4

5. Classic Attack: 51 % Attack
● The hacker will do mining without broadcast to the public
○ A secret version of the chain will exist
● When hacker broadcasts the secret chain, the original
chain would get discarded, because Longest Chain Wins
● The hacker can include transaction in the original chain,
and later force everyone on to the new chain
5

6. Classic Attack: 51 % Attack
● Very difficult and expensive to perform on Bitcoin chain
○ Need to control HUGE hashpower
● But not impossible …
○ 56.3% of the hashpower “controlled” by Bitmain
○ Lack the motivation to conduct the attack
■ Miners can switch mining pool at will
■ Act honestly can earn more consistently
owned
lead the
investment
Alliance
6

7. Classic Attack: 51 % Attack
● But not so difficult on less popular chains…
○ https://www.crypto51.app/
○ Real attacks did happen on some of the smaller coins like Bitcoin Gold, Verge,
etc.
7

8. How Hackers Attack the Blockchain
Hack the protocol
● Design issue
● Code flaw
● Vulnerable node
● Logic errors Hack the exchange
● Application
vulnerability
● Employee computer
compromise
● Cloud infrastructure
compromise
● DNS service hijack
● Rogue insider
● Customer
credentials
compromise
● Denial of Service
attack
Hack the miner / mining
pool
● Physical breach
● Malware
● Hosting account
compromise
● Rogue insider
Hack the wallet
● Design flaw
● Social
engineering
● Credential theft
● Malware
Not in the diagram
● ICO Scam
● Cloud mining scam
● Hacked scam
● Kidnap and violence
● ...
8

9. Crypto Institution Hacks In The Past
Data source: https://magoo.github.io/Blockchain-Graveyard/
The security of blockchain not only depends on blockchain
concepts like decentralization, consensus and smart
contract, it’s also closely related to traditional cyber security
mechanisms.
9

10. Case Study 1: Exchange Hack
Mt Gox Hack in 2011-2013
● BitcoinCore before 0.4.0 (released in Sep 2011) doesn’t
support native private key encryption
● Mt Gox’s wallet.dat file (contains private key for the hot
wallet in plaintext) was stolen via remote hacking or insider
theft
● Mt Gox wasn’t aware of the key theft for years
● Users keeps depositing into the hot wallet
● In total 744,000 Bitcoins had been lost (6% of the total 12.4
mil Bitcoin in circulation in Q4 2013)
References:
https://bitcoin.org/en/release/v0.4.0
https://blog.wizsec.jp/2017/07/breaking-open-mtg
ox-1.html
10

11. Case Study 2: Exchange User Hack
Binance Attack in March 2018
● Hackers using URLs like www.biṇaṇce.com to steal user credentials
● Bypass 2FA by double login, and create API for auto trading
● In 48 hours, BTC drop 20%, global crypto market cap drop 15%
1. User login with
credentials and OTP
2. Hacker redirect user to the real
Binance
3. Hacker login using valid OTP
within 30 sec
Altcoins BTC VIA
VIA BTC
Withdraw
(Failed)
Compromised accounts
Hacker’s accounts
Phishing
API
Trading
Reference: https://cryptobriefing.com/binance-suspends-withdrawals-after-possible-api-breach/
11

12. Case Study 3: Mining Pool Hack
Slush Pool hack in March 2012
● Early days of CPU/GPU mining era, Slush pool has a mining
market share of 13%
● Slush Pool’s cloud infrastructure provider, Linode, got
hacked
● According to Linode “an intruder accessed a web-based
Linode customer service portal”
● Hackers compromised Slush Pool’s hot wallet that
contained 3000+ BTC
● The Linode hack also affected the community, including:
○ Gavin Andersen, founder of Bitcoin Foundation
○ Bitcoinica, a well known Bitcoin trading platform
● Total loss up to 46,703 BTC (0.5% of the world’s total BTC at
the time of the hack)
References:
http://archive.is/tRQ9#selection-78.10-78.14
https://blog.trezor.io/how-trezor-was-born-from-a-hacking-attack-that-affected-slush-pool-7a538f03fd8f
12

13. Case Study 4: Wallet Hack
MyEtherWallet Hack in April 2018
● MyEtherWallet is a popular online service for
cryptocurrency transactions
○ An interface to interact with the blockchain
○ User upload private key in order to make a transaction
○ MyEtherWallet won’t hold user’s funds/private key
● Hackers hacked into the BGP router in the ISP
● Users were redirected by false DNS record to a fake
website, and wallets got emptied
AWS
ISP
Server
Hacked
BGP
Router
Fake site
MyEtherWallet
server in
Russia
DNS redirect to
AWS Route 53
User
13

14. Lessons Learned from Case 1-4
● Blockchain is effectively decentralized, but the solutions
built around blockchain is still centralized (also the
infrastructure…)
○ Exchange
○ Mining pool
○ …
● Problems of centralization:
Single Point of Failure
● Possible solutions:
Decentralized Everything?
14

15. Case Study 5: Protocol Hack
BEC Overflow Vulnerability in April 2018
BEC is a ERC20 token written in Solidity
● Problematic function: batchTransfer
○ Send a fixed amount of token (_value) to an array of receivers
(_receivers), the number of receivers in the array is (cnt)
● Maximum value for an uint256 parameter is 2^256-1
● Hackers set _value=2^255, cnt=2, amount overflowed to be 0
● require(_value > 0 && balances[msg.sender] >= amount) Always
true! function batchTransfer(address[] _receivers, uint256 _value) public returns
(bool) {
uint cnt = _receivers.length;
// Total number tokens withdrawn from the sender.
uint256 amount = uint256(cnt) * _value;
require(cnt > 0 && cnt <= 20);
// Check if the sender can afford it.
require(_value > 0 && balances[msg.sender] >= amount);
// Withdraw the amount from sender.
balances[msg.sender] = balances[msg.sender].sub(amount);
for (uint i = 0; i < cnt; i++) {
// Transfer _value to each of the receiver.
balances[_receivers[i]] = balances[_receivers[i]].add(_value);
Transfer(msg.sender, _receivers[i], _value);
}
// Succeeds or die.
return true;
}
Result:
● Sender sent 0
token!
● Receiver each get
2^255 tokens!
15

16. 16
Lessons learned from Case 5
● Security is often the least concerned aspect for a
startup (which is the reality but not the right thing to
do in blockchain field)
● Smart contracts were often developed by developers
without a security mindset
● Security frameworks for references
○ OpenZeppelin
(https://github.com/OpenZeppelin/openzeppelin-solidity)
○ CryptoCurrency Security Standard
(https://cryptoconsortium.org/standards/CCSS)
○ Smart Contract Best Practices
(https://github.com/ConsenSys/smart-contract-best-practi
ces)
Reference:
https://etherscan.io/token/0xc5d105e63711398af9bbff092d4b6769c82f793d?a=0xb4d30cac5124b46c2df0cf3e3e1be05f42119033