BlockSec’s Retrospective on DeFi Protocol Security in 2023

New trends in DeFi protocol security in 2023 and BlockSec's perspective on how to secure DeFi protocols

BlockSec’s Retrospective on DeFi Protocol Security in 2023

Although much of 2023 was a bear market for DeFi protocols, the ecosystem continues to suffer serious hacks due to protocol vulnerabilities. Notably, there was a significant loss of nearly $200 million in the Euler Finance hack. Meanwhile, new trends in DeFi security incidents have emerged, such as vulnerabilities caused by compilers and incompatibilities between widely used standards. To counter these threats, the community has proposed multiple solutions, including monitoring and threat intelligence. While some of these measures have proven effective, we believe that these efforts are ad-hoc. The community still lacks a systematic approach and guidance to help protect DeFi protocols.

In this blog, we will first use representative cases to present new trends in DeFi protocol security, then illustrate the current solutions and their limitations. Finally, we will propose BlockSec's perspective on how to secure DeFi protocols.

0x0. New Trends in DeFi Protocol Security

Trend-I: Reputable protocols have been attacked

In 2023, some well-established and reputable protocols have been compromised, including Curve, Balancer, and KyberSwap. The table below illustrates the launch dates of these reputable protocols and when they were attacked. It's important to note that the vulnerabilities exploited may have been introduced in updates that occurred after the initial launch of the protocols. Therefore, the durations provided in the table are approximate and intended to offer a general idea of the timespan involved.

Protocol Launch Time Security Incident Time Duration
kyberSwap 2017 Nov, 2023 ~ 6 years
Curve 2020 July, 2023 ~ 3 years
Balancer 2020 August, 2023 ~ 3 years

Besides the above ones, Aave V2 was emergently paused after receiving a vulnerability report from the community in November. Although the protocol was not attacked, it still raised security concerns about reputable protocols.

These protocols have undergone several audits, with multiple security measures implemented internally. The tables below list the auditors for each protocol. It should be noted that an auditor may have only conducted audits on some of the smart contracts within the protocols. The auditors mentioned in the table do not necessarily correspond to those who audited the specific smart contracts that were vulnerable. The purpose of this table is to show that the protocols have invested considerable resources into security.

Protocol Auditors Link
kyberSwap ChainSecurity, Sherlock, Hacken Audits - KyberSwap Docs
Curve TrailOfBits, MixBytes, Quantstamp, ChainSecurity Audits - Curve Docs
Balancer OpenZeppelin, TrailOfBits, Certora, ABDK Security | Balancer

Fortunately, victims have been compensated for their losses through plans implemented by the respective protocols. For instance, Kyber Network announced that it intends to compensate affected users via the KyberSwap Treasury. Similarly, the Curve community voted in favor of a proposal to reimburse LPs for their financial losses. These measures are steps towards restoring the DeFi community's confidence, albeit at a considerable expense.

Trend-II: New Types of Attack Vectors have Emerged

Attack vectors involving compiler bugs and incompatible third-party libraries have indeed emerged in the DeFi space. For example, the underlying cause of the Curve security incident was identified as bugs within certain versions of the Vyper compilers. Additionally, some protocols have suffered attacks that stemmed from the incompatibility between two widely adopted standards: ERC2771 and Multicall, when these were implemented in popular third-party development libraries, such as thirdweb. These complex technical challenges underscore the importance of thorough security practices and the continuous evolution of security measures to protect against new and unforeseen vulnerabilities.

Compiler Bugs

In 1983, Ken Thompson delivered a speech in this Turing Award lecture titled “Reflections on Trusting Trust.” In this speech, he described the steps to modify a C compiler to insert a backdoor into a program, which can lead to unexpected results. The idea conveyed in the speech was well-received by the community. However, real cases of malicious compilers in practice are rare (except for the well-known XcodeGhost security incidents.) Even if we relax the security model from malicious compilers to benign but unexpected compiler behavior, public cases that cause serious financial losses are still rare.

The Curve security incident caused by the Vyper compiler bug is one publicly known case that caused approximately 70 million in losses (some of them have been returned, and the actual losses are around 23 million). The Vyper compiler versions 0.2.15, 0.2.16, and 0.3.0 versions have bugs that will make the reentrancy guard ineffective. This means that the attacker can leverage the reentrancy to perform the hack, which should not happen if the compiler generates the correct bytecode – since the developer has added the code to prevent the reentrancy from happening.

Attack Tx: 0x2e7dc8b2fb7e25fd00ed9565dcc0ad4546363171d5e00f196d48103983ae477c

Incompatibility of Common Standards

DeFi composability allows different smart contracts and standards to connect and create powerful applications. However, this raises potential compatibility issues. For example, combining popular standards can introduce new security vulnerabilities when each smart contract functions smoothly on its own.

One example of such an incompatibility issue involves ERC-2771 and Multicall standards. ERC-2771 defines an interface for receiving meta transactions via a trusted forwarder, while Multicall is a mechanism for batching multiple function calls within a single transaction. The problem arises when a call forwarded from a trusted forwarder retrieves the actual call address from the calldata, which can be manipulated by an attacker. Although each standard works flawlessly in isolation, their combined use can disrupt certain assumptions and lead to unforeseen issues. For further details, refer to the blog post from OpenZeppelin.

Note that both the ERC-2771 and Multicall standards are implemented in popular development libraries such as OpenZeppelin and thirdweb. Developers often place their trust in these well-known codebases and might exclude them from code auditing. This practice can introduce new security loopholes, even if the protocols themselves are not inherently vulnerable.

Trend-III: Old Vulnerabilities have New Security Impacts

Precision loss refers to the reduction in precision and accuracy during calculations, typically caused by a result having fewer decimal places than expected. While static analyzers can easily detect precision loss issues, their mere existence does not necessarily indicate a security vulnerability. It is only considered a vulnerability if the precision loss could lead to serious consequences. However, evaluating the impact of precision loss is often challenging, as it requires a deep understanding of the protocol's semantics and the specific context of the code.

Several attacks have targeted protocols that are forks of other leading protocols, such as Compound v2 and Aave v2, which may be susceptible to known precision issues. Specifically, the incidents involving Hundred Finance and Channels Finance—which are forks from Compound v2—arose from improperly initialized markets, as well as problems concerning precision loss. These issues allowed attackers to redeem collateral with a reduced number of tokens due to rounding down errors.

Attack Tx: 0x3f7de75566289224c5e95a35ee8717ddd6928500227a05c1d83838844c60491d

0x1. Current Solutions

It's true that reputable DeFi protocols have invested substantially in security measures and have undergone multiple rounds of security audits. Nonetheless, considering the vast amounts of user assets these protocols manage, it is entirely justified to underscore the critical nature of protocol security. Beyond code auditing, there are additional proposed solutions like threat monitoring. Let's delve into the current state of these solutions and their limitations.

Code Auditing

Code auditing, as defined here, is indeed a critical process in the security evaluation of DeFi protocols, typically performed before a protocol goes live. It incorporates a range of techniques, including manual code review, static analysis, dynamic fuzz testing, and formal verification. Also, this process can be conducted in one (or a few) audit companies or through a community-driven method. However, there are limitations to code auditing that must be acknowledged.

  • Firstly, code auditing primarily occurs before the protocol is deployed. Once the protocol is live, the auditing process typically concludes, and the ongoing security cannot be continuously assessed by the initial code audit. This means that any vulnerabilities or issues that arise post-launch may not be detected by the initial code audit.

  • Secondly, code auditing often struggles to identify subtle vulnerabilities that require complex interactions and specific states to be exploited. The composability of DeFi protocols, while a feature that promotes flexibility and integration, significantly expands the program space and presents severe challenges for human reviewers and static analyzers, which have difficulty exploring the full range of program states. Even though dynamic fuzz testing can be beneficial, it's limited by transaction and state dependencies. The absence of DeFi protocol-aware fuzzing oracles, which can detect failures, is a significant gap in the field that remains an open research question in both industry and academia.

  • Thirdly, there is a shortage of qualified code auditors, which cannot be quickly resolved due to the limited pool of talent. Code auditing is an interdisciplinary task that requires knowledge of cybersecurity, finance, and mathematics. Only a select number of universities currently offer education in this specialized field, leading to high costs for quality code audits and long wait times for services. As a result, protocols may go live without a code audit to maintain their business timelines.

  • Fourthly, assessing the quality of a code audit is challenging for users. While users are the most invested in the security of the protocol as they place their assets within it, most lack the ability to evaluate the thoroughness of a code audit. This can lead to audits that are conducted merely for appearances, which can ultimately compromise the security of both the protocol and the user assets

In conclusion, while code auditing is a valuable tool in securing protocols, its inherent limitations mean it cannot be the sole security solution.

Threat Monitoring

The basic idea of threat monitoring is to monitor and detect suspicious ones. This does improve security but needs to address the following concerns to be effective.

  • Firstly, the accuracy of threat monitoring systems is crucial. They must strike a balance by minimizing both false positives and false negatives. A high rate of false positives can lead to false alerts, where users or security teams become desensitized to warnings, potentially overlooking true threats.

  • Secondly, the current state of threat monitoring systems often requires manual confirmation to act upon the detection of suspicious transactions. This is largely due to the aforementioned issue of high false positive rates. The reactive nature of manual interventions is problematic because, in the fast-paced environment of blockchain and DeFi protocols, attacks can drain resources quickly, often before manual responses can be implemented. Therefore, the value of a threat monitoring system is significantly reduced if it cannot provide timely automatic actions to prevent or mitigate attacks.

  • Moreover, threat monitoring should be persistent and capable of adapting to new threats as they emerge.

0x2. BlockSec's Perspective

We think protocol security needs multiple defenses in different stages in the life cycle of a protocol, including high-quality code auditing, security testing before the launch, attack detection and blocking, and security incident response after the launch. We also want to highlight some perspectives that have been neglected in the community.

  • First, we think thorough security testing is needed for any small code or configuration upgrade. Such a test should be performed on the actual states of the protocol instead of the bogus states of user data. As discussed previously, protocol states are crucial to locating vulnerabilities in complicated protocols.

  • Second, an automatic response system to attacks, other than manual intervention, is needed. This requires an accurate and prompt attack detection system, with pretty low false positives and nearly zero false negatives. For instance, millions of users' assets can be saved if an automatic response is deployed.

  • Third, a proper security incident response procedure should be established, and security partners that can provide comprehensive security services are needed. For instance, when an exploit happens, the partner can assist in the process of creating a war room, recommend actions to take, help review and audit security patches, track fund flows, etc. The yearn finance article is a good resource on how to handle exploits.

Full-stack Security Service Provided by BlockSec

Based on the given insights, BlockSec provides full-stack security services to protocols.

  • High-quality code auditing services. BlockSec provides diligent code auditing services to DeFi protocols. By leveraging the static analysis tool, dynamic fuzzing, and differential testing framework backed by creative academic research, our code audits cover both protocols and the underlying EVM execution engine. Besides, the static analysis tool HookScan was supported by Uniswap Lab to detect the vulnerabilities in Uniswap V4 hooks.

  • Phalcon Fork: Collaborative Security Testing Framework. The Phalcon Fork is a framework that can mirror mainnet states and provide a security testing environment for protocols when updating code and configurations. The internal Phalcon Explorer can help debug the transactions. All the transactions sent in the Fork can be shared with other developers and normal users, thus creating a public testing DApp that can involve users in the testing process.

  • Phalcon Block: Attack Detection and Blocking System. With the battle-tested techniques to block more than 20 attacks and rescue around 14 million USD, Phalcon Block can help the protocol actively monitor attack contracts and transactions (even before the hack launches the attack transactions). With nearly 99.99% precise attack detection engine plus user-customized policies, Phalcon Block balances the false positives and negatives, enabling the automatic defense mechanism.

  • Security Incident Response. BlockSec is always the fastest (if not the first) security vendor that can identify attack root causes and vulnerabilities in DeFi hacks. We can help protocols review the security patches (Telcoin), provide the white fund rescue [e.g., AnySwap, TransitSwap, Paraspace, Loot], track hack fund flow, and pinpoint the identity of the Hopeland attacker.

0x3. Conclusion

In 2023, we found there are new trends in DeFi protocol security, and many reputable protocols have been attacked. We know that ensuring protocol security in technique is a complex, ongoing challenge. Simply adopting code auditing or monitoring systems isn't enough anymore. We need a full-stack solution that combines these elements and works along the whole life cycle of a protocol.

In conclusion, BlockSec's holistic approach to DeFi protocol security, combining cutting-edge auditing techniques, automatic attack defense tools, and responsive incident management, positions it as a leading partner for protocols seeking to fortify their security measures and protect user assets in the face of the evolving threats in the DeFi space in 2024.

Sign up for the latest updates