Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie Daniel Connelly Ethereum Smart Contract Master's Thesis
Ähnlich wie Daniel Connelly Ethereum Smart Contract Master's Thesis (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Daniel Connelly Ethereum Smart Contract Master's Thesis
- 1. Smart Contract Vulnerabilities On the Ethereum Blockchain: A Current Perspective Author: Daniel Connelly Adviser: Dr. Wu-chang Feng
- 2. Blockchain Review Most financial data from hereon has been collected on 02/14/2020
- 3. Blockchain Review - Details Anonymous Users (Wallet Address) (0x12a56b78c…) Immutable Ledger of txns (Stored in “Blocks”) Ledger is distributed Ledger is append-only
- 4. Blockchain Review - Bank Comparison Users -> Wallet Addresses Transactions -> Immutable Blocks Distributed Network Append-only ledger ● Bank Account numbers are tied to an identity. ● Closest is transactions in/among accounts. This system can be tricked, however. ● There is a centralized/decentralized financial system ● Banks may have a mutable database Blockchain Banks
- 5. It All Began With Bitcoin..
- 6. Blockchain Review - Bitcoin ● 03 January 2009 Bitcoin was created (the year I graduated HS) ● Mystery creator(s) named “Satoshi Nakamoto” ● A form of virtual currency -- BTC ● Current price of $10,474.70; most expensive ~$20,000! ● 17.85 Million bitcoins in supply ● “Simple” style: anonymous, immutable, append-only ledger; distributed among a peer-to-peer network
- 8. Ethereum on The Rise? Recent Events. Over the past week (02/14/2020)... ● $168 1 month ago. $117.10 . %68.60 ● The number of active Ethereum addresses has grown by 21.5% ● Transactions have increased by 13.2% ● JPMorgan is in talks to merge its open source Ethereum-based blockchain Quorum with Ethereum startup ConsenSys Disclaimer: I am not advocating investing in any cryptocurrency
- 9. ● Ethereum was created July 30th, 2015. ● Creators were Vitalik Buterin and others ● A form of virtual currency -- ETH ● Highest value was $334. ● 107 Million ETH in supply ● “Simple” style: anonymous, immutable, append-only ledger; distributed among a peer-to-peer network ● ...BUT, also has what is called Decentralized Applications (DApps), or in Ethereum lingo, Smart Contracts ○ “Just” programs ○ Contracts are not all that complex ○ Primarily written in Solidity ○ Compiled to bytecode ○ Deployed to network ○ Ethereum Virtual Machine (EVM) ○ Contracts can act as a mediary by interacting with users Blockchain Review - Ethereum
- 10. Ethereum Review - Smart Contract Properties Contracts are similar to other programs: ● Name: 0x3023868433F6086cd8CE0C4083fe2E11B37ce0B7 ● A user can call a contract; a contract can call other contracts on the blockchain (i.e., programs can call programs) But also are very unique: ● Can hold money inside of them ( tracked by the blockchain ) ● Can send money to wallet or contract addresses ● Can take out middlemen: ○ Trust funds, New forms of currency/assets (“Tokens”), Buying a house, receiving a deed, gambling, gaming…
- 11. Ethereum Review - Solidity Language ● The main language to write these contracts in is Solidity -- a horribly insecure language! ● Here are a listing of different ways to mess up (vulnerabilities): ○ Integer Arithmetic ○ Floating Point Arithmetic ○ Reentrancy ○ Access Control ■ Default Visibility ■ Authentication With tx.origin ■ Signature Verification ■ Unprotected Functions ○ Code Injection via delegatecall ○ Signature Replay Attacks ○ Unchecked External Calls ■ Insufficient Gas Attacks ○ DOS ■ Unexpected Revert ■ Block Gas Limit ■ External Calls without Gas Stipends ■ Offline Owner ...Not Very Solid
- 12. Ethereum Review - Solidity Language ● Dirty Higher Order Bits ● Complex Modifiers ● Outdated Compiler ● Use of Deprecated Solidity Functions ● Experimental Language Features ● Frontend (Off Chain) Attacks ○ Short Address Attack ● Historic Attacks ○ Constructor Names ○ Call Depth Attack ○ Constantinople Reentrancy ○ Solidity Abi Encoder v2 Bug ● References ● Entropy Illusion ● Privacy Illusion ● Miner Attacks ○ Transaction Ordering ○ Timestamp Manipulation ● Unexpected Ether ● External Contract Referencing ● Uninitialized Storage Pointers ● Writes to Arbitrary Storage Locations ● Incorrect Interface ● Arbitrary Jumps with Function Variables ● Variable Shadowing ● Assert Violation
- 13. Blockchain Review - Historical Losses ● Launched April 2016 ● Raised $150M+...in a single address! ● There was a recursive bug -- a “reentrancy bug” ● ~$60M drained from the contract ● Authors reset the chain to an earlier date and fixed the bug ○ A non-immutable act The DAO ((Almost)Loss: June, 2016) Fairwin ((Almost)Loss: Oct. 2019) ● Launched July 2019 ● Once contained $10.5 Mil of ETH ● Multiple bugs -- including the owner of the contract being able to siphon all money out of it ● Loss also (likely) avoided; due to calls to pull out of this contract by the security community
- 14. Vulnerability and Exploit Walkthrough
- 15. Blockchain Review - Details ● A weakness in software systems. ● For example (Integer Overflow) ○ A variable overflows, but is not checked or used in that context. ● Program behaves unexpectedly, but no damages incurred. ● Exploits are attacks which leverage vulnerabilities. ● For example, an Integer Underflow that leads to a bank account amount being flipped to a balance of $2,147,483,647. Vulnerability Exploit
- 16. ● Always a vulnerability and part of an exploit ● The Unprotected Self destruct vulnerability is where a function contains a self destruct call and is public (with no additional logic to stop anyone from executing the self destruct call). ● Can send all the ETH inside of a contract to a specified address before permanently deleting a contracts bytecode on the network. ● In the above code, the method has been declared public, which means anybody can call it (line 1). Furthermore, the person who called it is sent any available ETH in the contract before the bytecode is self-destructed (line 2). Unprotected Self Destruct 1 function close() public { 2 selfdestruct(msg.sender); // send available ETH to the contract invoker 3 } Figure 1 - UNSAFE Self Destruct Example 1 function close() public { 2 if (msg.sender == owner) // caller is owner 3 selfdestruct(msg.sender); // send available ETH to the contract invoker 4 } Figure 2 - SAFE Self Destruct Example
- 17. pragma solidity ^0.6.0; contract MyFaultyContract { address owner = 0x7a2afF8E576ce73bF775Eb2D8E443098c82261eA; function kill() public{ require(msg.sender == owner); // only owner may kill our function! selfdestruct(msg.sender); } function setOwner() public { // Anyone can be owner! owner = msg.sender; } /* Code included for demo */ function seeOwner() public view returns (address){ return owner; } } Self Destruct Demo (A real contract)
- 19. Registry Why not put information about vulnerable contracts in a public database for others to see?
- 20. ● There is NO insurance for Ethereum Wallet Address or Contracts (FDIC, SPIC) ● There exists currently NO official Consumer Report-like, VirusTotal-like, or BBB-like agency to tell users what contracts to avoid ● 50% of general Smart Contract flaws and 78% of the most important flaws can be discovered with static and dynamic analysis!¹ ● Symbolic execution is such a method and detects a wide range of vulnerabilities! ● These vulnerabilities can be programmatically discovered and the output parsed to fit in a database. State Of The Art ₁ TrailOfBits, a security auditing and consulting company https://blog.trailofbits.com/2019/08/08/246-findings-from-our-smart-contract-audits-an-executive-summary/
- 21. Why a Digital Registry? ● Tools can be cumbersome and filled with technical jargon only CS majors or enthusiasts understand ● Tools may not be widely known or advertised to people...individuals don’t know of these tools ● Owners and users of vulnerable contracts cannot be contacted any other way! ○ As mentioned, everything is anonymous on the blockchain ● Getting results takes TIME, ELECTRICITY, and MONEY. ● Contracts can be given a rating indicating levels of risk ○ Like the BBB, Consumer Reports rating system ○ Can use multiple opinions from varying engines (VirusTotal) ● There is a need for a rating of the technologies themselves ○ Mythril, for example, gives erroneous output in Self Destruct Vulnerabilities… ● Vulnerability names need to be unified… ○ E.g., is “Accessible Self Destruct” comparable to “Unprotected Self Destruct”? ₁ TrailOfBits, a security auditing and consulting company https://blog.trailofbits.com/2019/08/08/246-findings-from-our-smart-contract-audits-an-executive-summary/
- 22. Why a Digital Registry? ● Users can search a contract before using it ● Vulnerable contracts are less likely to fill up with ETH and cause a giant exploit later on ● Users can remove their funds from insecure contracts ● Developers are more aware of problematic codebases ● Developers can redeploy new contracts with reduced bugs and divert their users to that contract ● Increases user confidence in a contract and Ethereum as a whole. ● ... ₁ TrailOfBits, a security auditing and consulting company https://blog.trailofbits.com/2019/08/08/246-findings-from-our-smart-contract-audits-an-executive-summary/
- 23. Similar Work ● Consumer Reports, VirusTotal, BBB. ● haveibeenpwned.com ● Contract-library.org ● A rating system - http://ethtrust.org/ ● …? Downside to decentralization: little centralized resource listings
- 24. What Is Symbolic Execution And Mythril Execution?
- 25. Symbolic Execution Walkthrough What if the `if` branch was “Send all ETH to the caller’s address”?
- 27. Symbolic Execution Walkthrough - Mythril ● Mythril discovers a total of 16 vulnerabilities ● Bytecode is disassembled, then LASER -- A Symbolic VM that can run EVM Instructions (not bytecode) -- is used to find vulnerable states ● Mythril is able to traverse all possible states for common vulnerabilities ● States that pose a vulnerability are discovered and then proved ● Mythril proves possible paths by using Z3, an automatic Theorem Prover, to prove or disprove the reachability of a certain state Theorem Proving Paths
- 28. Integer Overflow and Integer Underflow An overflow/underflow happens when an arithmetic operationreaches the maximum or minimum size of a type. E.g., uint8 = 2^8.Overflow could cause if statements to be false when true. Exception State (Assert violation) Flow control reaches a failing Assert() statement. External Call To User-Supplied Address (Reentrancy) A contract calls an external contract that the callee of the contractprovides, opening up the possibility for a reentrancy bug. External Call To Fixed Address (Reentrancy) A contract calls an external contract that the contract has hardcoded,opening the possibility for a reentrancy bug. Delegatecall Proxy To User-Supplied Address (DelegateCALL tountrusted Contract/Callee) A contract uses [address].delegatecall(). Code at target address isexecuted in the context of the calling contract; contract can changelocal storage or drain contract of balance. Dependence on predictable environment variable ● Detects Weak Randomness ● And Timestamp Dependence Numbers controlled by miners are a bad source of randomness asminers can control the output, and by association a variable that isusing that number.
- 29. Use of tx.origin (Use of Deprecated Functions) A deprecated function. May lead to unintended side effects. Unprotected Ether Withdrawal (Ether Thief) Function(s) is not protected with the potential net effect being anyparty may withdraw ETH from the contract. Multiple Calls in a Single Transaction (DOS With Failed Call) If an external call fails accidentally or deliberately, a DoS conditioncan result in the contract as a contract is waiting for a call to return. State change after external call (Reentrancy) A contract may call back into the calling contract before the firstinvocation finishes. This could result in undesirable consequences. Unprotected Selfdestruct (Unprotected Selfdestruct) Any party can call the function that has a self-destruct in itscontract. Unchecked Call Return Value (Unchecked Call Return Value) Return values of a message call must be checked to see if anexception was thrown. Otherwise, the program will continue despitea failed call.
- 30. Use of callcode (Use of Deprecated Functions) A deprecated function. May lead to unintended side effects. Jump to an arbitrary instruction (Arbitrary Jump with Function TypeVariable) A developer may use assembly instruction mstore or the assignoperator, an attacker may point a function type variable to any codeinstruction. Jump to an arbitrary line (Arbitrary Jump with Function Type Variable) A developer may use assembly instruction mstore or the assignoperator, an attacker may point a function type variable to any codeinstruction. Write to an arbitrary storage slot (SWC: Write to an Arbitrary StorageLocation) A contract may write to an arbitrary storage location, which couldhouse the contract owners address for example. An attacker couldbe renamed the contract owner.
- 31. Methodology
- 32. Data Collection ● The registry service was built by interacting with a GETH node to discover contract addresses ● Multiple machines were spun up in Google Cloud Platform ● Each machine ran a Python program that spawned ~10 threads to spawn docker containers where each container was given an address to run the image of Mythril ● Output was separated into bins (i.e., exceptions, errors, or Mythril Output). ● Mythril Output was then parsed to derive each vulnerable contract and its vulnerabilities that were inserted as a row in a table, forming a vulnerable contracts table. https://github.com/ConsenSys/mythril
- 34. Results
- 35. Results ● ~50 days of compute time ● 3,046,140 contracts from the 0-9 millionth block ● Achieved partial analysis through the blockchain 0-~8.4 millionth block ● 797,384 contracts had vulnerabilities in them ● ~%26+ of Ethereum contracts have vulnerabilities ○ didn’t complete analysis up to 9 millionth block ○ live contracts with exploits is a smaller number, and thus a higher ratio ○ time limit constraints on symbolic execution (1 hour) likely yielded less results ○ higher transaction (“call”) count could yield more vulnerabilities (default is 2 in Mythril) ● 1,224,486 vulnerabilities within those 797,384 contracts ● 2,580,565 ETH at risk* ○ $430,128,605 in USD (1/19/2020) * Ether at risk is defined as any contract with money and an exploit(s) inside
- 36. Results(cont)
- 37. Results(cont)
- 38. Results(cont)
- 39. Results(cont)
- 40. The Registry - http://haveibeenexploited.com
- 41. Discussion ● A number of bugs in Mythril cast doubt on some results ○ Self Destructs are not always reliable ○ But the registry is still an important idea ● Some ethical concerns in allowing people to find these contracts. However, a similar system already exists (contract-library.com) and this has not upset the system. ● More analysis needs to be done to detect true enduring patterns and know the security of the blockchain. ● ...But generally the blockchain is pretty safe and is increasing in popularity! ○ Jan 4th, 2018: 1.3 million transactions! the most transactions in 24 hours
- 42. Future Work ● Finish analysis ● Include other engines ○ Akin to virustotal.com ● Automate analysis, parsing, updating of database ● Rating system ○ Based off multiple engines ○ Based of what each engine thinks is severe ● Run deeper transactional analysis on vulnerable contracts (default in Mythril is 2 transactions) ● Collect Z3 outputs from Mythril, sort by high ETH, and determine if exploit exists. ● Update Website (Aesthetics, Cloud Run, etc.). Oyente Manticore echidna
- 43. Special Thanks ● I owe special thanks to Professor of Computer Science Dr. Wu-chang Feng. Without Dr. Feng, I would not have had any knowledge to work with in Blockchain or in Cloud Computing, both of whose subject knowledge this thesis relied heavily on. Furthermore, without his additional guidance in crafting this thesis, I would have gotten into many sticky situations, which were ultimately avoided. ● Finally, thanks must go to the two funders of this project. The first, The National Science Foundation (NSF) grant Curricula and CTF Exercises for Teaching Smart Fuzzing and Symbolic Execution (#1821841). The second source, the Google Faculty Research Grant, which generously gave $5,000 worth of cloud research credits for Google Cloud Platform use. Without the NSF grant and compute resources afforded by these Google Cloud credits, this project would not exist at its current level of maturity. ● I owe another thanks to the Ethereum Foundation for connecting me with a community -- -- the ETHSecurity Community Telegram channel --to ask questions and gain informational resources.