2021 年 08 月 04 日，据慢雾区消息，跨链收益率平台 Popsicle Finance 的 Sorbetto Fragola 产品遭受黑客攻击，慢雾安全团队第一时间介入分析，并将结果分享如下。
攻击背景
在本次攻击中，攻击者通过创建 3 个攻击合约来完成对 Sorbetto Fragola 的攻击，以下是本次攻击涉及的具体地址：
攻击者：
H1：0x3A9D90eD069021057d9d11E78F142F2C4267934A
H2：0xf9E3D08196F76f5078882d98941b71C0884BEa52
攻击合约：
C1：0xdFb6faB7f4bc9512d5620e679E90D1C91C4EAdE6
C2：0x576cf5f8ba98e1643a2c93103881d8356c3550cf
C3：0xd282f740bb0ff5d9e0a861df024fcbd3c0bd0dc8
Sorbetto Fragola：
0xc4ff55a4329f84f9Bf0F5619998aB570481EBB48
攻击对象
通过官方的介绍我们可以知道被攻击的 Sorbetto Fragola 产品主要是用于帮助用户管理 Uniswap V3 头寸，以避免用户在 Uniswap V3 做市的头寸超出所选定的价格范围。用户可以在 Sorbetto Fragola 中存入提供流动性对应的两种代币，Sorbetto Fragola 会给到用户 Popsicle LP (PLP) 凭证，用户使用此凭证可以获取奖励并取回抵押的流动性资金，同时此凭证也是可以随意转移给其他用户的。
攻击核心
此次攻击的核心在于，Sorbetto Fragola 中通过用户持有的 PLP 凭证数量来参与计算用户所能获得的奖励，但 PLP 凭证是可以随意转移给其他用户的，但其凭证转移的过程中没有进行奖励结算转移等操作。这就导致了只要持有 PLP 凭证就可以立即获取奖励。最终造成同个 PLP 凭证却能在同个时间节点给多个持有者带来收益。接下来我们对整个攻击细节进行详细分析。
攻击细节
攻击首先通过 H1 地址创建了攻击合约 C1、C2 与 C3，随后攻击者通过 H2 地址调用了攻击合约 C1 开始进行具体的攻击，交易为：
尼日利亚中央银行将CBDC交易费用削减50%:金色财经报道，尼日利亚中央银行表示，它将把 e-naira 平台的交易费用削减 50%——该银行声称此举将增加中央银行数字货币 (CBDC) 平台上的交易量。中央银行还认为，更广泛地采用 CBDC 将提振尼日利亚的跨境贸易量。
此外，一份报告称，签约成为 e-naira 商家的尼日利亚企业有机会将各自的电子商务交易量增加 50%。[2022/8/31 12:59:00]
0xcd7dae143a4c0223349c16237ce4cd7696b1638d116a72755231ede872ab70fc。
通过分析此交易我们可以发现，其先从 AAVE 中利用闪电贷借出了 30,000,000 个 USDT、13,000 个 WETH、1,400 个 WBTC、30,000,000 个 USDC、3,000,000 个 DAI、200,000 个 UNI，为后续在 Sorbetto Fragola 中提供流动性获得 PLP 凭证做准备。
随后攻击者调用 Sorbetto Fragola 合约的 deposit 函数存入提供流动性对应的两种代币 (这里以攻击者首次存入的 WETH 与 USDT 代币为例)，其会先通过 checkDeviation 与 updateVault 修饰器分别检查价格与更新奖励。价格检查主要是针对价格是否出现大波动被操控等情况，这里不做展开。而奖励更新就与本次攻击密切相关了，我们切入分析：
可以看到其调用了 _updateFeesReward 函数进行具体的更新操作，我们跟进此函数：
去中心化社交平台Bluesky发布初始版本代码，将保留内容审核机制:5月6日消息，去中心化社交平台Bluesky发布初始版本代码，将保留内容审核机制。审核通过系统在多个层面进行，包括聚合算法、基于声誉的阈值和用户选择。此外，服务提供商需根据当地法律删除非法内容。
据悉，Bluesky由Twitter前首席执行官Jack Dorsey在2019年时创立，并获得Twitter1300万美元支持，目前Dorsey仍然是Bluesky董事会成员。（cointelegraph）[2022/5/6 2:53:43]
从上图我们可以很容易的发现其先通过 positionLiquidity 函数获取 tickLower 与 tickUpper 范围内合约所持有的流动性数量。然后通过 _earnFees 函数从 Uniswap V3 Pool 中收取提供流动性奖励。之后再通过 _tokenPerShare 函数计算每个 PLP 凭证所能分得的流动性奖励。最后通过 _fee0Earned 与 _fee1Earned 函数来计算用户所持有的 PLP 凭证数量可以获得多少奖励，并使用user.token0Rewards 与 user.token1Rewards 变量进行记录，如下图所示：
但由于此时攻击者刚进行充值操作，还未获得 PLP 凭证，因此其 user.token0Rewards 与 user.token1Rewards 变量最终记录的自然是 0。
看到这里你可能已经意识到问题所在了，既然 user.token0Rewards 与 user.token1Rewards 变量记录的奖励是根据用户持有的 PLP 凭证进行计算的，且 PLP 凭证是可以转移的，那么是否只要持有 PLP 凭证再去触发此变量记录奖励就可以让我们获得奖励。答案自然是肯定的。我们继续看 deposit 函数：
在奖励更新之后通过 liquidityForAmounts 函数计算出在目标价格区间内用户提供资金所占的流动性然后调用 Uniswap V3 Pool mint 函数注入流动性。随后通过 _calcShare 计算出 Sorbetto Fragola 所需要铸造给用户的 PLP 凭证数量。
在攻击者获得 PLP 凭着后也正如我们所想的那样将 PLP 凭证转移给其他地址，并调用 Sorbetto Fragola 合约 collectFees 函数来进行奖励记录。
通过上图的 PLP 凭证链上转移记录我们可以看到，在攻击合约 C1 获得 PLP 凭证后，将其转移给了攻击合约 C2，随后调用了 collectFees 函数。之后攻击合约 C2 再将 PLP 凭证转移给攻击合约 C3 再次调用了 collectFees。最后攻击合约 C3 将 PLP 凭证转移回攻击合约 C1。我们切入 collectFees 函数进行分析：
通过上图我们可以很容易的看出此函数也有 updateVault 修饰器，而经过上面的分析我们可以知道 updateVault 修饰器用于奖励更新，因此在攻击合约 C2 持有 PLP 凭证的情况下调用 collectFees 函数触发 updateVault 修饰器则会根据其持有的 PLP 凭证数量来计算应分得的奖励，并记入用户的 token0Rewards 与 token1Rewards 变量。需要注意的是此时对于此类 PLP 凭证持有者缓存的 tokenPerSharePaid 变量是 0，这直接导致了用户可以获得 PLP 凭证持有奖励。
我们从链上状态的变化也可以看出：
随后攻击合约 C2 也如法炮制即可获得奖励记录。
最后 PLP 凭证转移回到攻击合约 C1，并调用了 Sorbetto Fragola 合约的 withdraw 函数燃烧掉 PLP 凭证取回先前存入的 WETH 与 USDT 流动性。并且攻击合约 C2、C3 分别调用 collectFees 函数传入所要领取的奖励数量以领取奖励。这样攻击者在同个区块中不仅拿回了存入的流动性还额外获得多份流动性提供奖励。
随后攻击者开始利用其他的代币对如法炮制的薅取奖励，如下图所示：
攻击流程
1、攻击者创建多个攻击合约，并从 AAVE 中利用闪电贷借出大量的代币；
2、攻击者使用借来的代币存入 Sorbetto Fragola 合约中获得 PLP 凭证；
3、攻击者利用 Sorbetto Fragola 合约的奖励结算缺陷问题将获得的 PLP 凭证在其创建的攻击合约之间进行转移并分别调用了 Sorbetto Fragola 合约的 collectFees 函数来为各个攻击合约纪录奖励；
4、攻击者燃烧 PLP 凭证取回在 Sorbetto Fragola 合约中存入的流动性资金，并通过各个攻击合约调用 Sorbetto Fragola 合约的 collectFees 函数来获取纪录的奖励；
5、不断的循环上述操作攻击各个流动性资金池薅取奖励；
6、归还闪电贷获利走人。
MistTrack 分析过程
慢雾 AML 团队分析统计，本次攻击损失了约 4.98M USDT、2.56K WETH、96 WBTC、5.39M USDC、159.93K DAI、10.49K UNI，接近 2100 万美元。
资金流向分析
慢雾 AML 旗下 MistTrack 反追踪系统分析发现，攻击者 H1 地址首先从 Tornado.Cash 提币获取初始资金随后部署了三个攻击合约：
攻击获利后通过 Uniswap V3 将获得的代币兑换成 ETH 再次转入了 Tornado.Cash：
目前攻击者账户余额仅为 0.08 ETH，其余资金均已通过 Tornado.Cash 进行转移。
总结
本次漏洞的核心在于由于奖励更新记录缺陷导致同个 PLP 凭证能在同个时间节点给多个持有者都带来收益。针对此类漏洞，慢雾安全团队建议在进行凭证转移前应处理好奖励结算问题，记录好转移前后用户的奖励缓存，以避免再次出现此类问题。
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。