Smart contracts are programs that, once deployed, execute autonomously on blockchains. Depending on the blockchain being used (and the method of smart contract deployment), these smart contracts can be to a smaller or larger extent immutable. Immutable in the sense that once deployed they may not be modifiable by their creator.

If you've ever developed a significant piece of software then you know that deploying SW that is right the first time is extremely difficult as the SW you develop may contain a variety of bugs:

• Logical errors
• Business errors
• Security vulnerabilities

While logical and business errors can be mitigated to some extent, security vulnerabilities in blockchain smart contracts can be much harder to recover from. Smart contracts often control crypto tokens that are pseudonymous and easily transferrable into liquid cash. This makes smart contracts very lucrative targets for bad actors looking to exploit any errors for quick profit at relatively lower risk of detection. In fact this is so common that the blockchain space is rife with incidents of bad actors exploiting smart contracts for real world gain.

Avoidance is better than cure

To avoid these exploits software developers are adapting techniques from off-chain development ranging from:

• Following smart contract development best practices
• Auditing their contracts via a thorough review of the code
• Subjecting their deployed contracts to white hat hackers

In this piece we concentrate on the second of these; auditing your smart contracts to discover vulnerabilities before deployment. Auditing can take two forms. Firstly, what many in the space are familiar with is a manual review of the business and programming logic of your smart contract by a team of experts who are well versed in the state of the art of security vulnerabilities. These experts pore over the design and source code of your smart contracts with the aim of identifying any exploits. Depending on the size and scope of your smart contract this process may take anything from a week to a couple of months and cost anywhere from $50k to $500k. Smart contract auditing is a very specialised skill and so it is unlikely that many of the nascent projects in the space will have such an expert internally. They will typically rely on commissioning an external organisation to conduct their audits.

Even if the organisation commissioning the external security audit is well-funded, multiple iterations through such an audit are likely to be time and cost prohibitive. Organisations therefore leave such audits as the last step before deploying their smart contract to their blockchain of choice. In this world of agile development, this feels rather like going back to the old days of waterfall development. In short, manual security audits are simply not scalable.

A second approach which is now beginning to gain traction is the use of smart contract analysis tools that perform an automated review of the smart contract to identify vulnerabilities. Whilst the results from automated analysis may not catch the full breadth of issues exposed by a properly in-depth manual security audit, automated analysis does have the benefit that it is relatively lower cost and more convenient to execute than a manual audit. This allows automated analysis to be used within the development cycle to catch potential issues prior to the code being submitted for a final manual security audit. Automated analysis also enables developers to leverage the efforts of a handful of expert smart contract security researchers making automated analysis a much more scalable approach.

Automated smart contract vulnerability analysis methods

Automated vulnerability analysis of software programs is a well researched area with a rich pedigree in the off-chain world of web, desktop and enterprise software.  In designing an automated analysis approach, there are two main areas where trade-offs need to be made:

• Reproducibility: what steps need to be taken to exactly trigger a vulnerability define whether or not a vulnerability is reproducible. Some analysis approaches may not capture information on how to trigger a vulnerability and so any vulnerabilities identified may need to be manually verified.
• Semantic insight: Insight into how and why a program, or parts of it, behaves.

Typically automated analyses cannot optimise for both reproducibility and semantic insight. High reproducibility typically means low coverage as to make results reproducible an analysis needs to be able to understand how to reach the code under analysis; removing this requirement means that an analysis can achieve much higher code coverage. However the lack of reproducibility results in a high false positive rate (i.e. a false alarm for a vulnerability that does not actually exist). A high semantic understanding on the other hand may necessitate processing and storing of a large amount of data. Attempting an analysis that achieves both full semantic insight and identifies reproducible vulnerabilities may not be entirely different from executing the smart contract through all of its possible input permutations which is typically unscalable for a smart contract of sufficient complexity.

Automated vulnerability analysis can be divided into two types:

• Static vulnerability analysis: identifies defects before you run a smart contract
• Dynamic vulnerability analysis: identifies vulnerabilities after you run a smart contract

Static vulnerability analysis

Static vulnerability analysis on a smart contract is performed by reasoning about the code without actually executing it. Normally the analysis is done on some representation of the smart contract's source code, either the source code itself or some intermediate form that is above the object code. Occasionally static analysis can also be done on the object code.

Advantages of Static Analysis?

• It can achieve very good coverage of the smart contract under analysis and can often cover every possible execution path
• It can be easier to trace the vulnerability back to the exact location in the code

Static vulnerability analysis does have some drawbacks:

• Results are not reproducible: information on how to trigger the vulnerabilities identified is typically not captured and so the vulnerabilities may need to be verified to avoid false positives.
• Lack semantic insight: They operate on simpler data domains and may have reduced insight into why a part of the smart contract has a vulnerability or what parts of the input cause misbehaviour

Dynamic vulnerability analysis

Dynamic vulnerability analysis is performed by executing the smart contract on a real or virtual processor and subjecting it to test inputs to verify its behaviour under a variety of conditions. Unit testing a smart contract to find errors is one of the most common method of dynamic analysis.

Automated dynamic analysis techniques are split into two main categories: concrete and symbolic execution.

• Concrete execution involves running the smart contract as normal against carefully crafted test cases provided by the user. A common dynamic concrete execution technique is fuzzing, where malformed input is provided to a smart contract in an attempt to discover a vulnerability.
• Symbolic execution executes the smart contract in an emulated environment using symbolic variables and tracking the state of the smart contract throughout program execution. At each conditional branch the analyser follows every path and saves the path condition. The analyser can then use the accumulated path conditions to reason on how to exactly trigger an identified vulnerability.

But how does dynamic analysis fare against static analysis?

Advantages of Dynamic analysis.

• Vulnerabilities identified are highly reproducible as you have the inputs or path conditions required to trigger the vulnerability
• It allows for analysis of smart contracts in which you do not have access to the actual code.

Drawbacks of Dynamic analysis.

• Fuzzers typically require carefully crafted test cases to avoid identifying only shallow vulnerabilities.
• Similar to static analysis, fuzzers have limited semantic insight into what parts of the input caused a vulnerability to be tirggered. This makes it more difficult to trace a vulnerability back to the exact location in the code. Symbolic execution on the other hand offers high semantic insight.
• With symbolic execution the number of condition paths causes an exponential increase in the possible paths to be explored limiting the complexity of smart contracts that can be analysed.

As can be seen from above, both static and dynamic analysis techniques have different advantages and disadvantages. One technique cannot be said to be definitively better than the other. To take advantage of their different attributes we see some of the leading suppliers of smart contract analysis tools use both types of analyses in their offerings.

Top Vulnerability Analysis Tools for Ethereum and EOS

Now that we have a fundamental understanding of the different smart contract vulnerability analysis methods, what tools are available to check your Ethereum and EOS smart contracts for bugs?

1. MythX
   
   SaaS platform that combines static, fuzzing and dynamic symbolic analysis of Ethereum smart contracts. Developed by a Consensys spoke. Offers an API that tools (such as IDEs, web interfaces etc) can use to enable security scanning in their application. Pricing from 199 DAI per user. https://mythx.io/plans
2. Mythril
   
   Developed by some of the team that were behind MythX. Utilises dynamic symbolic execution. Open source and free to use.
3. Securify
   
   Online and open-source security scanner for Ethereum smart contracts that performs static analysis. Online version is free to use, but requires signing over rights to submitted source code.
4. Manticore
   
   Open source dynamic symbolic execution analysis tool. Can analyse Ethereum smart contracts and Linux ELF binaries. Appears to be actively maintained with multiple contributions to its Github repository over the last 3 months.
5. Smartcheck Online and open source static analysis tool that translates Ethereum Solidity code into an XML based representation on which it checks against security patterns. Its Github repository does not show much sign of recent activity.
6. Octopus
   
   Octopus supports basic analysis of smart contracts allowing contract disassembly, control flow analysis and conversion byte code into an Intermediate Representation. Although it is one of the few tools we found that supports both Ethereum's EVM and EOS' WASM byte code formats, it currently cannot run a vulnerability analysis. That is planned in the future through dynamic symbolic execution. Its Github repository does not show much sign of recent activity.

Conclusion

Automated vulnerability analysis is a burgeoning field that will help secure smart contracts.

There are a variety of tools available, but these primarily target the Ethereum ecosystem. We found only one tool that has minimal support for EOS.

Do you know of any tools that we should include in the list? Do you think automated analysis can be a substitute for manual review? Let us know what you think in the comments.