Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Web Apps vs Blockchain dApps (Smart Contracts): tools, vulns and standards

317 views

Published on

Last year at AppSec EU I had a presentation about the Ethereum smart contracts and did a technical showcase of some of their potential vulnerabilities and security flaws. I also presented my proposition on how to handle the responsible disclosure process in the smart contracts world.
This year I want to focus on the whole process of security testing and present it by analogies to the web applications which are quite well-known. Smart contracts are described as Web3 decentralized apps and I believe that my talk will not only bring new light on this subject but will also help to understand and organize the way of testing. I am going to cover the whole SDLC and show the similarities and differences between the smart contracts and web applications on each step.
The presented overview is especially important nowadays when the biggest companies are building their own blockchain platforms and cryptocurrencies – i.e. Libra introduced by Facebook (which by the way also supports smart contracts).
I am also going to show the differences in the arsenal of vulnerabilities, security tools and standards by the analogy to web apps arsenal. I think that, even though there exist a lot of great security projects for smart contracts, we do not have a single, widely accepted security standard (such as ASVS in web apps world). I would like to discuss potential work that needs to be done in that area and show my preliminary work on that matter.
After this presentation audience will know what are the similarities and differences between smart contracts and web apps in the SDLC, an arsenal of tools and standards, but also will have a fresh overview of possible options and current trends.

Published in: Software
  • Be the first to comment

  • Be the first to like this

Web Apps vs Blockchain dApps (Smart Contracts): tools, vulns and standards

  1. 1. www.securing.pl Damian Rusinek Web Apps vs Blockchain dApps (Smart Contracts): tools, vulns and standards OWASP AppSec Global Amsterdam 2019 26th of September 2019
  2. 2. www.securing.pldrdr_zz Damian Rusinek @drdr_zz 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
  3. 3. www.securing.pldrdr_zz Web 3.0 They are using Decentralized Applications or Platforms
  4. 4. www.securing.plwww.securing.pl Decentralized Apps And why are they becoming important? WHAT IS IT?
  5. 5. www.securing.pldrdr_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. 6. www.securing.pldrdr_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. 7. www.securing.pldrdr_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).
  8. 8. www.securing.pldrdr_zz Where is the main difference? Architecture Decentralized ApplicationWeb Application
  9. 9. www.securing.pldrdr_zz Where is the main difference? Architecture Web Application Hybrid Decentralized Application
  10. 10. www.securing.plwww.securing.pl Decentralized Apps ARE THOSE SECURE?
  11. 11. www.securing.pldrdr_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. 12. www.securing.pldrdr_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. 13. www.securing.pldrdr_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
  14. 14. www.securing.plwww.securing.pl Web Apps vs Decentralized Apps WE NEED SECURITY!
  15. 15. www.securing.pldrdr_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?
  16. 16. www.securing.plwww.securing.pl SCSVS - Smart Contracts Security Verification Standard
  17. 17. www.securing.pldrdr_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. 18. www.securing.pldrdr_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
  19. 19. www.securing.pldrdr_zz Software Development Life Cycle SCSVS covers all stages of SDLC process.
  20. 20. www.securing.pldrdr_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.
  21. 21. www.securing.plwww.securing.pl Web Apps vs Decentralized Apps - Analysis & Requirements SDLC
  22. 22. www.securing.pldrdr_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. 23. www.securing.pldrdr_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. 24. www.securing.pldrdr_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. 25. www.securing.pldrdr_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.
  26. 26. www.securing.pldrdr_zz Differences – Randomness SDLC – Analysis & Requirements Web Apps • A matter of a function call Decentralized Apps • Not trivially achieved in the decentralized computer • No local parameters can be used
  27. 27. www.securing.pldrdr_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).
  28. 28. www.securing.pldrdr_zz New threat actors for Decentralized Apps SDLC – Requirements & Analysis • Miners/Validators • Validate transactions and add new blocks
  29. 29. www.securing.pldrdr_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. 30. www.securing.pldrdr_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).
  31. 31. www.securing.plwww.securing.pl Web Apps vs Decentralized Apps - Design SDLC
  32. 32. www.securing.pldrdr_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.
  33. 33. www.securing.pldrdr_zz Differences – Loops SDLC – Design Web Apps • Infinite loops -> DoS Decentralized Apps • Unbound loops -> DoS
  34. 34. www.securing.pldrdr_zz Differences – Loops SDLC – Design • GovernMentals • A ponzi scheme • Iteration over a huge array • 1100 ETH frozen (~220k USD) • 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. 35. www.securing.pldrdr_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.
  36. 36. www.securing.plwww.securing.pl Web Apps vs Decentralized Apps - Implementation SDLC
  37. 37. www.securing.pldrdr_zz • Great tools • Perform basic security analysis • But we still make bugs. • Sounds familiar? ☺ SDLC – Implementation
  38. 38. www.securing.pldrdr_zz Similarities – Arithmetic bugs SDLC – Implementation Web Apps • Not that common Decentralized Apps • Overflows and underflows
  39. 39. www.securing.pldrdr_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. 40. www.securing.pldrdr_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. 41. www.securing.pldrdr_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
  42. 42. www.securing.pldrdr_zz Differences – Recursive calls SDLC – Implementation • 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. 43. www.securing.plwww.securing.pl Web Apps vs Decentralized Apps - Testing SDLC
  44. 44. www.securing.pldrdr_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/
  45. 45. www.securing.pldrdr_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.
  46. 46. www.securing.pldrdr_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. 47. www.securing.plwww.securing.pl Web Apps vs Decentralized Apps - Deployment SDLC
  48. 48. www.securing.pldrdr_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?
  49. 49. www.securing.pldrdr_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
  50. 50. www.securing.pldrdr_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. 51. www.securing.plwww.securing.pl Web Apps vs Decentralized Apps - Maintenance SDLC
  52. 52. www.securing.pldrdr_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.
  53. 53. www.securing.pldrdr_zz Differences – Security Alert and Fix SDLC – Analysis & Requirements 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.
  54. 54. www.securing.pldrdr_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
  55. 55. www.securing.pldrdr_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.
  56. 56. www.securing.pldrdr_zz SCSVS – Future plans • SCSVS is going open-source • Published on GitHub in a few days (October 1st). • Sign up to be informed. • https://bit.ly/2lXiRR9 • OWASP SCSVS?
  57. 57. www.securing.pl Thank you! Damian.Rusinek@securing.pl @drdr_zz or leave me your card! Sign up to be informed about SCSVS: Want a security audit of smart contract? Go for SCSVS!

×