No platform can prevent poorly designed apps.
- Daniel Larimer (@bytemaster7) September 14, 2019
As the response to the EOSPlay hack at 14 Sep, 2019 Daniel Larimer said that no platform can prevent poorly designed apps.
I'm stating that in fact, a DAPP development platform can implement a set of features that will prevent such “poorly developed applications” or significantly reduce their number. The purpose of this article is to describe methods for improving security that can be used to achieve this goal.
It should be noted that neither formal verification, better programming languages, automated tests or any other automated methods of security improvement can solve the problem.
There are two layers of the problem.
Security issues are important when developing applications that work with funds.
Application-specific problems and vulnerabilities often affect the reputation of the platform on which they were developed (for example TheDAO hack on Ethereum). The most harmful factor that causes the most hacks and exploits is the mindset of DAPP developers who don't want to pay attention to security of their projects.
Analyzing past hacks of smart contracts, we can conclude that most of them contained a previously known vulnerability that could be easily detected by any code reviewers.
Example 1: Parity Multisig hack involves exploit of the contract flaw that allowed anyone to execute a function that was intended to require owner
permission. The reason for this was the inattentiveness of the contract developer, who made a clear mistake.
Example 2: EOSPlay hack involves exploit of the implementation of Random Number Generator of the EOSPlay smart-contract. It was known in advance that EOS lacks reliable source of entropy and Random Number Generator can not be implemented on-chain securely. If the developers had done their research properly, then they would have learned about this issue of RNG in EOS.
Even the most competent developers make mistakes sometimes. It is important to take all the necessary measures to prevent a potential harm that you DAPP can inflict in case of a fault. This is the responsibility of a DAPP developer and the main problem of most development platforms is that developers tend to ignore this responsibility.
As a result, the proposed set of functions should not only enable developers who care about security to improve their DAPPs, but also force those who don't care about the security aspect to pay attention.
The system must:
Allow for requesting a security audit of a project free-of-charge for the requester.
Allow anyone to request a security audit of any DAPP instead of focusing on offering security auditing service to DAPP developers.
In a user-friendly form, provide ordinary users with information about the status of DAPPs which includes: (1) security audit report if security audit was conducted; (2) availability of source codes; (3) bug-bounty results if the bug-bounty was conducted; (4) other factors. DAPPs that have not passed security enhancement procedures must be marked as "high risk" applications.
Provide a set of security enhancement methods. Based on the experience and analysis of the DAPP launch processes, it can be considered that a security audit conducted by a team of experts is the most effective security improvement method. (Read more here: DAPP security standards)
What if we can use inflation to ensure DAPPs security exactly as it is used to ensure the correctness of mined/produced blocks in various consensus mechanisms?
The main idea of the described security enhancement system is that it is possible to use a built-in source of funding in order to improve the security of smart-contract development platform ecosystem by paying a group of experts who will continuously review DAPPs and report any found vulnerabilities. Since code reviewers are paid at protocol level the security audit can be free for the DAPP developer whose DAPP is audited. Even more - a potential investor can request a security audit of a DAPP that he(she) is going to invest in to get a professional response regarding the safety of the DAPP.
Many blockchain ecosystems in one form or another have a built-in funding mechanism and governance. Many blockchain ecosystems in one form or another have a built-in funding mechanism and governance. A good example is Treasury model implemented in DASH or PIVX. Worker Proposal System and Block Producers are similar tools that receive funding at the protocol level and should distribute it in order to improve the network and ecosystem.
For the described system to have an effective impact on the ecosystem, it is necessary that it consists of three parts:
Security Auditing Department - DAO that represents a kind of freelance-platform for smart-contract security auditors. This organization should handle DAPP reviews and audit requests.
Registry of audited DAPPs - It should be a media resource that provides users with information on existing DAPPs and their security status (or the absence of information regarding DAPP security which renders it risky for potential users/investors). It is important that all participants in the ecosystem take this resource into account, thus incentivising DAPP developers to pay attention to their security status.
On-chain funding source - The funding source must be deployed in order to pay for security auditors work. The funding source must also allow for the replacement of a security department DAO if the results will prove to be inefficient.
Callisto Network is a project that is founded to improve security for the smart contract industry. Callisto Network implements Security Auditing department and Treasury governance/funding model. Callisto Security Department (solidity) has performed more than 300 security audits of various Ethereum/ ETC/ TRX smart-contracts which is enough to draw some valuable conclusions.
Callisto Network was never intended to be a development platform on its own. As a result it quickly turns from "platform that pays for security of its DAPPs" into a "platform that pays for security of DAPPs built on other platforms".
There is a fund locking mechanism (Cold Staking) which is intended to compensate the inflation effect in Callisto however it proves to be not enough at some stage. It is better if the security platform is closely integrated with DAPP development platform in order to ensure the long-term sustainability of both.
It was originally assumed that DAPP developers would promote Callisto in exchange for free audits which should boost the network effect and Callisto adoption as a project.
In reality, this only work when developers are satisfied with the results of the security audit. In some cases, if an issue of medium or high severity is reported and redesign of the smart-contract is suggested DAPP developers tend to ignore the results of the audit and not to mention the Auditor in any way. In some cases, the severity of the reported finding is arguable. The best example here is "owner privileges" functions. While this functions are mostly used to debug a contract or interrupt its workflow in case of a force-majeure these functions pose a potential threat and these are often mentioned at the security audit report.
It would be much better if some independent third parties would promote and announce the results of DAPP security audits thus spreading the word about the Auditor and protecting users from potentially threating applications.
Based on the results of more than 300 completed security audits, thousands of lines of code reviewed and numerous mistakes reported it is possible to draw a conclusion that the current structure of Callisto Security Department is suitable for the task. None of the audited and approved DAPPs ever got hacked for almost two years now.
The next step towards improving the structure of the Security Department is the implementation of DAO smart-contract that will automate the workflow.
Callisto Network lacks the Registry of audited DAPPs component in its design. This component proves to be mandatory as it is much more efficient to target users and educate/convince them to use secure DAPPs instead of trying to convince DAPP developers to pay attention to their codes.
If a DAPP is not audited then users risk their own funds when using such a DAPP while developers mostly risk their customer's funds.
In order to perform a security audit of a specific contract without the permission of the contract developer, the source code of the contract must be published.
The described structure of the security audit department is designed to ensure maximum transparency and verifiability of the work process. Transparency and verifiability are hard to achieve if the Auditor can not highlight and describe an issue publicly.
To ensure the maximum flexibility and efficiency of security auditing as well as a sufficient level of abstraction from the underlying platform the structure and workflow of a Securiy Department must be defined as follows.
There should be two types of participants: auditors and auditing manager.
Auditors actually review the submitted codes and provide reports.
Managers assign auditors to tasks, verify the reports provided by auditors, compare reports to one another and summarize the reported flaws in a final security audit report.
Auditors should work independently of each other. There must be at least three security auditors reviewing each contract to consider the audit completed. Upon completion of the security audit, auditors should receive payments in proportion to the number of reported and missed findings. Auditors should work in a competitive environment, which is achieved by the fact that the budget of the audit request is distributed among the auditors working on this particular request. The greater the weight
of one auditor compared to others, the higher the reward he will receive and the less reward two others will receive (where weight
is determined by the number and severity of reported findings of each auditor).
The budget of a particular security audit request must depend on the length of the code of the auditable contract.
Example: detailed Security Auditor's salary calculation scheme can be found here.
Example: detailed Security Department structure definition can be found here.
The results of each audit request are:
audit request, submitted and verifiable on-chain
at least three security audit reports provided by at least three independent reviewers
summary provided by security manager
The summary and reports must be published and stored in any censorship-resistant storage. As it is relatively expensive to store texts in a blockchain it may be better to rely on alternative storage solutions and only store hashes in the blockchain.
Since each step of the process is transparent and verifiable it is also possible to retain valuable statistics on found/missed vulnerabilities which can also help to develop solutions in order to prevent them in advance.
The described system is intended to prevent such industry-harming events as TheDAO hack, Parity Multisig freeze or EOSPlay hack. Those applications that can cause the greatest harm to the ecosystem must be of higher priority. In most cases, these are applications that will operate with large quantities of funds and become potential targets for hackers.
In order to increase the reliability of the work of the auditing department in the case of critical or especially complex applications, it may be necessary to assign more than three auditors.
The described system can be implemented in a number of smart-contract platforms in order to improve the security of the DAPP ecosystem and protect the users from potentially threatening applications by introducing the specially dedicated component of the platform responsible for security awareness.
EOS GO is funded by EOS ASIA and powered by YOU. Join the community and begin contributing to the movement by adding eos go to your name and joining the EOS GO telegram group.