Popsicle攻击事件复盘分析 | 零时科技

2023-11-04 03:20

本文主要是介绍Popsicle攻击事件复盘分析 | 零时科技,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

事件背景

Popsicle Finance是专注于自动做市(AMM)流动性提供商(LP)的下一代跨链收益提高平台。旨在成为一个完全分散的平台,由其用户(ICE治理令牌的持有者)管理。ICE令牌将用于对协议更新,资产池包含,费用管理以及协议其他关键运营方面的提案进行投票。

零时科技区块链安全情报平台监控到消息,北京时间2021年8月4日,Popsicle Finance官方推文称Sorbetto Fragola被攻击,零时科技安全团队及时对该安全事件进行复盘分析。

事件分析

攻击信息

通过初步追踪分析,攻击者创建了3个攻击合约,进行了1笔攻击交易,共盗取资金价值超2100万美元,攻击信息如下:

攻击者钱包地址:

https://cn.etherscan.com/address/0xf9E3D08196F76f5078882d98941b71C0884BEa52

攻击者合约地址:

合约1:

https://cn.etherscan.com/address/0xdFb6faB7f4bc9512d5620e679E90D1C91C4EAdE6

合约2:

https://cn.etherscan.com/address/0x576cf5f8ba98e1643a2c93103881d8356c3550cf

合约3:

https://cn.etherscan.com/address/0xd282f740bb0ff5d9e0a861df024fcbd3c0bd0dc8

攻击交易:

https://cn.etherscan.com/tx/0xcd7dae143a4c0223349c16237ce4cd7696b1638d116a72755231ede872ab70fc

SorbettoFragola合约地址:

https://cn.etherscan.com/address/0xc4ff55a4329f84f9Bf0F5619998aB570481EBB48#contracts

攻击过程

攻击者在一笔交易中,利用同一攻击手法进行了多次获利,下面分步解析该笔交易,方便读者更清晰的了解攻击过程。

第一步:攻击合约1从Aave利用闪电贷借出3000万枚USDT,1.3万枚ETH,1400枚BTC,3000万枚USDC,300万枚DAI,20万枚UNI。

第二步:攻击者合约1通过Uniswap V3协议使用5492枚WETH和3000枚USDT添加流动性并获取10.52枚Popsicle LP。

第三步:攻击者合约1将获取的10.52枚Popsicle LP发送至攻击者合约2,后者又将LP发送至攻击者合约3,最后将LP归还至攻击者合约1。

第四步:攻击者合约1归还获取10.52枚Popsicle LP,得到添加流动性的5492枚WETH和3000枚USDT。

第五步:攻击者合约2和合约3分别从Uniswap V3优化器SorbettoFragola得到392枚ETH和215万枚USDT(凭空获利)。

交易信息中,攻击中循环执行8次同样的攻击(第二步至第五步)。

第六步:攻击者合约2和合约3将获取到的资金全部转至攻击者合约1。

第七步:攻击者归还闪电贷的3000万枚USDT,1.3万枚ETH,1400枚BTC,3000万枚USDC,300万枚DAI,20万枚UNI及其手续费。

第八步:攻击者将获取的资金统一转至攻击者钱包。

至此

攻击者通过该笔攻击交易获取了497万枚USDT,2560枚ETH,96枚BTC,538万枚USDC,16万枚DAI,1万枚UNI,总价值超过2100万美元。

走到这里大家可能会有疑问,交易的第三步为什么将LP多次转移,交易第五步为何会获取大量代币,下面我们从合约中分析SorbettoFragola合约代码逻辑。

攻击成功的原因

通过以上交易分析可以明确,攻击者将LP在攻击合约2和攻击合约3中转移后,这两个攻击合约就分别获取了大量资金,我们从交易logs信息中可查找出具体调用的合约调用事件,如下图:

从上图的信息我们可以发现,攻击者合约2触发了两次RewardPaid事件,分别是有LP时的触发和最后将LP转移走后的触发,但两次事件显示传入方法的参数截然不同,第一次为0,第二次为获利资金,我们继续分析RewardPaid事件对应的合约中collectFees方法,如下图:

上图collectFees方法中,RewardPaid事件触发需要进行三个主要判断:

  1. 修饰符执行updateVault(msg.sender);
  2. 判断奖励user.token0Rewards >= amount0;
  3. 判断(balance0 >= amount0 && balance1 >= amount1);

这里条件二是由updateVault(msg.sender)更新得到,只要获取的amount数值不超过奖励数值,均可完成该条件;条件三只要amount不超过对应合约余额,则该条件成立;下面继续分析条件一:修饰符updateVault(msg.sender),如下图:

调用_updateFeesReward方法,继续跟进,如下图:

上图updateFeesReward方法中,调用的第一个方法为pool.positionLiquidity,主要判断流动性是否为0,这里不做详细解释,我们主要来看获取奖励user.token0Rewards和user.token1Rewards变量相关联的四个方法:earnFees,tokenPerShare,fee0Earned,fee1Earned。

_earnFees方法,主要功能是获取Uniswap pool中的奖励数值,如下图:

_tokenPerShare方法,主要功能是通过earnFees方法中获取的奖励值来计算每个 LP 代币提供了多少代币,如下图:

fee0Earned,fee1Earned方法中,通过每个LP代币提供的代币数量,计算特定的用户可以获得多少token,如下图:

这里非常重要的一点是:

整个奖励计算流程中,只要user.token0Rewards奖励计算出来后,如果不提取奖励,该值不会再受到减少的影响,只可能通过fee0Earned方法更新不断增大。

攻击流程到这里就比较清晰了,攻击者合约1将LP转至攻击者合约2后,攻击者合约2随即调用漏洞合约的collectFees方法更新奖励值,随后将LP转出,由于user.token0Rewards奖励值只会叠加,并且该方法中并未判断调用者是否拥有LP,之后攻击者合约2再次调用collectFees方法获取user.token0Rewards奖励。

从以上攻击流程可以看出,攻击者利用SorbettoFragola合约未判断LP的归属问题,借助闪电贷资金,多地址移动LP并调用collectFees方法,多次循环操作后,获取大量代币。

总结

通过此次攻击事件来看,攻击者通过闪电贷资金,并通过SorbettoFragola合约未判断LP的归属问题,最终获得了大量代币,目前类似的闪电贷攻击事件居多,为何还会频频发生,对于DeFi项目而言,合约代码的安全,代币价格的相对稳定,旧版本的及时更新都是保证项目安全极其重要的部分,对于合约未判断LP的归属问题,应在合约上线前进行严格审查及测试。对于此类闪电贷攻击事件,零时科技安全团队给出以下建议:

安全建议

  • 对于合约代码安全,可找多家安全审计公司进行审计。

  • 对LP归属及获取奖励判断,应根据业务逻辑进行严格审核演算,避免出现参数可控导致盗币问题。

  • 对转账地址应进行严格判断,避免转账地址异常导致参数可控。

  • 使用可信的并且安全可靠的预言机,如Chainlink去中心化预言机,Alpha homera采用的。

  • 对敏感性较强的代码,要做到及时更新完善。

这篇关于Popsicle攻击事件复盘分析 | 零时科技的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/342878

相关文章

Nginx分布式部署流程分析

《Nginx分布式部署流程分析》文章介绍Nginx在分布式部署中的反向代理和负载均衡作用,用于分发请求、减轻服务器压力及解决session共享问题,涵盖配置方法、策略及Java项目应用,并提及分布式事... 目录分布式部署NginxJava中的代理代理分为正向代理和反向代理正向代理反向代理Nginx应用场景

Redis中的有序集合zset从使用到原理分析

《Redis中的有序集合zset从使用到原理分析》Redis有序集合(zset)是字符串与分值的有序映射,通过跳跃表和哈希表结合实现高效有序性管理,适用于排行榜、延迟队列等场景,其时间复杂度低,内存占... 目录开篇:排行榜背后的秘密一、zset的基本使用1.1 常用命令1.2 Java客户端示例二、zse

Redis中的AOF原理及分析

《Redis中的AOF原理及分析》Redis的AOF通过记录所有写操作命令实现持久化,支持always/everysec/no三种同步策略,重写机制优化文件体积,与RDB结合可平衡数据安全与恢复效率... 目录开篇:从日记本到AOF一、AOF的基本执行流程1. 命令执行与记录2. AOF重写机制二、AOF的

MyBatis Plus大数据量查询慢原因分析及解决

《MyBatisPlus大数据量查询慢原因分析及解决》大数据量查询慢常因全表扫描、分页不当、索引缺失、内存占用高及ORM开销,优化措施包括分页查询、流式读取、SQL优化、批处理、多数据源、结果集二次... 目录大数据量查询慢的常见原因优化方案高级方案配置调优监控与诊断总结大数据量查询慢的常见原因MyBAT

分析 Java Stream 的 peek使用实践与副作用处理方案

《分析JavaStream的peek使用实践与副作用处理方案》StreamAPI的peek操作是中间操作,用于观察元素但不终止流,其副作用风险包括线程安全、顺序混乱及性能问题,合理使用场景有限... 目录一、peek 操作的本质:有状态的中间操作二、副作用的定义与风险场景1. 并行流下的线程安全问题2. 顺

MyBatis/MyBatis-Plus同事务循环调用存储过程获取主键重复问题分析及解决

《MyBatis/MyBatis-Plus同事务循环调用存储过程获取主键重复问题分析及解决》MyBatis默认开启一级缓存,同一事务中循环调用查询方法时会重复使用缓存数据,导致获取的序列主键值均为1,... 目录问题原因解决办法如果是存储过程总结问题myBATis有如下代码获取序列作为主键IdMappe

Java中最全最基础的IO流概述和简介案例分析

《Java中最全最基础的IO流概述和简介案例分析》JavaIO流用于程序与外部设备的数据交互,分为字节流(InputStream/OutputStream)和字符流(Reader/Writer),处理... 目录IO流简介IO是什么应用场景IO流的分类流的超类类型字节文件流应用简介核心API文件输出流应用文

Android 缓存日志Logcat导出与分析最佳实践

《Android缓存日志Logcat导出与分析最佳实践》本文全面介绍AndroidLogcat缓存日志的导出与分析方法,涵盖按进程、缓冲区类型及日志级别过滤,自动化工具使用,常见问题解决方案和最佳实... 目录android 缓存日志(Logcat)导出与分析全攻略为什么要导出缓存日志?按需过滤导出1. 按

Linux中的HTTPS协议原理分析

《Linux中的HTTPS协议原理分析》文章解释了HTTPS的必要性:HTTP明文传输易被篡改和劫持,HTTPS通过非对称加密协商对称密钥、CA证书认证和混合加密机制,有效防范中间人攻击,保障通信安全... 目录一、什么是加密和解密?二、为什么需要加密?三、常见的加密方式3.1 对称加密3.2非对称加密四、

MySQL中读写分离方案对比分析与选型建议

《MySQL中读写分离方案对比分析与选型建议》MySQL读写分离是提升数据库可用性和性能的常见手段,本文将围绕现实生产环境中常见的几种读写分离模式进行系统对比,希望对大家有所帮助... 目录一、问题背景介绍二、多种解决方案对比2.1 原生mysql主从复制2.2 Proxy层中间件:ProxySQL2.3