慢雾：Lendf.Me被盗全过程分析及防御建议

编者按：本文来自慢雾科技，Odaily星球日报授权转载。

据慢雾区情报，以太坊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及其他代币。以下是详细分析过程：

慢雾：Solana公链上发生大规模盗币，建议用户先将热钱包代币转移到硬件钱包或知名交易所:8月3日消息，据慢雾区情报，Solana公链上发生大规模盗币事件，大量用户在不知情的情况下被转移SOL和SPL代币，慢雾安全团队对此事件进行跟踪分析：

已知攻击者地址：

Htp9MGP8Tig923ZFY7Qf2zzbMUmYneFRAhSp7vSg4wxV、CEzN7mqP9xoxn2HdyW6fjEJ73t7qaX9Rp2zyS6hb3iEu、5WwBYgQG6BdErM2nNNyUmQXfcUnB68b6kesxBywh1J3n、GeEccGJ9BEzVbVor1njkBCCiqXJbXVeDHaXDCrBDbmuy

目前攻击仍在进行，从交易特征上看，攻击者在没有使用攻击合约的情况下，对账号进行签名转账，初步判断是私钥泄露。不少受害者反馈，他们使用过多种不同的钱包，以移动端钱包为主，我们推测可能问题出现在软件供应链上。在新证据被发现前，我们建议用户先将热钱包代币转移到硬件钱包或知名交易所等相对安全的位置，等待事件分析结果。[2022/8/3 2:55:22]

攻击细节

慢雾:BSC链上项目BXH遭受攻击分析:10月30日消息，据慢雾区情报，2021年10月30日，币安智能链上(BSC)去中心化交易协议BXH项目遭受攻击，被盗约1.3亿美金。经慢雾安全团队分析，黑客于27日13时(UTC)部署了攻击合约0x8877，接着在29日08时(UTC)BXH项目管理钱包地址0x5614通过grantRole赋予攻击合约0x8877管理权限。30日03时(UTC)攻击者通过攻击合约0x8877的权限从BXH策略池资金库中将其管理的资产转出。30日04时(UTC)0x5614暂停了资金库。因此BXH本次被盗是由于其管理权限被恶意的修改，导致攻击者利用此权限转移了项目资产。[2021/10/30 6:22:02]

本次对Lendf.Me实施攻击的攻击者地址为0xa9bf70a420d364e923c74448d9d817d3f2a77822，攻击者通过部署合约0x538359785a8d5ab1a741a0ba94f26a800759d91d对Lendf.Me进行攻击。通过在Etherscan上查看攻击者的其中一笔交易：https://etherscan.io/tx/0xae7d664bdfcc54220df4f18d339005c6faf6e62c9ca79c56387bc0389274363b

慢雾：Cover协议被黑问题出在rewardWriteoff具体计算参数变化导致差值:2020年12月29日，慢雾安全团队对整个Cover协议被攻击流程进行了简要分析。

1.在Cover协议的Blacksmith合约中，用户可以通过deposit函数抵押BPT代币；

2.攻击者在第一次进行deposit-withdraw后将通过updatePool函数来更新池子，并使用accRewardsPerToken来记录累计奖励；

3.之后将通过_claimCoverRewards函数来分配奖励并使用rewardWriteoff参数进行记录；

4.在攻击者第一次withdraw后还留有一小部分的BPT进行抵押；

5.此时攻击者将第二次进行deposit，并通过claimRewards提取奖励；

6.问题出在rewardWriteoff的具体计算，在攻击者第二次进行deposit-claimRewards时取的Pool值定义为memory，此时memory中获取的Pool是攻击者第一次withdraw进行updatePool时更新的值；

7.由于memory中获取的Pool值是旧的，其对应记录的accRewardsPerToken也是旧的会赋值到miner；

8.之后再进行新的一次updatePool时，由于攻击者在第一次进行withdraw后池子中的lpTotal已经变小，所以最后获得的accRewardsPerToken将变大；

9.此时攻击者被赋值的accRewardsPerToken是旧的是一个较小值，在进行rewardWriteoff计算时获得的值也将偏小，但攻击者在进行claimRewards时用的却是池子更新后的accRewardsPerToken值；

10.因此在进行具体奖励计算时由于这个新旧参数之前差值，会导致计算出一个偏大的数值；

11.所以最后在根据计算结果给攻击者铸造奖励时就会额外铸造出更多的COVER代币，导致COVER代币增发。具体accRewardsPerToken参数差值变化如图所示。[2020/12/29 15:58:07]

动态 | 慢雾： 警惕利用EOS及EOS上Token的提币功能恶意挖矿:近期由于EIDOS空投导致EOS主网CPU资源十分紧张，有攻击者开始利用交易所/DApp提币功能恶意挖矿，请交易所/DApp在处理EOS及EOS上Token的提币时，注意检查用户提币地址是否是合约账号，建议暂时先禁止提币到合约账号，避免被攻击导致平台提币钱包的CPU资源被恶意消耗。同时，需要注意部分交易所的EOS充值钱包地址也是合约账号，需要设置白名单避免影响正常用户的提币操作。[2019/11/6]

我们发现，攻击者首先是存入了0.00021593枚imBTC，但是却从Lendf.Me中成功提现了0.00043188枚imBTC，提现的数量几乎是存入数量的翻倍。那么攻击者是如何从短短的一笔交易中拿到翻倍的余额的呢？这需要我们深入分析交易中的每一个动作，看看究竟发生了什么。通过把该笔交易放到bloxy.info上查看，我们能知道完整的交易流程

声音 | 慢雾：警惕“假充值”攻击:慢雾分析预警，如果数字货币交易所、钱包等平台在进行“EOS 充值交易确认是否成功”的判断存在缺陷，可能导致严重的“假充值”。攻击者可以在未损失任何 EOS 的前提下成功向这些平台充值 EOS，而且这些 EOS 可以进行正常交易。

慢雾安全团队已经确认真实攻击发生，但需要注意的是：EOS 这次假充值攻击和之前慢雾安全团队披露过的 USDT 假充值、以太坊代币假充值类似，更多责任应该属于平台方。由于这是一种新型攻击手法，且攻击已经在发生，相关平台方如果对自己的充值校验没有十足把握，应尽快暂停 EOS 充提，并对账自查。[2019/3/12]

通过分析交易流程，我们不难发现攻击者对Lendf.Me进行了两次supply()函数的调用，但是这两次调用都是独立的，并不是在前一笔supply()函数中再次调用supply()函数。紧接着，在第二次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

标签：UPPPPLPLYSUPGuppykepple币最新价格SPLY币SUPD

以太坊交易所热门资讯