解读技术大佬对Cetus Protocol黑客攻击事件的分析

来源：推特@tmel0211

通俗版本：简单“翻译”解读下技术大佬关于 @CetusProtocol

 黑客攻击事件的分析：

这次攻击暴露的是一个经典的整数溢出问题，具体表现为类型转换过程中的数据截断。

技术细节拆解：

1）漏洞定位：问题出现在get_amount_by_liquidity函数的类型转换机制中，从u256到u64的强制转换导致高位数据丢失。

2）攻击流程：

1、攻击者通过add_liquidity函数传入极大的流动性数量参数；

2、系统调用get_delta_b函数计算所需的B代币数量；

3、在计算过程中，两个u128类型数据相乘，理论结果应为u256类型；

关键缺陷：函数返回时将u256结果强制转换为u64，导致高位128位数据被截断。

3）利用效果：原本需要大量代币才能铸造的流动性额度，现在仅需极少量代币即可完成。攻击者以极低成本获得巨额流动性份额，随后通过销毁部分流动性实现资金池套利。

简单类比：就像用只能显示8位数的计算器计算10亿×10亿，20位的计算结果只能显示后8位，前12位直接消失。攻击者正是利用了这种"计算精度缺失"漏洞。

需要明确一点：这次漏洞与 @SuiNetwork  的底层安全架构无关，属于Move语言的安全性“荣光”暂时还可信。Why？

Move语言在资源管理和类型安全方面确实具备显著优势，能够有效防范双重支付、资源泄露等底层安全问题。但此次Cetus协议出现的是应用逻辑层面的数学计算错误，并非Move语言本身的设计缺陷。

具体而言，Move的类型系统虽然严格，但对于显式类型转换（explicit casting）操作，仍需依赖开发者的正确判断。当程序主动执行u256到u64的类型转换时，编译器无法判断这是有意设计还是逻辑错误。

此外，这次安全事件与Sui的共识机制、交易处理、状态管理等核心底层功能完全无关。Sui Network只是忠实执行了Cetus协议提交的交易指令，漏洞源于应用层协议本身的逻辑缺陷。

说白了，再先进的编程语言也无法完全杜绝应用层的逻辑错误。Move能够防范大部分底层安全风险，但无法代替开发者进行业务逻辑的边界检查和数学运算的溢出保护。

更正：

跟大佬进一步沟通了下，此前对 @CetusProtocol  黑客攻击的技术分析在具体细节上存在偏差，特此更正。

此前准确识别了这是一个数学计算溢出类漏洞，攻击者通过构造特殊数值"以小博大"的核心逻辑是对的，对大家关心的Move语言的安全性疑惑解答也是对的。

只不过看到了数学计算错误的现象，推测是类型转换问题，但实际是其他函数的边界检查问题。事实上，Move语言对u256到u64等类型转换有严格的审查机制，这类显式转换在正常情况下确实会有安全检查。

具体的漏洞位置和技术实现机制需要修正，如下。

真正的问题出现在`get_delta_a`函数的溢出检查机制失效：

1）函数作用：计算添加指定流动性时需要的token A数量；

2）关键缺陷：`checked_shlw`函数的溢出检查存在编码错误，未能阻止无效的大流动性值；

3）攻击利用：黑客构造特殊流动性值，绕过失效检查，最终通过`div_round`的向上取整机制，让所需token A数量变成14）。

攻击效果：用1个token A铸造巨额流动性，然后抽干资金池。