8月12日，根据DAO Maker电报群用户反馈，该项目疑似遭到黑客攻击，价值700万美元的USDC被黑客提取至未知地址。团队经过分析后，发现该事件的起因是私钥泄露或者内部人士所为。
通过我们的交易分析系统（https://tx.blocksecteam.com）我们发现，攻击的过程非常简单。攻击交易的hash是：
0x26aa86261c834e837f6be93b2d589724ed5ae644bc8f4b8af2207e6bd70828f9
涉及到的地址：
0x41b856701bb8c24cece2af10651bfafebb57cf49: 受害者钱包
MakerDAO社区参与者提议创建以DAI为重点的新流动性市场Spark Protocol:2月9日消息，最新成立的一家研发公司Phoenix Labs在MakerDAO社区发起了一项新治理提案，提议创建一个名为Spark Protocol的新流动性市场，用于借贷以DAI为重点的加密资产。第一个产品将是Spark Lend，它将允许用户以设定的DAI储蓄率借入DAI，目前该利率为1%。根据提案，Spark Lend将支持高流动性的去中心化资产作为抵押品，例如ETH、DAI以及质押的ETH (wstETH)和 BTC (wBTC)的封装衍生品。未来的功能将包括固定期限收益产品和包含Maker 自己的合成液体质押衍生品（LSD），称为EtherDAI。
根据提案，Spark的目标是在今年4月推出，在Maker上开设一个债务上限为2亿美元的DAI借贷金库。Spark将使用Aave v3的智能合约系统。作为交换，开发团队Phoenix Labs打算在未来两年内将该协议在Spark Protocol的DAI市场上赚取的利润的10%发送给Aave DAO。实施Spark Protocol取决于Maker社区的投票。（CoinDesk）[2023/2/9 11:56:06]
0x1c93290202424902a5e708b95f4ba23a3f2f3cee: XXX，攻击者合约
安全机构：TempleDAO攻击者开始通过Tornado.cash转移资金:10月16日消息，PeckShield表示，TempleDAO攻击者开始通过Tornado.cash转移资金。
此前消息，TempleDAO项目遭受黑客攻击，涉及金额约236万美元。[2022/10/17 17:28:18]
0x0eba461d9829c4e464a68d4857350476cfb6f559：中间人
0x054e71d5f096a0761dba7dbe5cec5e2bf898971c：受害合约创建者（也是攻击者）
ZT启动 ZT DAO，并奖励 1000万枚ZTB:据官网公告，ZT将正式启动ZT DAO，同时ZT基金会将拿出1000W枚ZTB用于奖励所有ZT DAO的参与者和贡献者。
根据活动内容，持有10000枚以上ZTB的用户可在6月1日至6月30日期间报名，并于7月1日至7月31日进行投票竞选，8月1日开始按照投票数占比瓜分收益发放收益。
ZT DAO是包含于ZT基金会的去中心化社区组织，旨在以区块链技术为应用底层，丰富和完善ZT生态。[2021/5/29 22:55:15]
MakerDAO社区投票支持接受真实资产作为抵押品:金色财经报道，MakerDAO社区已就将真实资产（RWA）作为抵押品进行了投票。MakerDAO社区的投票大力支持了由初创公司Centrifuge牵头的两个新的抵押提案，该公司已开发出协议，可让用户将真实资产转换为可发行带息ERC 20代币的证券。Centrifuge已与Paperchain和ConsolFreight合作，以代币化音乐流版税和贸易发票。今天结束的投票为这些代币被用作铸造Dai的抵押品铺平了道路。Centrifuge首席执行官Lucas Vogelsang表示，Centrifuge及其合作伙伴现在将开始工作以确定使用哪些oracle、开发风险模型并审查智能合约的安全性。他估计这些步骤将花费几周到几个月的时间。一旦完成这项工作，将举行第二次具有约束力的投票，以确定是否将新代码添加到以太坊区块链上的智能合约中。[2020/6/9]
攻击者XXX （0x1c93290202424902a5e708b95f4ba23a3f2f3cee）调用受害者钱包合约(0x41b856701bb8c24cece2af10651bfafebb57cf49)的函数查询用户余额，然后调用withdrawFromUser将钱转到自己的账户。攻击完成。由于转账的操作是一个特权操作，因此通常需要对调用者的身份做校验。我们通过分析发现，攻击者确实具有相应的权限来将受害者钱包中的余额转出。
这里的问题就变成为什么攻击者能具有相应的权限？通过进一步分析我们发现另外一笔交易。这一笔交易将攻击者赋予具有转账的权限。交易trace如下：
0x2fba930502d27f9c9a2f2b9337a0149534dda7527029645752b2a6507ca6b0d6
0x0eba461d9829c4e464a68d4857350476cfb6f559调用受害者合约的grantRole函数将攻击者0x1c93赋予具有转账的权限。但是能调用grantRole赋予其他账户权限，那么0x0eba4必须具有admin的权限。那么他的admin权限是谁授予的呢？
继续追踪，我们发现它的admin权限是由另外一笔交易完成的。
0x054e71d5f096a0761dba7dbe5cec5e2bf898971c账户将0x0eba461d9829c4e464a68d4857350476cfb6f559账户设置成受害合约的admin。
然而我们发现，受害合约是由0x054e71d5f096a0761dba7dbe5cec5e2bf898971c创建的。
总结一下，整个的流程是：
那问题就来了，为什么部署受害者合约的0x054e最后间接赋予了攻击者能转账的特殊权限呢？这里有两个可能性。第一个0x054e是内鬼，第二个就是私钥泄露。
另外一个有趣的点就是攻击者的合约是开源的，代码简单易懂，可以作为学习合约开发的启蒙教程。
但是受害者的合约代码是不开源的。这有点匪夷所思。不开源的钱包也有人敢用？
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。