Back to Blog

BlockSec:2023年DeFi协议安全性回顾

January 21, 2024
10 min read

尽管 2023 年大部分时间里 DeFi 协议处于熊市,但由于协议漏洞,该生态系统仍持续遭受严重的黑客攻击。值得注意的是,在 Euler Finance 黑客攻击事件中,损失高达近 2 亿美元。与此同时,DeFi 安全事件中出现了新的趋势,例如由编译器引起的漏洞以及广泛使用的标准之间的不兼容性。为了应对这些威胁,社区提出了多种解决方案,包括监控和威胁情报。虽然其中一些措施已被证明有效,但我们认为这些努力是临时性的。社区仍然缺乏保护 DeFi 协议的系统性方法和指导。

在这篇博客中,我们将首先利用典型案例来展示 DeFi 协议安全的新趋势,然后说明当前的解决方案及其局限性。最后,我们将提出 BlockSec 对于如何保障 DeFi 协议安全的观点。

0x0. DeFi 协议安全的新趋势

趋势一:知名协议遭到攻击

2023 年,一些老牌且声誉卓著的协议遭到攻击,包括 CurveBalancerKyberSwap。下表列出了这些知名协议的启动日期及其被攻击的时间。需要注意的是,所利用的漏洞可能是在协议初始发布后的更新中引入的。因此,表中提供的时间跨度仅为近似值,旨在提供一个大致的时间概念。

协议 启动时间 安全事件时间 持续时间
kyberSwap 2017 2023 年 11 月 ~ 6 年
Curve 2020 2023 年 7 月 ~ 3 年
Balancer 2020 2023 年 8 月 ~ 3 年

除了上述协议外,Aave V2 在 11 月收到社区的漏洞报告后被紧急暂停。虽然该协议未受到攻击,但这仍然引起了人们对知名协议安全性的担忧。

这些协议都经过了多次审计,并在内部实施了多种安全措施。下表列出了各协议的审计方。需要注意的是,一家审计公司可能仅对协议中的部分智能合约进行了审计。表中提到的审计方并不一定对应审计了存在漏洞的具体智能合约。此表旨在表明这些协议在安全方面投入了相当多的资源。

协议 审计方 链接
kyberSwap ChainSecurity, Sherlock, Hacken 审计 - KyberSwap 文档
Curve TrailOfBits, MixBytes, Quantstamp, ChainSecurity 审计 - Curve 文档
Balancer OpenZeppelin, TrailOfBits, Certora, ABDK [安全

幸运的是,受害者已经通过各协议实施的补偿计划挽回了部分损失。例如,Kyber Network 宣布计划通过 KyberSwap 国库补偿受影响的用户。同样,Curve 社区投票通过了一项向流动性提供者 (LPs) 补偿其经济损失的提议。尽管代价高昂,但这些措施是恢复 DeFi 社区信心的重要步骤。

趋势二:新型攻击向量的出现

涉及编译器漏洞和不兼容第三方库的攻击向量确实已在 DeFi 领域出现。例如,Curve 安全事件的根本原因被确定为特定版本的 Vyper 编译器中存在的错误。此外,一些协议遭受的攻击源于两种被广泛应用的标准(ERC2771 和 Multicall)之间的不兼容性,当这些标准在 thirdweb 等主流第三方开发库中实现时尤为突出。这些复杂的技术挑战凸显了深入安全实践以及不断演进安全措施以抵御未知漏洞的重要性。

编译器错误

1983 年,肯·汤普森(Ken Thompson)在图灵奖演讲中发表了题为“对通过信任进行反思”的演讲。在演讲中,他描述了如何通过修改 C 编译器在程序中植入后门,从而导致意想不到的结果。演讲中传达的理念受到了社区的高度评价。然而,在实践中恶意编译器的真实案例却很少见(除了著名的 XcodeGhost 安全事件)。即使将安全模型从恶意编译器放宽到良性但意想不到的编译器行为,公开报道的造成严重经济损失的案例仍然稀少。

由 Vyper 编译器漏洞引起的 Curve 安全事件是一个广为人知的案例,导致了约 7000 万美元的损失(其中部分资金已归还,实际损失约为 2300 万美元)。Vyper 编译器 0.2.15、0.2.16 和 0.3.0 版本存在漏洞,会导致重入锁(reentrancy guard)失效。这意味着攻击者可以利用重入进行攻击。如果编译器生成了正确的字节码,这种情况本不应发生,因为开发者已经添加了防止重入的代码。

攻击交易: 0x2e7dc8b2fb7e25fd00ed9565dcc0ad4546363171d5e00f196d48103983ae477c

常见标准的不兼容性

DeFi 的可组合性允许不同的智能合约和标准相互连接,从而创建强大的应用程序。然而,这也带来了潜在的兼容性问题。例如,组合使用流行的标准可能会在每个智能合约各自运行正常的情况下引入新的安全漏洞。

这种不兼容性问题的一个例子涉及 ERC-2771 和 Multicall 标准。ERC-2771 定义了一个通过受信任转发器接收元交易的接口,而 Multicall 是一种在单笔交易中批量处理多个函数调用的机制。当从受信任转发器转发的调用从调用数据(calldata)中检索实际调用地址时,问题便会出现,因为该地址可以被攻击者操纵。虽然每个标准在单独使用时都能完美运行,但它们的组合使用可能会破坏某些假设,导致不可预见的问题。有关更多详细信息,请参阅 OpenZeppelin 的博客文章

请注意,ERC-2771 和 Multicall 标准都在 OpenZeppelin 和 thirdweb 等流行开发库中实现。开发者通常信任这些知名的代码库,因此可能会将其排除在代码审计范围之外。这种做法可能会带来新的安全漏洞,即使协议本身并非固有漏洞。

趋势三:旧漏洞产生了新的安全影响

精度损失是指计算过程中精度和准确度的降低,通常是由结果的小数位数少于预期引起的。虽然静态分析器可以轻松检测到精度损失问题,但其存在并不一定意味着存在安全漏洞。只有当精度损失可能导致严重后果时,才会被视为漏洞。然而,评估精度损失的影响往往具有挑战性,因为它需要深入理解协议的语义和代码的具体上下文。

一些攻击针对的是 Compound v2 和 Aave v2 等领先协议的复刻版本,这些版本可能对已知的精度问题敏感。具体来说,涉及 Hundred FinanceChannels Finance 的事件(它们均源自 Compound v2)就是由于市场初始化不当以及精度损失问题引起的。这些问题允许攻击者由于向下取整错误而在抵押品变少的情况下赎回代币。

攻击交易: 0x3f7de75566289224c5e95a35ee8717ddd6928500227a05c1d83838844c60491d

0x1. 当前的解决方案

知名 DeFi 协议确实在安全措施上投入了大量资金,并经过了多轮安全审计。尽管如此,考虑到这些协议所管理的大量用户资产,强调协议安全的重要性是完全合理的。除了代码审计,还提出了威胁监控等其他解决方案。让我们深入了解这些解决方案的现状及其局限性。

代码审计

此处定义的代码审计确实是 DeFi 协议安全评估中的一个关键过程,通常在协议上线前完成。它结合了多种技术,包括人工代码审计、静态分析、动态模糊测试和形式化验证。此外,该过程可以由一家(或少数)审计公司进行,或者通过社区驱动的方式进行。然而,代码审计必须承认其存在的局限性。

  • 首先,代码审计主要发生在协议部署之前。一旦协议上线,审计过程通常就结束了,初始代码审计无法持续评估 ongoing 的安全性。这意味着上线后出现的任何漏洞或问题可能无法通过初始代码审计检测到。

  • 其次,代码审计通常难以发现需要复杂交互和特定状态才能被利用的细微漏洞。DeFi 协议的可组合性虽然促进了灵活性和集成,但也极大地扩展了程序空间,给人工评审和静态分析器带来了严峻挑战,因为它们难以探索所有的程序状态。尽管动态模糊测试有益,但它受限于交易和状态依赖。缺乏能够检测失败的 DeFi 协议感知型模糊测试预言机,是该领域的一个重大缺口,也是行业和学术界共同面临的一个开放性研究课题。

  • 第三,合格的代码审计人员短缺,受限于人才库,这一问题无法迅速解决。代码审计是一项跨学科任务,需要网络安全、金融和数学方面的知识。目前只有少数大学提供这一专业领域的教育,导致高质量代码审计成本高昂,服务等待时间长。因此,协议可能会为了维持业务进度而在没有经过代码审计的情况下直接上线。

  • 第四,对于用户而言,评估代码审计的质量具有挑战性。虽然用户由于将资产置于协议中,其对协议安全性的关注度最高,但大多数用户缺乏评估代码审计彻底性的能力。这可能导致审计仅流于形式,最终损害协议和用户资产的安全性。

总之,虽然代码审计是保障协议安全的一项有价值的工具,但其固有的局限性意味着它不能成为唯一的安全解决方案。

威胁监控

威胁监控的基本理念是监控并检测可疑行为。这确实提高了安全性,但若要有效,需要解决以下顾虑。

  • 首先,威胁监控系统的准确性至关重要。它们必须通过最小化误报(false positives)和漏报(false negatives)来取得平衡。高误报率会导致虚假警报,使用户或安全团队对警告产生脱敏,从而可能忽略真正的威胁。

  • 其次,当前的威胁监控系统在检测到可疑交易时,往往需要人工确认才能采取行动。这在很大程度上是由于上述高误报率问题所致。人工干预的被动属性是有问题的,因为在区块链和 DeFi 协议的快节奏环境中,攻击可以在短时间内抽干资金,通常在人工干预能够实施之前就已经造成了损失。因此,如果威胁监控系统无法提供及时的自动响应来预防或缓解攻击,其价值将大大降低。

  • 此外,威胁监控应该是持续的,并能够适应新出现的威胁。

0x2. BlockSec 的观点

我们认为协议安全需要在协议生命周期的不同阶段采用多种防御手段,包括高质量的代码审计、上线前的安全测试、上线后的攻击检测与防御,以及安全事件响应。我们还想强调社区所忽略的一些观点。

  • 首先,我们认为任何微小的代码或配置升级都需要进行彻底的安全测试。这种测试应该在协议的实际状态上进行,而不是在伪造的用户数据状态上进行。如前所述,协议状态对于定位复杂协议中的漏洞至关重要。

  • 其次,除了人工干预,还需要一套对攻击的自动化响应系统。这需要一个准确且及时的攻击检测系统,其误报率应极低,且漏报率应接近于零。例如,如果部署了自动化响应系统,数百万用户的资产可以得到挽救。

  • 第三,应建立适当的安全事件响应程序,并需要能够提供全面安全服务的安全合作伙伴。例如,当发生漏洞利用时,合作伙伴可以协助建立应急作战室、推荐采取的行动、协助审查和审计安全补丁、跟踪资金流向等。yearn finance 的文章是关于如何处理漏洞利用的优秀资源

BlockSec 提供的全栈安全服务

基于上述洞察,BlockSec 为协议提供全栈安全服务。

  • Phalcon: 攻击检测与防御系统。凭借经过实战检验、已成功阻断 20 多起攻击并挽回约 1400 万美元损失的技术,BlockSec Phalcon 可以帮助协议主动监控攻击合约和交易(甚至在黑客发起攻击交易之前)。配合近 99.99% 精确的攻击检测引擎以及用户自定义策略,BlockSec Phalcon 平衡了误报与漏报,实现了自动防御机制
  • 安全事件响应。在 DeFi 黑客事件中,BlockSec 始终是识别攻击根源和漏洞最快(如果不是第一个)的安全厂商。我们能够帮助协议审查安全补丁(例如 Telcoin)、提供白帽资金救援 [如 AnySwap, TransitSwap, Paraspace, Loot]、跟踪被盗资金流向,并定位 Hopeland 攻击者 的身份。

0x3. 结论

在 2023 年,我们发现 DeFi 协议安全领域出现了新趋势,许多知名协议遭到了攻击。我们深知,在技术层面保障协议安全是一项复杂且持续的挑战。仅采用代码审计或监控系统已不再足够。我们需要一套结合了这些元素,并贯穿于协议整个生命周期的全栈解决方案。

综上所述,BlockSec 对 DeFi 协议安全的整体方法——结合先进的审计技术、自动攻击防御工具和响应式事件管理——使其成为广大协议的领先合作伙伴。这些协议正致力于在 2024 年 DeFi 领域不断演变的威胁面前,强化安全措施并保护用户资产。