DeFi 常见安全漏洞及预防措施

近期,一位安全专家为社区成员分享了一堂 DeFi 安全课。他回顾了过去一年多 Web3 行业遭遇的重大安全事件,探讨了这些事件发生的原因以及如何规避,总结了常见智能合约的安全漏洞及预防措施,还对项目方和普通用户给出了一些安全建议。

常见的 DeFi 漏洞类型包括闪电贷、价格操纵、函数权限问题、任意外部调用、fallback 函数问题、业务逻辑漏洞、私钥泄漏、重入等。下面重点介绍闪电贷、价格操控以及重入攻击这三种类型。

闪电贷

闪电贷本身是 DeFi 的一种创新,但被黑客利用时,他们无需成本就可以借到大量资金,在执行完套利后归还,只需支付少量 Gas 费用就可获得巨额收益。

过去两年,闪电贷问题频发。一些项目看似收益很高,但实际上项目方水平参差不齐。即便代码本身没有漏洞,在逻辑上仍可能存在问题。例如,有项目会在固定时间根据持仓者持有的代币数量发放奖励,却被攻击者利用闪电贷购买大量代币,在奖励发放时获取大部分奖励。还有一些通过代币来计算价格的项目,可以通过闪电贷影响价格。项目方应该对这些问题提高警惕。

价格操控

价格操控问题与闪电贷关系密切,主要有两种类型:

1. 计算价格时使用第三方数据,但使用方式不正确或检查缺失导致价格被恶意操控。

2. 使用某些地址的代币数量作为计算变量,而这些地址的代币余额可以被临时增加或减少。

重入攻击

调用外部合约的主要危险之一是它们可以接管控制流,并对数据进行调用函数未预料到的更改。

针对不同的合约,重入存在的方式很多,可以结合合约的不同函数或多个不同合约的函数完成重入攻击,所以解决重入问题时需要注意:

1. 不只是防止单一函数的重入问题

2. 遵循 Checks-Effects-Interactions 模式进行编码

3. 使用经过时间验证的防重入 modifier

最怕的就是重复造轮子,需要什么都自己写。在这个圈内有很多最佳安全实践,我们拿来用就好,完全没有必要重复造轮子。当你造一个轮子时,是没有通过充分验证的,这个时候出问题的概率,很明显比用一个非常成熟的久经考验的出问题的概率要大得多。

安全建议

项目方安全 Tips

1. 合约开发遵循最佳安全实践。

2. 合约可升级、暂停:很多攻击不是一次性把币全转走,而是分多笔交易执行,如果有相对健全的监控机制,是可以发现的,发现后如果合约可以暂停,就可以有效降低损失。

3. 采用时间锁:如果有时间锁,假设是 48 小时内才能完成,这个时候在时间锁期间很多人能发现创建者重新更新了一个所有人都可以使用的 mint 方法,监控的人就知道项目可能被黑了,可以通知项目方去改变,即使通知了也没人管,至少可以先把自己的那部分钱给拿出来,先保证自己的收益不受损。所以说一个项目如果没有时间锁,理论上来讲是增加了出问题的概率。

4. 加大安全投入,建立完善的安全体系:安全不是一个点,也不是一条线,安全是成体系的。不要觉得作为项目方,合约通过多家公司审计就没问题了,要考虑各种可能导致资金损失的风险。要尽量做风险建模,然后逐步将大部分风险规避掉,剩余风险也是可接受风险,在可承受范围内。安全和效率是不可能兼得的,要做一定的取舍。但如果完全不管安全,在安全上没有投入,被攻击是很正常的。

5. 提高所有员工的安全意识:提高安全意识并不需要很多技术。在这个大环境内,只要稍微多问一些为什么,稍微多想一点就能规避掉很多问题。

6. 预防内部作恶,在提升效率的同时增强风控:比如合约的 Owner 是单签还是多签、是否使用时间锁等,都需要考虑。

7. 三方引入安全性:作为生态中的一环,项目方都会有自己的上下游。安全上有一个"默认上下游都是不安全"的原则。无论对于上游还是下游,都要做校验。对于三方我们是很难控制,安全的风险敞口实际上特别大,所以要很注意三方的引入。合约是开源的,可以去引入、调用它;如果合约不开源,就绝对不能引用。

用户/LP 如何判断智能合约是否安全?

对于普通用户,判断项目是否安全主要看以下六点:

1. 合约是否开源:凡是合约不开源的项目,坚决不碰,因为我们无从得知合约写的是什么。

2. Owner 是否采用多签,多签是否去中心化:如果不用多签,我们无法判断项目的业务逻辑和内容,一旦出现安全事件,无法判断是否为黑客所为。即便采用多签,也需要判断一下多签是不是去中心化的。

3. 合约已有的交易情况:尤其市面上有很多搞钓鱼诈骗的项目,可能会做一个比较相似的合约,这个时候我们就要看一下合约的部署时间、交互次数等,这些都是判断合约是否是安全的衡量标准。

4. 合约是否为代理合约,是否可升级,是否有时间锁:如果合约完全不能升级,就太死板了,还是推荐项目的合约是可以升级的。但是升级要讲究方法,当升级有升级内容、重要参数更改的时候,要有一个时间锁定,要有给大家一个时间窗口去判断真实升级是对用户有害的还是有利的,这也是公开透明的一种方式。

5. 合约是否接受过多家机构审计(不要盲目信任审计公司), Owner 权限是否过大:首先不要只相信一家审计公司,因为不同的审计公司,不同的审计人员,看问题的角度是不一样的。其次要看 Owner 的权限是否过大。一个正常的项目 Owner 的权限一定是可控的,这样就不会有太多高危操作,操作也会用时间锁的方式,让用户知道操作的是什么。

6. 注意预言机:如果项目使用市面上的龙头预言机,基本上不会有太大问题,但如果使用自建的预言机,或者用一些随便抵押一些代币就可以往里去喂价的预言机,那就要注意了。当发现预言机可能会存在一些问题,或者说存在被操纵可能的时候,即便项目收益再高也不能参与。