Audit of smart contracts and blockchain

One of our audit projects was the audit of smart contracts on the DX25 platform. This audit allowed us to identify several important vulnerabilities and provide recommendations for their elimination.

Audit methodology

Our approach to auditing DX25 smart contracts included a combination of manual and automated methods to comprehensively identify potential vulnerabilities. The main aspects of the audit included:

1. Behavior flow management assessment.
2. Access control verification.
3. Assessment of denial of service threats.
4. Verification of cryptographic issues.
5. Analysis of common code errors.

Identified vulnerabilities

The audit revealed several vulnerabilities of varying risk levels:

1. Lack of validation (F-1)

• Description: the init_wegld method does not contain a check for ensure_payable_api_resumed, which can lead to undesirable behavior.
• Risk: low
• Recommendation: add the ensure_payable_api_resumed check to the init_wegld method.

2. Unnecessary double checking (F-2)

• Description: The init_wegld method includes a check that restricts the ability to call this method only by the smart contract owner, but subsequent calls also include this check.
• Risk: low
• Recommendation: Consider removing the recheck or implementing an additional lower-level method.

3. Unnecessary argument passing (F-3)

• Description: when initializing a smart contract, arguments are passed, which are then checked and eliminated in the new_contract method.
• Risk: low
• Recommendation: use constant expressions instead of passing arguments.

4. No overflow checks (F-4)

• Description: The Cargo.toml file does not include the overflow-checks=true option, which can lead to overflows in release builds.
• Risk: informational
• Recommendation: add overflow-checks=true to the release profile in the Cargo.toml file.

More details can be found in the public audit report.

Three Cardano full nodes were assessed during the penetration test of a DEX trading solution. The assessment was done in the black-box and gray-box modes. As a result, we found that 4 security updates were not installed, and also we confirmed 3 kernel-level vulnerabilities. The Customer remediated these findings, and after that started to perform pool management operations in a secure manner.

The source code of a liquidity protocol for non-fungible tokens including the smart contracts was audited from the security point of view using mapping of vulnerabilities to the classification schemes CWE/SANS Top 25, DASP Top 10 and SWC Registry. Findings included costly loops, dead code, improper level of functions’ visibility in contracts and interfaces, weak points potentially influenced by miners. Vulnerabilities were classified as SWC-135, SWC-100, SWC-108 and DASP-8. The Customer got a detailed report with all the findings which were subsequently addressed successfully and fixed in the new release.

We have recently had the unique experience of analysing a decentralised exchange focused on the innovative Milkomeda L2 protocol. The protocol allows the capabilities of Ethereum virtual machines in blockchain networks where they are not supported. 

In auditing the smart contracts that power the exchange, we applied our time-tested methodology. The analysis consisted of both automated and manual checks. We performed tests to find vulnerabilities from SWC and DASP TOP10, also deployed contracts in the test network to implement all possible attack scenarios.

As a result, we helped our client become confident that their project would not be the next news item on our blog about the biggest hack of the exchange. Personalised recommendations were developed on how to address the vulnerabilities that we found, as well as the ways to save Gas costs.

We were tasked with auditing smart contracts written for the Algorand blockchain which is a competitor to Ethereum.

Coding for Algorand is a relatively new area without many security standards, documentation, or best practices. Nonetheless, smart contracts can end up controlling tens of millions of dollars, making them a target for attackers.

The Algorand smart contracts are written in Transaction Execution Approval Language (TEAL). The smart contracts provided to us were built using PyTeal, a Python library for generating TEAL programs.

Our task was to ensure that smart contract functions worked as intended, and to identify any potential security issues. For this purpose, we used custom verification code to check for a number of attack vectors, with various inputs representing possible scenarios based on real incidents. We also employed both a checklist of known smart-contract security issues and official guidelines from Algorand.

Finally, we deployed the smart contracts on our private network to reproduce the issues found and confirm our findings.

As a result, we were able to confirm that it is not possible to abuse the smart contracts or violate the customer's business requirements. Additionally, we provided the customer with useful recommendations for improvement based on our experience.