从Lendf.Me黑客事件我们看到了什么？

转载

1670 天前

5331

链闻ChainNews

来源：链闻ChainNews 撰文：LeftOfCenter

作者特别感谢慢雾科技创始人余弦对本文的帮助。

对于 DeFi 投资者来说，这是一个不平静的周末。知名的 DeFi 贷款协议 Lendf.Me 平台上价值近 2500 万美元的资产被黑客洗劫一空，不过是个把小时的事情。

大约是在北京时间 4 月 19 日周日早上 9 点多，DeBank 的徐勇在微信群中截图提示， Lendf.Me 平台上的资金利用率显示异常。当时，该平台上几乎所有可借资产都出现极高的借出率，多个资产的利用率已经高达 99%，imBTC 的资金利用率则为 100%。DeFi Pulse 的数据也显示，Lendf.Me 平台锁仓资产迅速跌落。

很快，Tokenlon 发布公告宣布暂停 imBTC 交易。

Lendf.Me 团队随后证实，北京时间 8 点 45 分，在区块高度 9899681 遭受黑客攻击。该团队表示，已经关停网站并展开调查，技术团队已经定位问题，并在网页端建议所有用户停止往借贷协议存入资产。

至此，黑客已将 Lendf.Me 平台上的用户存储资产全部掏空。链上数据显示，被攻击后，Lendf 锁仓资产美元价值瞬间下跌 100% 至 6 美元，而此前的锁仓总价值超过 2490 万美元。链上观测发现，攻击者不断通过 1inch.exchange、ParaSwap、Tokenlon 等 DEX 平台将盗取的资产兑换成 ETH 及其他代币。

据区块链安全公司慢雾科技当时发布的统计，Lendf.Me 被攻击累计的损失约 24,696,616 美元，具体盗取的币种及数额为：

WETH: 55159.02134,
WBTC: 9.01152,
CHAI: 77930.93433,
HBTC: 320.27714,
HUSD: 432162.90569,
BUSD: 480787.88767,
PAX: 587014.60367,
TUSD: 459794.38763,
USDC: 698916.40348,
USDT: 7180525.08156,
USDx: 510868.16067,
imBTC: 291.3471

此时，我们很容易联想到前不久发生闪贷攻击的 bzx，那一次攻击也是发生在 1 月的某个周六，先后两次攻击共盗走了 90 万美金。当时，很多 DeFi 爱好者突然意识到，蒸蒸日上的 DeFi 并不是想象中的那么安全。

到了周日晚间，事情又发生了一些戏剧化变化，黑客开始向 Lendf.Me 返还部分资产。

链上信息显示，攻击者向 Lendf.Me 平台 admin 账户陆续转回 12.6 万枚 PAX、 38 万枚 HUSD 和 320 枚 HBTC，并附言「Better future」。这些资产属于合规的中心化资产，对于黑客来说，无法兑现，竟然退还了。

这一动作也在稍后团队发布的官方声明中得到了证实。 Lendf.Me 平台的发起方 dForce 的创始人杨民道在之后发表的一篇文章中称，「黑客试图与我们联系，而我们也打算与他们进行讨论」。Lendf.Me 平台的 admin 账户通过 memo 对攻击者进行了回应。杨民道称，正与交易所和执法机构合作追查黑客，全力抢救被盗资金。

与此同时，Lendf.Me 平台的多位受害者纷纷通过转账向黑客留言，求对方返还自己的血汗钱。至此，此次黑客盗窃已演变成一次大型群体事件。

团队同时还公布了后续解决该事件的几个措施，包括：1. 联系了顶级安全公司，对 Lendf.Me 进行更全面的安全性评估；2. 与合作伙伴一起制订解决方案，对系统进行资本重组，「虽然我们遭遇了攻击，但不会就此被打倒」；3. 正在与主流交易所、场外交易商和执法机构合作，调查该情况，扣留被盗资金并追查黑客。

截止目前，调查及被盗资金截断工作正在进行。

还原攻击过程

目前已知的情况是，攻击者利用了 imBTC 采用的 ERC-777 标准的一个「特性」，执行「重入攻击」（reentrancy attack ），导致市值约 2500 万美金的资产从 Lendf.Me合约里被取出。

慢雾对此次攻击事件的细节进行了详细还原：对 Lendf.Me 实施攻击的攻击者地址为 0xa9bf70a420d364e923c74448d9d817d3f2a77822，此次攻击者通过部署合约0x538359785a8d5ab1a741a0ba94f26a800759d91d 实现。

通过查看 Etherscan 上其中一笔交易发现：

攻击者首先是存入了 0.00021593 枚 imBTC，但是却从 Lendf.Me 中成功提现了 0.00043188 枚 imBTC，也就是说，提现的数量几乎是存入数量的翻倍。

那么攻击者是如何从短短的一笔交易中拿到翻倍的余额的呢？接下来，慢雾对一笔交易中的每一个动作进行了深入分析：

攻击者对 Lendf.Me 进行了两次 supply() 函数的调用，但是这两次调用都是独立的，并不是在前一笔 supply() 函数中再次调用 supply() 函数；
紧接着，在第二次 supply() 函数的调用过程中，攻击者在他自己的合约中对 Lendf.Me 的 withdraw() 函数发起调用，最终提现；
攻击者的 withdraw() 调用是发生在 transferFrom 函数中，也就是在 Lendf.Me 通过 transferFrom 调用用户的 tokensToSend() 钩子函数的时候调用的。很明显，攻击者通过 supply() 函数重入了 Lendf.Me 合约，造成了重入攻击。

如果说以上的技术细节对于小白来说不那么容易理解，那么，可以通过以下这个类比来通俗地理解何为重入攻击：

假设甲是现实生活中的一名诈骗犯，他来到银行柜台前对柜员乙表示需要取出自己账户里的所有钱。
柜员乙查询了甲的账户金额，将金额记账到了「待取款的临时账户」里。不过，还没等柜员乙从「待取款的临时账户」里把钱取出来并更新甲的账户金额及重置甲的「待取款的临时账户」，甲已经不见踪影；
甲以光速来到了另一个分行，向该分行的柜员丙表示需要取钱，柜员丙又执行了一遍之前柜员乙的操作：查询了甲的账户金额，将金额再次记账到了「待取款的临时账户」里，从「待取款的临时账户」里把钱取出来并更新甲的账户金额及重置甲的「待取款的临时账户」；
最终这导致甲取了自己金额两倍的钱，如此往复，直到将该银行的所有资金掏空为止。

在 Lendf.Me 黑客事件中，甲对应的是黑客，而银行则是 Lendf.Me。

祸从何处来？

这是 DeFi 领域中一次标志性的黑客事件，引发了业内广泛讨论，范围不仅仅局限于被黑金额和项目本身，更是涉及了安全的重要性、开放金融的意义、社区的包容性乃至中西区块链社区的误解和偏见。

首先，2500 万美金是一笔数目不小的损失，它可能是平台上普通用户的所有积蓄。对于这些 DeFi 领域的早期探索者而言，对中心化平台持怀疑态度让他们投向了开放金融的怀抱，这次这个沉重的代价无疑是一记重拳，打击了他们对 DeFi 的信心。

而对于项目方来说，这有可能意味着重头再来。Lendf.Me 作为 DeFi 领头羊之一，是从中国发起的明星区块链项目和冉冉升起的潜力之星，2019 年 9 月启动到目前仅半年时间，在开放金融借贷市场占有一席之地，并已发展成为最大的法币稳定币借贷协议。在被攻击事件发生之前，其资产规模接近 3000 万美元，并有近 1000 万美元的未偿还贷款。就在几天前，Lendf.Me 才获得来自 Multicoin Capital 、火币资本和招银国际的 150 万美金战略投资。

dForce 的创始人杨民道在声明中也表示，其个人也在本次黑客攻击中遭到了严重的经济损失。

更糟糕的是，除了直接受害者，此次事件带来的间接伤害可能更大。今年 2 月，DeFi 才刚刚迎来里程碑事件（锁定资产突破 10 亿美金），同时作为以太坊重要的真实用例，这可能会对以太坊甚至整个公链的失去信心。

针对此次攻击，有社区成员认为，平台方具有不可推卸的责任。Lendf.Me 本身作为运营方，对界面端的合约安全性审核不足，导致事故发生。对此，团队表示，已经联系了顶级安全公司，对 Lendf.Me 进行更全面的安全性评估，预计团队后续会在这个方面有所加强。

也有另一种声音则认为， imBTC 的资产发行方 Tokenlon 负有一定责任，在前一晚 Uniswap 发生事故关停 imBTC 的合约转账后，又重新开通了 imBTC 的合约转账功能，给了黑客可乘之机。

不过，Tokenlon 透露的信息则表示，在 4 月 18 日 17:00 重启 imBTC 的转账功能之前，曾经与 Lendf.Me 及其他 imBTC 合作平台沟通，并得到 Lendf.Me 及其他合作平台确认安全风险评估没问题后，才重启转账功能的。

imBTC 是与 BTC 1:1 锚定的 ERC-777 代币（兼容 ERC-20 ），由 Tokenlon 负责发行和监管，imBTC 采用 ERC-777 代币标准规范。

出于安全上的考虑，很多投资者纷纷开始清查哪些平台涉及 ERC-777 标准的代币，一时之间对 ERC-777 标准闻之色变。

也有人为协议标准喊冤，认为协议本身没问题，只是开发者在使用时没有考虑到其中存在的兼容性问题。

比如，有开发者认为，ERC20 之于 ERC777，就如同比特币之于以太坊，ERC20 虽然更加安全，但功能具有局限性。

诞生于 2015 年的 ERC20 标准，功能非常简单，因此也很受欢迎。但对于一个试图创建「可编程货币」的系统来说，ERC 20 代币标准的功能非常有限，其局限性导致了以太坊的许多用户体验问题。

ERC 777 标准可以看作是 ERC 20 标准的升级版，作为一种新的代币标准，它向后兼容 ERC20，并增加了一些新的功能，这些功能包括数据字段、运算符，配合合约钱包还可拒绝不想要的代币等功能。

但 ERC 777 可解决的最大问题是，通过添加「钩子」，提供以太坊代币之外的代币支付功能，这可实现在 Uniswap 中将 Dai 转换为 ETH 的交易只需一步即可完成。

对于不熟悉 ERC20 代币标准的同学，这里可以做个简单科普：由于 ERC20 代币标准没有「支付功能」，在进行代币交易时需要进行多笔交易，比如如果使用 Uniswap 将 ETH 转换为 Dai，基本上发送 ETH 即可获得 Dai，但如果是相反，将 Dai 转换为 ETH，则需要先进行一笔交易对 Dai 进行批准，之后才可以置换成 ETH。

这个问题的原因在于，ERC20 标准没有「支付功能」，这让合约在收到 ETH 时可以执行代码，但是在收到 ETH 之外的其他代币时则无法执行代码。而 ERC 777 通过添加「钩子」解决了这个问题，让 Dai 转换为 ETH 的交易一步即可完成。

但 ERC777 标准最大的问题是，调用「钩子」函数会导致安全问题。最近 imBTC/Uniswap 发生的两起安全事故就是黑客利用了 ERC777 标准导致的重入攻击，让攻击者可提现余额变多，直到掏空平台所有资产。

不过，重入攻击并不是什么新鲜事物。2017 年那起导致以太坊分家的「The DAO 事件」就是由可重入攻击引起的。对于开发者而言，新鲜事物可能是，重入攻击也会对 ETH 之外的代币产生影响，而此前，开发者了解的可能是：ETH 转移很容易受到重入攻击，但其他代币转移则是安全的。

此次事件更引发了对 DeFi 整个生态系统的反思。

被成为货币乐高的 DeFi 具有可组合和互操作性的特点，这给我们带来了无数的可能性。但硬币的另一面也是的 DeFi 的最大问题：作为一个复杂系统，DeFi 的风险也会被无限放大，系统的安全性取决于最短的那块木板，乐高积木中只要有一个模块出了问题，整个系统就会被拖垮。这就是经典的木桶原理。

为此，安全团队慢雾给出的防御性建议之一是：「在对多个合约进行对接的时候需要对多方合约进行代码安全和业务安全的把关，全面考虑各种业务场景相结合下的安全问题。」

再反思

那些出于对安全隐患的担忧，从中心化平台转向 DeFi 的早期探索者们，赫然发现，去中心化上的安全问题似乎更大。

尤其在近一年以来， DeFi 领域已经频频发生多起事故。

2019 年 6 月，Synthetix 受到预言机攻击，损失超过 3700 万 sETH 合成代币。
今年 1 月，bZx 先后遭到两次攻击，损失达 90 万美金；
今年 3 月，新晋 DeFi 明星项目 iearn.finance 提供的 Zap 智能合约因未检查滑点导致稳定币交易平台 Curve 出现一笔异常交易，后通过人为干预使得损失者几乎未遭受损失，但其创始人 Andre Cronje 称无法承受社交压力，将让该项目自运营。
3 月 12 日发生的黑天鹅事件导致部分清算人以价格为 0 的出价赢得以太坊抵押品清算程序的拍卖，导致 MakerDAO 出现近 500 万美元抵押不足的未偿债务，导致多名抵押者在市场抛售期间损失了所有抵押品。
Lendf.Me 黑客事件发生的前一天，黑客利用 Uniswap 的 ERC777 兼容性问题，盗走价值超 30 万美元的 imBTC。

显然，Lendf.Me 发生的这起事故不是第一起，也不会是最后一起。

此次黑客事件为整个行业敲响警钟，倒逼各个项目开始审查自己项目的安全的漏洞。

Lendf.Me 事件发生后的一天，利用联合曲线进行做市的去中心化稳定币交易平台 Curve 公布自己的 sUSD 资金池合约存在漏洞，称「所有的漏洞已经解决，资金安全，无损失发生」。Curve 请用户提回资金，并等候新合约部署，新合约的改变将进行审计。

到目前为止，已有兼容 ERC-777 标准的平台开始采取行动。以太坊「无损彩票」平台 PoolTogether 宣布已移除 ERC-777 标准的代币 plDai，之前这是为第三方的开发人员提供的小型资金池，仅涉及约 480 个 plDai。不过慢雾创始人余弦则表示，「拿掉 plDai 也不是彻底解决方案，他们自己的代码也往 ERC-777 去兼容实现，所以自己的代码还得加强。」

另一支区块链安全团队PeckShield 则提出了一个有效的解决方案，建议开发者采用「Checks-Effects-Interactions」方法来防止这类重入攻击。举个例子，Lendf.Me 的supply() 里如果是先更新 token 余额，再调用 doTransferIn() 。这将会让攻击在 withdraw() 之后没有重置余额的可能性。

这是一次极好的总结和反思机会，让项目和用户本身开始审视安全的重要性。长远来说，这有利于整个行业的发展。

对于项目方来说，未来最重要的是防微杜渐，以「如何最大限度保障平台资金的安全」/为此，慢雾提出了一系列防御建议：