DAO还安全吗？Build Finance遭遇恶意治理接管，被洗劫一空！

据悉，Build Finance 是一个自我描述为“去中心化风险建设者”，其目标是通过奖励代币来激励新项目。这个想法是用其原生 BUILD 代币为项目提供资金，作为回报，这些项目将采用 BUILD 代币来增加对它们的需求。此外，该项目由 DAO 维护，也就是由一个去中心化组织参与治理。（扩展阅读：“DAO”到底是什么？）

但是，黑客却悄悄搞起事情，该项目遭遇攻击者恶意治理接管，黑客通过获得足够多的投票成功控制 Build 代币合约，在三笔交易中铸造了超过10亿的BUILD 代币，并耗尽了 Balancer 和 Uniswap 流动性池中的大部分资金。事发后，该项目团队在推特建议用户不要在任何平台上购买 BUILD 代币，项目团队成员试图与攻击者进行直接对话，但对方似乎没有兴趣对话。

看来项目方又遇到了一位“任性”的黑客。下面，跟着我们来看一下事件具体分析过程。

通过对项目的交易追踪，我们发现2022年2月12日Build Finance 项目被攻击者窃取了治理权限，接着向0xdcc8A38A地址分三次铸造了超过10亿的BUILD代币。

然后0xdcc8A38A地址将这10亿代币通过Uniswap V2: BUILD兑换将项目方的交易池掏空。

观察交易细节后，我们发现调用Build 代币合约mint函数铸币的地址也为0xdcc8A38A。

接着往下看，我们观察下图项目方的合约代码发现调用mint函数的地址只能为governance地址。此时铸币的地址为0xdcc8A38A，也就是说合约现在的governance权限已经被0xdcc8A38A地址获取了。

从代码中可以看到原本的governance权限属于合约的创建者即下图的0x2Cb037BD6B7Fbd78f04756C99B7996F430c58172地址。

我们不禁要问，那么governance权限是如何转移到0xdcc8A38A上的呢？

通过排查，我们通过2020年9月4日的一笔交易发现了线索，攻击者只有通过setGovernance函数才能窃取governance的权限。那么在这期间合约创建者0x2Cb037BD一定使用了setGovernance函数进行了权限转移。

通过查找0x2Cb037BD地址的交易记录可见，在同一天创建者使用了setGovernance函数。交易hash为0xe3525247cea81ae98098817bc6bf6f6a16842b68544f1430926a363e790d33f2。

通过查找内部的Storage可见权限转移给了0x38bce4b45f3d0d138927ab221560dac926999ba6地址而不是上述的0xdcc8A38A攻击地址。交易哈希为：
0xe3525247cea81ae98098817bc6bf6f6a16842b68544f1430926a363e790d33f2。

通过继续跟进0x38bce4b地址，发现是一个Timelock合约，而合约中可以调用build 代币合约函数的setGovernance函数只有executeTransaction函数。

我们跟进executeTransaction函数找到了其中的Storage。

从上图可见0x38bce4b45f3d0d138927ab221560dac926999ba6地址将权限又转移到了0x5a6ebeb6b61a80b2a2a5e0b4d893d731358d888583地址，交易哈希为0x9a0c9d5d3da1019edf234d79af072c1a6acc93d21daebae4ced97ce5e41b2573，调用时间为2021年1月25日。

通过继续跟进0x5a6ebeb6地址，在下图可知在2022年2月9日由suho.eth发起的提案，0xdcc8A38A攻击地址在2022年2月11日投票通过。在4天前将governance权限变更为0xdcc8A38A。

suho.eth发起的提案变更governance，投票设置的阈值较低导致提案通过，通过call调用将build合约的governance更改为0xdcc8A38A地址。

0x5a6ebeb6b61a80b2a2a5e0b4d893d731358d888583地址部分代码。

此地址获取governance权限后，0xdcc8A38A地址通过build 代币合约的mint函数向本身铸造了大约10亿的build代币，随后去交易池掏空流动性。

获取权限的流程图为：

攻击者利用类似的手法，从另外一个治理合约中转走了该治理合约所持有的代币资产。本次获利共162个ETH、20014个USDC 481405个DAI、75719个NCR约为112万美元。

最后，成都链安提醒：DAO合约应该设置合适的投票阈值，实现真正的去中心化治理，避免很少的投票数量就使得提案通过并成功执行，建议可以参考openzeppelin官方提供的治理合约的实现。