2. www.securing.pldrdr_zzdrdr_zz
Damian Rusinek
damianrusinek @ github
โข Pentester
โข Researcher
โข Focused on blockchain and smart contracts
Security Researcher & Pentester
Assistant Professor
Introducing Decentralized Applications by analogy to Web Apps
https://bit.ly/2kpfKkm
Last year on AppSec EU London
& OWASP Poland Day Warsaw
drdr_zz
5. www.securing.pldrdr_zzdrdr_zz
What are Decentralized Applications?
โข Decentralized Application are like Web Applications with decentralized
storage and governance.
โข Web Apps
โข Facebook
โข Reddit
โข Decentralized Apps
โข Steemit (a kind of decentralized Reddit)
6. www.securing.pldrdr_zzdrdr_zz
Why are Decentralized Applications important?
โข There exist great projects already:
โข Augur (decentralized oracle and prediction market),
โข Gnosis (prediction platform),
โข MakerDAO (decentralized finance).
โข The market is worth billions of $ in cryptocurrencies.
โข A chance for new technologies (e.g. financial technology)
โข Easy decentralized banking,
โข No brokers (direct payments).
โข Big players:
โข Hyperledger (Linux Foundation, IBM, Intel, SAP),
โข Libra (Facebook).
7. www.securing.pldrdr_zzdrdr_zz
What is so special about Decentralized Apps?
โข Trustlessness: Use blockchain to store code and data (state).
โข No one can turn it off permanently (anyone can bring it to live).
โข Everyone can have it (like keeping the database of FB or Reddit locally).
11. www.securing.pldrdr_zzdrdr_zz
Are Decentralized Apps secure?
โข Undestroyable: No one can turn it off
โข Cryptographically secure: All transactions are digitally signed
โข Publicly verifiable: Anyone can verify the code of smart contracts
โข But stillโฆ.
12. www.securing.pldrdr_zzdrdr_zz
Are Decentralized Apps secure?
โข Undestroyable: No one can turn it off
โข Cryptographically secure: All transactions are digitally signed
โข Publicly verifiable: Anyone can verify the code of smart contracts
โข But stillโฆ.
13. www.securing.pldrdr_zzdrdr_zz
Are Decentralized Apps secure?
โข Undestroyable: No one can turn it off
โข Cryptographically secure: All transactions are digitally signed
โข Publicly verifiable: Anyone can verify the code of smart contracts
โข But stillโฆ.
Expectations Reality
15. www.securing.pldrdr_zzdrdr_zz
Security Projects & Standards
Web Apps
โข Most common vulnerabilities?
โข OWASP Top 10
โข The knowledge base about the
weaknesses?
โข Mitre CWE (Common Weakness
Enumeration)
โข The end to end security checklist to
perform an audit?
โข OWASP ASVS (Application
Security Verification Standard)
Decentralized Apps
โข Most common vulnerabilities?
โข DASP Top 10 (https://dasp.co)
โข The knowledge base about the
weaknesses?
โข SWC Registry
(https://smartcontractsecurity.github.io/SWC-registry/)
โข The end to end security checklist to
perform an audit?
17. www.securing.pldrdr_zzdrdr_zz
โข Objectives:
โข Provide a checklist for architects, developers and security
reviewers.
โข Help to mitigate known vulnerabilities by design.
โข Help to develop high quality code of the smart contracts.
โข Provide a clear and reliable assessment of how secure the
smart contract is in relation to the percentage of SCSVS
coverage.
โข Format similar to ASVS.
SCSVS - Objectives
18. www.securing.pldrdr_zzdrdr_zz
SCSVS - Categrories
V8: Business Logic
V9: Denial of Service
V10: Token
V11: Code Clarity
V12: Test Coverage
V13: Known Attacks
V1: Architecture, Design
and Threat Modelling
V2: Access Control
V3: Blockchain Data
V4: Communications
V5: Arithmetic
V6: Malicious Input
Handling
V7: Gas Usage & Limitations
20. www.securing.pldrdr_zzdrdr_zz
โข Approaches
โข OWASP SAMM
โข SDL (Security Development
Lifecycle)
โข BSIMM (Builing Secuirty in Maturity
Model)
Software Development Life Cycle
DISCLAIMER
This is not a presentation about how
to introduce security to your SDLC.
22. www.securing.pldrdr_zzdrdr_zz
Similiarities
โข Threat modelling
SDLC โ Analysis & Requirements
1.1 Verify that the every introduced design change is preceded by an earlier threat
modelling.
1.2 Verify that the documentation clearly and precisely defines all trust boundaries
in the contract (trusted relations with other contracts and significant data flows).
23. www.securing.pldrdr_zzdrdr_zz
Differences โ Sensitive data
SDLC โ Analysis & Requirements
Web Apps
โข Stored in protected database
Decentralized Apps
โข Stored on public blockchain
โข Forever
โข Anyone can read
3.1 Verify that any data saved in the contracts is not considered safe or private
(even private variables).
3.2 Verify that no confidential data is stored in the blockchain (passwords, personal
data, token etc.).
24. www.securing.pldrdr_zzdrdr_zz
Differences โ Public access
SDLC โ Analysis & Requirements
Web Apps
โข Allowed only to part of application
โข Frontend
โข API
Decentralized Apps
โข Allowed to the whole application
โข Code is public
โข Functions are public by default
25. www.securing.pldrdr_zzdrdr_zz
Differences โ Public access
SDLC โ Analysis & Requirements
โข Parity Wallet hack
โข 150k ETH stolen (~30kk $)
โข https://bit.ly/2kpfKkm
2.7 Verify that visibility of all functions is specified.
27. www.securing.pldrdr_zzdrdr_zz
Differences โ Randomness
SDLC โ Analysis & Requirements
โข EOSPlay hack
โข 30k EOS stolen (~100k USD)
โข SmartBillions Lottery hack
โข 400 ETH stolen (~80k USD)
โข https://bit.ly/2jJEKPd
7.5 Verify that the contract does not generate pseudorandom numbers trivially
basing on the information from blockchain (e.g. seeding with the block number).
29. www.securing.pldrdr_zzdrdr_zz
New threat actors for Decentralized Apps
SDLC โ Requirements & Analysis
โข Augur vulnerability
โข DoS on smart contract
โข Business logic abuse by miner
โข 5k $ bounty
https://hackerone.com/reports/377398
30. www.securing.pldrdr_zzdrdr_zz
New threat actors for Decentralized Apps
SDLC โ Requirements & Analysis
8.1 Verify that the contract logic implementation corresponds to the
documentation.
8.3 Verify that the contract has business limits and correctly enforces it.
9.3 Verify that the contract logic does not disincentivize users to use contracts (e.g.
the cost of transaction is higher than the profit).
32. www.securing.pldrdr_zzdrdr_zz
Similiarities
โข Least privilege rule
โข Access control
โข Public and known to everyone
โข Centralized and simple
SDLC โ Design
2.3 Verify that the creator of the contract complies with the rule of least privilege and
his rights strictly follow the documentation.
2.11 Verify that all user and data attributes used by access controls are kept in trusted
contract and cannot be manipulated by other contracts unless specifically authorized.
34. www.securing.pldrdr_zzdrdr_zz
Differences โ Loops
SDLC โ Design
โข GovernMentals
โข A ponzi scheme
โข Iteration over a huge array
โข 1100 ETH frozen
โข https://bit.ly/2kVXwaj
7.3 Verify that the contract does not iterate over unbound loops.
8.8 Verify that the contract does not send funds automatically but it lets
users withdraw funds on their own in separate transaction instead.
35. www.securing.pldrdr_zzdrdr_zz
Decreasing the risk
SDLC โ Design
โข Decentralized Applications keep cryptocurrencies
โข The higher the amount the bigger the incentive for hackers
1.8 Verify that the amount of cryptocurrencies kept on contract is controlled and at
the minimal acceptable level.
39. www.securing.pldrdr_zzdrdr_zz
Similarities โ Arithmetic bugs
SDLC โ Implementation
โข Multiple ERC20 Smart Contracts
โข Allow to transfer more than
decillions (10^60) of tokens
โข https://bit.ly/2lWa9ma
โข https://bit.ly/2ksNEF1
40. www.securing.pldrdr_zzdrdr_zz
Similarities โ Arithmetic bugs
SDLC โ Implementation
5.1 Verify that the values and math operations are resistant to integer
overflows. Use SafeMath library for arithmetic operations.
5.2 Verify that the extreme values (e.g. maximum and minimum values of the
variable type) are considered and does change the logic flow of the contract.
5.3 Verify that non-strict inequality is used for balance equality.
41. www.securing.pldrdr_zzdrdr_zz
Differences โ Recursive calls
SDLC โ Implementation
Web Apps
โข Must be explicitly included in the
logic
Decentralized Apps
โข Executing some logic multiple times
in one call
โข The DAO hack
โข Recursive withdrawals
โข 3.6 mln ETH stolen
โข https://bit.ly/2hBQjKq
4.5 Verify that re-entrancy attack is mitigated by blocking recursive calls from
other contracts. Do not use call and send function unless it is a must.
4.6 Verify that the result of low-level function calls (e.g. send, delegatecall,
call) from another contracts is checked.
43. www.securing.pldrdr_zzdrdr_zz
Similarities โ Great tools for automatic scans
SDLC โ Testing
Web Apps Decentralized Apps
1.11 Verify that code analysis tools are in use that
can detect potentially malicious code.
https://securify.ch https://bit.ly/2mpaL3U
https://tool.smartdec.net
https://mythx.io/
44. www.securing.pldrdr_zzdrdr_zz
Similiarities โ Ensuring the testing takes place
โข including manual security tests
SDLC โ Analysis & Requirements
12.1 Verify that all functions of verified contract are covered with tests in the
development phase.
12.2 Verify that the implementation of verified contract has been checked for
security vulnerabilities using static and dynamic analysis.
12.3 Verify that the specification of smart contract has been formally verified.
12.4 Verify that the specification and the result of formal verification is included in
the documentation.
1.3 Verify that the SCSVS, security requirements or policy is available to all
developers and testers.
45. www.securing.pldrdr_zzdrdr_zz
Similiarities โ Business logic errors
โข Hard to find using automated scans
โข MakerDAO vulnerability
โข Allows to create DAI
cryptocurrency without
coverage
โข 25k $ bounty
SDLC โ Analysis & Requirements
1.10 Verify that the business logic in contracts is consistent. Important changes in the logic
should be allowed for all or none of the contracts.
8.2 Verify that the business logic flows of smart contracts proceed in a sequential step order
and it is not possible to skip any part of it or to do it in a different order than designed.
https://hackerone.com/reports/672664
47. www.securing.pldrdr_zzdrdr_zz
Differences โ Initialization stage
SDLC โ Deployment
Web Apps
โข Setting up configurations and
integrations
โข Performed once during deployment
Decentralized Apps
โข Setting up configurations and
integrations
โข What if one can (re-)initialize the
contract?
48. www.securing.pldrdr_zzdrdr_zz
Differences โ Initialization stage
SDLC โ Deployment
โข Parity Wallet hack (2nd):
โข Kill contract shared by hundreds
of other contracts
โข 500k ETH frozen (~100kk USD)
โข https://bit.ly/2kIBYhA
โข https://bit.ly/2kpfKkm
49. www.securing.pldrdr_zzdrdr_zz
Differences โ Initialization stage
SDLC โ Deployment
11.7 Verify that all storage variables are initialised.
2.8 Verify that the initialization functions are marked
internal and cannot be executed twice.
9.1 Verify that the self-destruct functionality is used only
if necessary.
51. www.securing.pldrdr_zzdrdr_zz
Similarities โ Logs
SDLC โ Maintenance
Web Apps
โข Kept safe on the server
Decentralized Apps
โข Public events
3.4 Verify that there is a component that monitors access to sensitive
contract data using events.
52. www.securing.pldrdr_zzdrdr_zz
Differences โ Security Alert and Fix
SDLC โ Maintenance
Web Apps
โข Application goes down
โข The bug is fixed (patch)
โข Application redeployed
Decentralized Apps
โข Smart contract goes down
โข The bug is fixed (patch)
โข Smart contract deployed again
1.6 Verify that there exists a mechanism that can temporarily stop the sensitive functionalities of the contract in
case of a new attack. This mechanism should not block access to the assets (e.g. tokens) for the owners.
1.4 Verify that there exists an upgrade process for the contract which allows
to deploy the security fixes.
53. www.securing.pldrdr_zzdrdr_zz
Security Projects & Standards
Web Apps
โข Most common vulnerabilities?
โข OWASP Top 10
โข The knowledge base about the
weaknesses?
โข Mitre CWE (Common Weakness
Enumeration)
โข The end to end security checklist to
perform an audit?
โข OWASP ASVS (Application
Security Verification Standard)
Decentralized Apps
โข Most common vulnerabilities?
โข DASP Top 10 (https://dasp.co)
โข The knowledge base about the
weaknesses?
โข SWC Registry
(https://smartcontractsecurity.github.io/SWC-registry/)
โข The end to end security checklist to
perform an audit?
SCSVS
54. www.securing.pldrdr_zzdrdr_zz
V13: Known attacks
SCSVS โ The special category
โข Quick check for well known attacks
13.4 Verify that the contract is not vulnerable to Silent Failing Sends and
Unchecked-Send attacks.
[4.6] Verify that the result of low-level function calls (e.g. send, delegatecall, call)
from another contracts is checked.
[4.7] Verify that the third party contracts do not shadow special functions (e.g.
revert).
13.2 Verify that the contract is not vulnerable to Reentrancy attack.
[4.5] Verify that the re-entrancy attack is mitigated by blocking recursive calls from
the other contracts. Do not use call and send functions unless it is a must.