慢雾：Furucombo网站被黑剖析_数据来源

慢雾：Furucombo网站被黑剖析

知名 DeFi 新项目 Furucombo 网站被黑，损害超 1500 万美金。慢雾安全性精英团队第一时间干预剖析，并将进攻关键点共享给大伙儿。

此次产生难题的合约在 Furucombo 自身的代理商合约之中。全部进攻步骤非常简单。攻击者根据设定了 Furucombo 的 AaveV2 Proxy 的逻辑地址造成 事后根据 Furucombo 代理商合约调用的逻辑所有分享到攻击者自身的故意合约上，造成 随意资产失窃。

可是假如事儿这么简单，那麼此次剖析不值一提。难题远比想像的繁杂得多。

如圖所显示攻击者的通道在 Furucombo 的 batchExec 函数，大家先向 batchExec 函数开展剖析：

之上是 Furucombo Proxy 合约的 batchExec 函数的实际完成，在其中 _preProcess 和 _postProcess 合约分别是对调用前后左右做一些数据信息上的解决，不涉及到实际的调用逻辑，这里能够 先忽视。大家关键观查关键的 _execs 函数：

根据对 execs 编码的剖析不会太难发觉，函数的关键逻辑是对 configs 二维数组的数据信息做检查，并依据 configs 二维数组的数据信息对 data 开展一些解决。可是回望上原文中攻击者的调用数据信息，不会太难发觉攻击者的调用数据信息中，configs 的数据信息是一个 0 地址：

这儿有一个 trick，因为 0 地址是一个 EOA 地址，全部对 EOA 地址的函数调用都是会取得成功，可是不容易回到一切結果。融合这一 trick，execs 函数中的有关 configs 数据信息的一部分能够 先临时忽视。立即见到最终的关键 _exec 函数：

_exec 函数的逻辑也非常简单，在校检了 _to 地址后，立即就将 data 分享到特定的 _to 地址到了。而根据对进攻买卖的剖析，大家能发觉这一 _to 地址的确是官方网特定的合理合法地址。

最后一步，就是调用 _to 地址，也就是官方网特定的 AaveV2 Proxy 合约的 initialize 函数，将攻击者自身的故意地址设成 AaveV2 Proxy 合约的逻辑地址。根据对 Furucombo 合约的剖析，能够 发觉全部调用步骤上沒有发生比较严重的安全性点，对调用的地址也开展了授权管理的查验。那麼难题只有是出在了相匹配要调用的代理商逻辑上，也就是 AaveV2 Proxy 合约。

大家立即剖析 AaveV2 Proxy 合约的 initialize 函数的逻辑：

能够 见到 initialize 函数是一个 public 函数，并在开始就查验了 _implementation 是不是 0 地址，如果是 0 地址，则抛出去不正确。这一查验的目地实际上便是查验了 _implementation 是不是被设定了，假如被设定了，就没法再度设定。依据这一设定，不会太难想到 initialize 这一函数只有调用一次。除非是 AaveV2 Proxy 从来没有设定过 _implementation，不然这一调用是不容易取得成功的。难道说 Furucombo 确实沒有设定过相匹配的 _implementation 吗？带上那样的疑惑，大家查验了买卖内的情况转变。以下：

能够 见到，买卖中更改了储存部位为 0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc 的內容，而载入的內容恰好是攻击者自身的故意合约地址 0x86765dde9304bea32f65330d266155c4fa0c4f04。

而 0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc 这一部位，恰好是 _implementation 数据信息的储存地址。

换句话说，官方网从来没有设定过  AaveV2 Proxy 合约的 _implementation 地址，造成 攻击者钻了这一空档，导致了 Furucombo 财产损害。

根据对全部事情的剖析看来，Furucombo 本次安全事故并没有网络安全问题的范围内，关键的缘故取决于官方网将未开启的  AaveV2 Proxy 合约加上进了自身的授权管理中，而且未对 AaveV2 Proxy 合约开展复位，造成 攻击者趁虚而入。

现阶段，因为 Furucombo 遭到进攻，造成 一切将代币总受权过给 Furucombo 合约 (0x17e8ca1b4799a97602895f63206afcd1fc90ca5f) 的客户都将遭遇资产损害的风险性。

慢雾安全性精英团队提议与 Furucombo 互动过的客户查验是不是有将有关代币总受权给 Furucombo 合约。若有受权，应立即撤消有关受权，防止进一步损害。

这儿有一个 trick， 慢雾：Lendf.Me攻击者刚归还了126,014枚PAX:慢雾安全团队从链上数据监测到，Lendf.Me攻击者(0xa9bf70a420d364e923c74448d9d817d3f2a77822)刚向Lendf.Me平台admin账户(0xa6a6783828ab3e4a9db54302bc01c4ca73f17efb)转账126,014枚PAX，并附言\"Better future\"。随后Lendf.Me平台admin账户通过memo回复攻击者并带上联系邮箱。此外，Lendf.Me攻击者钱包地址收到一些受害用户通过memo求助。[2020/4/20]

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

动态 | 慢雾：10 月发生多起针对交易所的提币地址劫持替换攻击:据慢雾区块链威胁情报(BTI)系统监测及慢雾 AML 数据显示，过去的 10 月里发生了多起针对数字货币交易所的提币地址劫持替换攻击，手法包括但不限于：第三方 JS 恶意代码植入、第三方 NPM 模块污染、Docker 容器污染。慢雾安全团队建议数字货币交易所加强风控措施，例如：1. 密切注意第三方 JS 链接风险；2. 提币地址应为白名单地址，添加时设置双因素校验，用户提币时从白名单地址中选择，后台严格做好校验。此外，也要多加注意内部后台的权限控制，防止内部作案。[2019/11/1]

标签：

区块链热门资讯