简单回顾
区块链安全圈好久没有这么热闹了。。昨晚 Curve 被黑可谓是精彩。细节上倒是没有什么值得太深入分析的部分，无非是一次简单的重入攻击罢了，有兴趣的小伙伴可以自行研究，相关交易放在这里：
https://explorer.phalcon.xyz/tx/eth/0xb5d91f1e0afc96a52f8c6c28eae405eda7fcc5d34d6d03bdd8b16bd58089e939?line=10
简单做一下总体时间线的回顾吧
-
Peckshield 预警了 JPEG 项目方的被黑，同时分析出是一次重入攻击
-
大部分人都理所当然的认为就是一次 Curve 的只读重入，毕竟发生次数太多，理所当然了
-
Blocksec 团队介入分析，开始鸡贼地说对应 Vyper 版本有点问题，提示风险
-
事情开始不对劲，大面积开始被黑
接下来的事情大家都知道了，alcx 被黑，bsc 上的仿盘被黑，各种被黑。我大概是在 Blocksec 开始鸡贼的时候介入的，一开始我也以为是简单的只读重入，sb 项目方自己不会写 LP price 获取。但是Blocksec的推让我瞬间敏感了起来，然后就开始我这边的正常应急流程了：
-
确保老板先跑。确定影响范围
-
通过分析原始交易，不难看出这是一笔针对
Curve Factory Pool的攻击，结合Blocksec的预警，合理推断所有Factory创建的Pool都有问题 -
成因分析。攻击的主要形式为重入，思考重入条件，由于
Curve为AMM，存在外部交互的地方就只能是代币的发送，而普通ERC20是不存在回调接口的，所以无法形成重入条件。但是原生的ETH可以，ETH转账自带回调，所以这里是一个很好的重入接口 -
综合上面的点，不难得出此次的影响范围为
Curve Factory Pool中所有带Native ETH的池 -
理论上我们是还需要逐步试试不同
Vyper版本的编译器的，但是我们可以巧妙得通过问起他人来减轻自己的工作量，同时结合Vyper自己的声明，确定了本次受影响的版本为：0.2.15 0.2.16 0.3.0 -
同步分析结果
安全审计的意义
Curve 这次的事情引发了很多思考，Curve 一开始还发推嘲讽说为什么开发人员不遵循 ChainSecurity 针对 Curve 只读重入的建议来预防此类攻击，没想到短短半小时后就被狠狠打脸，这次竟然是 Curve 本身被黑了。那个在天上的 Curve 被黑了 !!!!
Curve 经历和很长的时间考验，经历过多轮的审计，我这里不是说 Curve 不重视安全，显然 Curve 在 DeFi 里无疑是最重视安全的那个，但是在经历了长时间的考验后，还是被黑了。
这次之后，我又想起了那句话，所有的 DeFi 协议，不是在被黑，就是在被黑的路上，总有被黑的一天。安全无非是在被黑之前的一种暂时性状态而已，只有被黑才是所有协议的终局。
那是否安全审计就没有意义呢？我想是有的吧，这就就像一种体检吧，尽可能的把显眼的问题都解决掉，但是一旦你癌症晚期，除非华佗在世，不然还是没办法。。
同时回顾目前总体的安全生态建设，显然我们太注重安全三部曲里面的事前准备，即大量的安全审计，而较为忽略第二步和第三部，分别是中期维护 和 事后补救。中期维护上大家都愿意上各种公开的赏金平台，有自己的 bug bounty，相当于定期体检，是一件好事，但是往往忽略了最重要的事后补救。纵观整个安全市场，目前做这块的主要还是各种为爱发电的 MEV Bot，还有安全公司们的抢跑。并没有形成体系化的流程。
今年发生了很多大事，很多团队已经意识到并在努力建设事后补救这一步了，希望下一次，大家可以足够幸运。
原文始发于微信公众号（蛋蛋的区块链笔记）：安全审计的意义
