2. www.divergentsecurity.com |
WHAT IS A BLOCKCHAIN?
• Decentralized
– No single point of failure
– Democracy of nodes (clients)
– Strengthened by diversity
• Trustless
– No requirement for trust in any entity (computer, human, company, government)
– Validity of state can be independently verified
• State Machine
– Operates on shared state (Ledger)
– Synchronized execution (Blocks)
– Defined Instruction Set (Virtual Machine Opcodes)
– The power of rejection (Just Say No)
2
Blockchain:
“A Decentralized, Trustless, State Machine”
9. www.divergentsecurity.com |
APPSEC 101: THE RED FLAGS
9
Client / Server
with potentially
malicious peers
Complex message
parsing and data
storage
Virtual Machine that
executes untrusted
instructions
Reliance on complex
cryptographic
concepts
Concurrency
critical both locally
and between peers
Code is responsible
for BILLIONS of
dollars
10. www.divergentsecurity.com |
THREAT MODEL - BIG PICTURE
• Recentralization
– Introduction of a single point of failure
– Some nodes are more “equal” than others
– Network based attacks (Segmentation, node isolation, etc)
• Trustlessness
– Consensus vulnerabilities (bugs in the algorithm)
– Verification vulnerabilities (bugs in the math)
• Infrastructure
– Attacks on critical infrastructure (Exchanges, Mining Pools)
– Connections between the blockchain and the real world
– Websites
• Social Interaction
– Attacks on the people
– Attacks on bad assumptions
10
11. www.divergentsecurity.com |
THREAT MODEL -
IMPLEMENTATION
• Traditional Vulnerabilities
– Bitcoin Core is written in C++ (hundreds of
forks are not as highly vetted)
– Blockchain devs love “Memory Safe”
languages (Go, Rust)
– Prediction: An exploitable race condition in a
GoLang node implementation
• Homogeneity of clients
– One vulnerability impacts EVERYONE
– Simple forced crash == full network DoS
• Virtual Machine
– Bugs within the state machine itself
– Forks of BTC/ETH love to add instructions
11
12. www.divergentsecurity.com |
THREAT MODEL -
CONTRACTS/SCRIPTS
• BTC Transaction Scripts
– Unspent outputs that are “solvable”
– Forks could modify instruction sets to create insecure
outputs
• Bugs in Contracts
– Memory Corruption (Yes! It has happened)
– Authorization Vulnerabilities
– Integer Over/Underflow
– Re-entrancy
– Logic Bugs
– Front Running
– No good random source
– Miner Advantage
• So many vulns, we now have a Top 10:
https://www.dasp.co/
12
13. www.divergentsecurity.com |
WHAT IS A WALLET, ANYWAY
13
0x0102030405060708091011121314151617181920212223242526272829303132
~3.4028237e+38 possible keys
Estimated grains of sand on earth ~= 7.5e+18
Estimated planets in our galaxy ~= 1.0e+11
7.5e+18 x 1.0e+11 = 7.5e+29
15. www.divergentsecurity.com |
WHEN RANDOM ISN’T RANDOM
15
int main () {
unsigned int seed = time(0);
srand(seed);
printf("0x");
for (int i = 0; i < 32; i++) {
unsigned char c = rand();
printf("%02x", c);
}
printf("n");
return 0;
}
16. www.divergentsecurity.com |
LET’S MAKE USERS GENERATE
RANDOM
16
- IOTA requires users to generate their own seed
- Used to generate subsequent private keys and
addresses (public key)
- 81 random A-Z and 9