前言
据慢雾区情报，以太坊DeFi平台Lendf.Me遭受重入漏洞攻击。慢雾安全团队在收到情报后随即对此次攻击事件展开分析，并快速定位了问题所在。
据慢雾科技反(AML)系统初步统计分析，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
之后攻击者不断通过1inch.exchange、ParaSwap、Tokenlon等DEX平台将盗取的币兑换成ETH及其他代币。
Steadefi：协议已被利用，所有资金目前都面临风险:金色财经报道，杠杆收益聚合商Steadefi发布推文警告称：协议已被利用，所有资金目前都面临风险，链上消息已发送至攻击者钱包地址进行协商。协议部署者钱包（也是协议中所有保险库的所有者）已被泄露。剥削者已将所有金库（借贷和策略）的所有权转移到他们控制的钱包中，并继续采取各种仅限所有者的操作，例如允许任何钱包能够从借贷金库借入任何可用资金。目前，Arbitrum 和 Avalanche 上的所有可用借贷能力已被剥削者耗尽，资产被交换到 ETH 并桥接到以太坊。存款人的金库尚未耗尽（截至目前），因为剥削者没有从该金库提取存款的仅限所有者的功能。
链上数据显示，截至发稿时，该协议已损失至少 334,000 美元。[2023/8/8 21:31:00]
以下是详细分析过程。
攻击细节
本次对Lendf.Me实施攻击的攻击者地址为?0xa9bf70a420d364e923c74448d9d817d3f2a77822，攻击者通过部署合约?0x538359785a8d5ab1a741a0ba94f26a800759d91d对Lendf.Me进行攻击。
DeFi平台StakeDAO推出主动ETH期权策略:官方消息，由Staking服务提供商StakeCapital启动的DeFi平台StakeDAO宣布推出其首个主动ETH期权策略。StakeDAO使用Opyn开发人员工具包中的永续合约模板创建了一种自动化策略，该策略每周自动向做市商出售价外看涨期权，在锁定等值的ETH抵押品的情况下，该策略除ETH上涨收益外还能赚取做市商的权利金，并将权利金添加到自动化策略中进行复利进一步产生收益。[2021/8/23 22:30:52]
通过在Etherscan上查看攻击者的其中一笔交易：https://etherscan.io/tx/0xae7d664bdfcc54220df4f18d339005c6faf6e62c9ca79c56387bc0389274363b
Set Protocol与DeFi Pulse推出由10种DeFi代币组成的DeFi Pulse指数:去中心化资产管理协议Set Protocol和DeFi实时数据分析平台DeFiPulse宣布在Set Protocol资产管理自动化平台TokenSets上推出可供购买的DeFiPulse指数（DFP）。DFP由DeFiPulse团队支持，建立在Set Protocol的v2基础架构上，由以太坊上前10大最受欢迎的DeFi项目代币组成，分别为LEND、YFI、COM??P、SNX、MKR、REN、KNC、LRC、BAL和REPv2，计算方法为加权平均。目前，可在TokenSets与集成合作伙伴Pillar、Zapper、Dharma等上进行购买。SetProtocol表示，DeFiPulseIndexSet并非衍生品，而是一个包含10种DeFi代币的标准的ERC20包装代币。[2020/9/15]
我们发现，攻击者首先是存入了0.00021593枚imBTC，但是却从Lendf.Me中成功提现了0.00043188枚imBTC，提现的数量几乎是存入数量的翻倍。那么攻击者是如何从短短的一笔交易中拿到翻倍的余额的呢？这需要我们深入分析交易中的每一个动作，看看究竟发生了什么。
当前DeFi项目总市值突破100亿美元，其中LINK占比超50%:金色财经报道，DeBank数据显示，当前DeFi项目总市值约为100.69亿美元。其中，LINK市值约51.01亿美元，占总体份额50.66%，MKR市值约5.26亿美元，占总体份额5.23%，COMP市值约5.15亿美元，占总体份额5.12%。
注：\"DeFi 项目市值\"是衡量一个 DeFi 项目估值的指标。( DeFi 项目市值 = DeFi 项目代币价格 x 代币流通供应量 )[2020/8/9]
通过把该笔交易放到bloxy.info上查看，我们能知道完整的交易流程
通过分析交易流程，我们不难发现攻击者对Lendf.Me进行了两次supply()函数的调用，但是这两次调用都是独立的，并不是在前一笔supply()函数中再次调用supply()函数。
分析 | DeFi周报：DeFi项目锁仓价值11.3亿美元，过去一周环比增加9.63%:据DAppTotal.com DeFi专题页面数据显示：截至目前，已统计的32个DeFi项目共计锁仓资金达11.3亿美元，其中EOSREX锁仓3.52亿美元，占比31.08%，排名第一位；Maker锁仓3.13亿美元，占比27.66%，排名第二位；排名第三位的是Edgeware锁仓1.52亿美元，占比13.48%；Compound，Synthetix、dYdX、Nuo等其他DeFi类应用共占比27.78%。截至目前，ETH锁仓总量达327.81万个，占ETH市场总流通量的3.03%，EOS锁仓总量达1.1亿个，占EOS市场总流通量的10.64%。整体而言：1、过去一周，DAI的市场总流通量平均为8,627万美元，目前在DeFi借贷市场未偿还资产中，DAI占比84%；2、受行情波动的影响，DeFi项目整体锁仓价值较上周环比增长9.63%。[2019/10/28]
紧接着，在第二次supply()函数的调用过程中，攻击者在他自己的合约中对Lendf.Me的withdraw()函数发起调用，最终提现
在这里，我们不难分析出，攻击者的withdraw()调用是发生在transferFrom函数中，也就是在Lendf.Me通过transferFrom调用用户的tokensToSend()钩子函数的时候调用的。很明显，攻击者通过supply()函数重入了Lendf.Me合约，造成了重入攻击，那么具体的攻击细节是怎样的呢？我们接下来跟进Lendf.Me的合约代码。
代码分析
Lendf.Me的supply()函数在进行了一系列的处理后，会调用一个doTransferIn函数，用于把用户提供的币存进合约，然后接下来会对market变量的一些信息进行赋值。回顾刚才说的攻击流程，攻击者是在第二次supply()函数中通过重入的方式调用了withdraw()函数提现，也就是说在第二次的supply()函数中，1590行后的操作在withdraw()之前并不会执行，在withdraw()执行完之后，1590行后的代码才会继续执行。这里的操作导致了攻击者可提现余额变多。
我们深入分析下supply()函数
根据上图，可以看到，在supply()函数的末尾，会对market和用户的余额进行更新，在这之前，用户的余额会在函数的开头预先获取好并保存在?localResults.userSupplyCurrent，如下：
通过赋值给?localResults?变量的方式，用户的转入信息会先暂时保存在这个变量内，然后此时攻击者执行withdraw()函数，我们看下withdraw()函数的代码：
这里有两个关键的地方:
1、在函数的开头，合约首先获取了storage的?market?及?supplyBalance?变量。
2、在withdraw()函数的末尾，存在同样的逻辑对?market?用户的余额信息(supplyBalance)进行了更新，更新值为扣除用户的提现金额后的余额。
按正常的提现逻辑而言，在withdraw()单独执行的时候，用户的余额会被扣除并正常更新，但是由于攻击者将withdraw()嵌入在supply()中，在withdraw()函数更新了用户余额(supplyBalance)后，接下来在supply()函数要执行的代码，也就是1590行之后，用户的余额会再被更新一次，而用于更新的值会是先前supply()函数开头的保存在localResults?中的用户原先的存款加上攻击者第一次调用supply()函数存款的值。
在这样的操作下，用户的余额虽然在提现后虽然已经扣除了，但是接下来的supply()函数的逻辑会再次将用户未扣除提现金额时的值覆盖回去，导致攻击者虽然执行了提现操作，但是余额不但没有扣除，反而导致余额增加了。通过这样的方式，攻击者能以指数级别的数量提现，直至把Lendf.Me提空。
防御建议
针对本次攻击事件慢雾安全团队建议：
在关键的业务操作方法中加入锁机制，如：OpenZeppelin的ReentrancyGuard
开发合约的时候采用先更改本合约的变量，再进行外部调用的编写风格
项目上线前请优秀的第三方安全团队进行全面的安全审计，尽可能的发现潜在的安全问题
多个合约进行对接的时候也需要对多方合约进行代码安全和业务安全的把关，全面考虑各种业务场景相结合下的安全问题
合约尽可能的设置暂停开关，在出现“黑天鹅”事件的时候能够及时发现并止损
安全是动态的，各个项目方也需要及时捕获可能与自身项目相关的威胁情报，及时排查潜在的安全风险
附：
OpenZeppelinReentrancyGuard:https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/utils/ReentrancyGuard.sol
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。