Witnet Smart Contracts Security Audit Results

Witnet’s smart contracts have gone through an external security audit, in preparation for Mainnet.

Mario Cao
The Witnet Oracle Blog
4 min readJun 4, 2020

--

Witnet’s Ethereum smart contracts are the gateway into the Witnet network, and with the security of applications that rely on Witnet at stake, they must be bullet-proof. With that in mind, the following steps are critical during our development process:

  • Open-source: All the code and research developed in Witnet is open-source. As a result, any community member can contribute by peer-reviewing and alerting the community to potential vulnerabilities at both the protocol and the code level.
  • Testing, testing and more testing: Testing the entire code is a necessary (but not sufficient) condition to merge any Pull Request. Thus, all the code is put through an exhaustive test suite that runs on every push in Travis and GitHub Actions.
  • Peer code reviews: As part of our development process, any Pull Request submitted to Witnet repositories goes thorough several reviews from other Community Members before it can get committed to the repository.
  • Internal audits: Once the code is considered stable (i.e. there have been no significant changes during the last iterations), an exhaustive internal security audit is done by using static analysis tools such as MythX or SmartCheck.
  • External audits: Finally, the community has chosen to hire Red4Sec (after a lengthy decision process) to conduct external security audits of the smart contracts.

Outcomes of the external security audit

The community asked Red4Sec to perform an analysis of the core components of the infrastructure which enable the interaction between Witnet and Ethereum. These components comprise of the following cryptographic libraries and smart contracts:

In particular, a thorough audit of the smart contract security measures was requested, in order to identify possible errors in the design, configuration or programming. The main goals are to guarantee the confidentiality, integrity and availability of the information accessed, treated, and stored.

Red4Sec dove deeply into the Witnet Network Protocol and its Smart Contracts, reviewing the technical aspects of the complete ecosystem. The subsequent report included 19 vulnerabilities classified in the following levels of risk according to the impact level defined by CVSS (Common Vulnerability Scoring System).

Summary of security audit vulnerabilities

The complete external security audit report can be found here.

Mitigation of vulnerabilities

After numerous discussions with the auditors, Witnet defined a mitigation plan by producing a technical response for each vulnerability (where possible) along with a pull request fixing or mitigating each issue. Most of them were easy to address by following the recommendations suggested by Red4Sec, while others required further discussions and more lengthy code fixes.

Some of the most interesting ones (classified as critical):

  • Replay Proof of Inclusion (PoI) Attack: a vulnerability that enabled attackers to report an old data request as a valid result for identical data requests executed at a later point in time. The issue was addressed by pulling the latest Witnet block epoch from Block Relay and ensuring that the data request lifecycle is always completed after that epoch has passed.
  • Race condition in the Witnet Request Board: a vulnerability that allowed any Ethereum user to listen to result insertion transactions, copy them and claim the rewards without doing any work. The issue has been mitigated by ensuring only legit nodes can report results (i.e. nodes that have proven to do recent work and are members of the Active Bridge Set).
  • Drain of contract funds in Witnet Request Board: this vulnerability describes a potential drain of funds if zero-length results are posted in the Witnet network. As this would indicate an invalid result, a guard was included to ensure the results are not zero-length.

The complete mitigation plan, which details the procedure to fix these vulnerabilities can be found here.

Acknowledgements

Special thanks to Gorka and Thomas, as this post is a common effort between the 3 of us.

--

--