Resolving the problems of DApp insurance: developers hacking themselves

This article breaks down the most pressing issue of a DApp insurance organization described at my previous article: DApp developers can hack themselves to receive the remuneration provided by insurance contract.

The problem.

DApp developer can:

1. Develop a ‘malicious’ smart-contract that can be hacked.
2. Insure the smart-contract at the DApp Insurance Organization.
3. Exploit a vulnerability of the contract to withdraw the funds operated by the contract.
4. Claim that the contract was hacked and request the remuneration from the DApp Insurance Organization according to the insurance agreement.

The method of the development of a ‘malicious’ smart-contract may also differ by the principle of the vulnerability:

Method #1: directly exploitable vulnerability added on purpose. Contract developer can implement a directly exploitable vulnerability and rely on an assumption that it will not be exploited by anyone else after the deployment of the contract.

Method #2: exploiting the owner privileges. Contract developer can implement a special debugging function that will allow an “owner” of the contract (account that was used to deploy the contract or a certain set of pre-defined accounts) to manipulate the contract.

Method #3: malicious upgrade. Some smart-contract systems allow for upgrade of the smart-contracts (contracts are upgradeable in EOS for example) and the developer of the smart-contract can implement a ‘malicious’ function during the upgrade process of the smart-contract.

The method of preventing the problem.

In order to prevent the described problem a DApp Insurance Organization must adhere to the following principles.

1. Security audit of a smart-contract code is mandatory for DApp developer to sign an insurance agreement.

The DApp Insurance Organization must collaborate with a Security Auditor. Security Auditor should be independent from the Insurance Organization in order to ensure fair distribution of incentives and responsibilities. The Security Auditor must perform the review of submitted smart-contracts and provide a publicly available audit report. The report must be stored in some censorship-resistant and transparent data structure like IPFS.

Security Audit report must contain the information about the findings, possible threats, owner privileges that can be used to manipulate the contract in theory and the conclusion.

The smart-contract can be insured if the “conclusion” of the security audit states that the contract is ready to use.

A smart-contract developer must request a security audit of the contract before applying for the insurance agreement. The contract must pass the security audit and all the found high-threat issues must be fixed.

This is a responsibility of the security auditor to track and describe the vulnerabilities of the contract.

2. Smart-contract Insurance Organization must establish a hack investigation department.

A group of smart-contract security experts must be responsible for investigating the hacks.

The hack investigation department and The Auditor must identify the exact feature of the smart-contract that lead to the hack. Then a special “Hack investigation report” must be formed, published and uploaded to the censorship-resistant data structure alongside the security audit reports.

Hack investigation report must be compared to the security audit report of the smart-contract being hacked. A high level of transparency is ensured by the fact that both reports are publicly available and securely stored in a censorship-resistant data system.

Depending on the results of comparison between Hack investigation report and Security audit report there are multiple possible scenarios:

• The exploited feature of the contract was not described during the security audit. In this case the Insurance Organization must compensate the amount of funds being stolen during the hack.
• The exploited feature of the contract was described during the security audit as ‘owner privilege’. In general this means that the contract developers exploited their privileges to hack themselves on purpose. In most cases the Insurance Organization must not compensate this losses unless a smart-contract developers can prove that they couldn’t exploit the owner privilege feature. In case they can further investigation is necessary.
• The exploited feature of the contract was described during the security audit but it was not fixed by the developer. The Insurance Organization must review the security audit report before signing an agreement with the smart-contract developer. All the findings described at the report must be taken into account. This is the responsibility of the Insurance Organization to describe which cases are considered a “hack” in the insurance agreement. If the security audit report states that some features of the contract are considered vulnerabilities or pose a risk of fund losses then the Insurance Organization must not sign the agreement with the smart-contract developer before the fix is applied and the contract is audited again.
• The exploited feature is not a feature of the smart-contract but a fault of some peripheral service or underlying platform. This cases must be described and resolved according to the insurance agreement. In general if the flaw that lead to the financial loss was known at the moment of the security audit then it is the responsibility of the Auditor to highlight it at the publicly available security audit report. If it is provable that the flaw that lead to the financial loss was known, documented or the effect was predictable and The Auditor failed to describe it then the Insurance Organization must compensate the financial loss of the smart-contract developer (if the insurance agreement does not have any specific descriptions regarding such situations). If it was impossible for the Auditor to identify the flaw or the flaw was not directly related to the security of the audited smart-contract then the Insurance Organization must describe this at the Hack investigation report.
• The exploited feature was not presented at the contract during the last security audit. Upgrading the smart-contract leaves it in unaudited state. Insurance Organization is not responsible for compensating any losses of unaudited smart-contracts.

3. Insurance Organization and the insured smart-contract developer must coordinate the updates and re-audits of the smart-contracts.

If the developer of the smart-contract is willing to perform an update then the new version of the smart-contract must pass the security audit before the updating procedure. The contract developer must request the audit of the smart-contract and fix the described findings if necessary.

The security audit report must be published before the updating procedure. The hash of new contract code must be published to make it possible to verify that the developer has upgraded the contract to the exact audited version without introducing any additional functions and pieces of code.

In some cases it may be necessary to perform an emergency update of a smart-contract. If the developer has planned this in advance then he must request the security audit of any “fallback version” of the smart-contract prior to using it in case of emergency update.

Any update of the smart-contract to unaudited version that lead to financial loss for smart-contract developers or their customers must not be compensated by the Insurance Organization.

4. “Feeding” the hacker.

In many cases hacks are continuous and they take hours (example: EOSPlay hack) or even weeks (example: TheDAO hack).

If the developer of the smart-contract has implemented a function to stop/emergency upgrade the contract then he can stop the continuous hack thus minimizing the losses.

In case of developers being responsible for the consequences on their own they have incentives to prevent the ongoing hack. However, when the contract is insured the developers have little to no incentives to stop the hack even if they can. This is especially relevant if 100% of the funds operated by the contract are insured.

Moreover in case of a successful hack the attacker may contact the developers of the smart-contract asking them not to stop the ongoing attack in exchange for some portion of “stolen” funds. With on-chain communications evolving quickly it became a possible scenario even if the developer and the attacker did not coordinate the hack in advance.

In order to prevent such accidents and minimize the unnecessary losses for the Insurance Organization the responsibility of the developer of the insured contract must be described at the insurance agreement.

The developer must:

• Respond to critical warnings and requests from the Insurance or the Auditing team no later than X hours later.
• Implement and utilize the emergency freeze functions if requested by the Insurance team or the Auditor in order to freeze the state of the smart-contract for further investigation.
• Perform an emergency upgrade of the smart-contract if requested by the Insurance team or the Auditor.

5. WONTFIX cases.

Despite the level of threat or the harm dealt some bugs and problems of smart-contracts and smart-contract development standards could remain in WONTFIX state.

It proves to be hard to force the developers to never use or interact with services that can contain a WONTFIX issues. In some cases it may be unavoidable to rely on such services. However this can cause the financial loss for developers of a smart-contract or their customers. Such problems of smart-contracts that remain in WONTFIX state are typically widely known which makes it possible to describe them in advance at the insurance agreement.

The Insurance Organization must resign from its responsibility for compensating any losses caused by the WONTFIX issues.