欢迎访问!

比特派资讯网

您现在的位置是:主页 > 区块链资讯 >

区块链资讯

tp钱包ios怎么下载|Fairyproof分析:一起三明治交易机器人被攻击案例

发布时间:2023-09-01区块链资讯评论
原文来源:Fairyproof 三明治机器人交易是区块链生态的日常交易中非常普遍的交易行为。通过机器人进行交易不仅能极大地提高交易效率,还能尽快发现交易中存在的套利机会。 安全的

原文来源:Fairyproof

三明治机器人交易是区块链生态的日常交易中非常普遍的交易行为。通过机器人进行交易不仅能极大地提高交易效率,还能尽快发现交易中存在的套利机会。

安全的机器人交易当然能达到上述目的,可不安全的机器人交易则有可能「偷鸡不成反蚀把米」。UTC 时间 8 月 29 日 06:04:39,BNB Chain 链上便发生了一起三明治交易机器人被攻击的案例。

在该起案例中被攻击的交易机器人总共损失了 207 个 WBNB、184900 个 BSC-USD 和 158900 个 BUSD,总资产价值约 39 万美元。

Fairyproof 在第一时间对该事件进行了分析,发现攻击原因疑似为函数调用权限验证不充分。

通常在 DEX(去中心化交易平台)的链上交易中,为了节省 gas,交易机器人会直接和交易对进行交互,而不通过 DEX 的 Router 合约。在基于 Uniswap 交易逻辑实现的 DEX 中,其交易对为先借后还,即调用交易者的特定回调函数(在本例中为 pancakeV3SwapCallback)来通知交易者代币已经借出,需要交易者进行相关操作以归还借出的代币。

因此,在交易合约中必须验证回调函数 pancakeV3SwapCallback 的调用者(msg.sender)为真正的交易对和交易的发起者(tx.origin)权限。由于 msg.sender 的验证相对复杂(有时要考虑兼容 Uniswap V2 导致验证逻辑复杂),因此大多数合约只验证了 tx.origin。

通常这么做是没有问题的。然而如果交易的某一步涉及到了恶意合约(在本例中就是攻击代币合约),则会发生风险,因为恶意合约调用 pancakeV3SwapCallback 时,tx.origin 是可以通过权限验证的。

在本次事件中,正是由于未验证 msg.sender 是否是 pancakeV3 交易池,攻击代币直接调用了 pancakeV3SwapCallback 函数并伪造了交易参数,从而通过了 tx.origin 验证并窃取了资产。

在本次攻击中,三明治交易的相关哈希值如下:

三明治机器人的合约地址如下:

·执行合约(存在漏洞):0x5C936E535Bb591C979a7c8D36C48a6B31808Cef9

·保险库合约:0x6E47b1123ddcF74E853516F934f5296cEb17D404

攻击代币的合约地址:0xb4864E14467B0D1a2AfB1F70b3f04D4aCd635e06

攻击代币交易对的地址:0xf61F401041a1AF03875B0E0d4AAa9749a57AEB93

攻击者的地址:0x30BA49Ca659B70d3723E3cA6ed96EA4EF0249893

本次攻击的主要内部交易流程如下图所示:

注,上图截取自此处

从上述流程中,我们可以分析攻击交易的具体步骤如下:

步骤 1:攻击者部署攻击代币合约并进行相关准备工作,发起一笔购买交易暴露给三明治交易机器人。

步骤 2:三明治机器人在 FrontRun 中调用 PancakeV3 交易池 0xf61F401041a1AF03875B0E0d4AAa9749a57AEB93 的 swap 函数来获取攻击代币。

步骤 3:交易池 0xf61F401041a1AF03875B0E0d4AAa9749a57AEB93 将攻击代币转给三明治机器人(Uniswap 系列的先借机制),这个过程会调用攻击代币的 transfer 函数。

步骤 4:攻击代币的 transfer 函数调用三明治机器人的 pancakeV3SwapCallback() 函数,并附带伪造的请求参数。

步骤 5:三明治机器人的 pancakeV3SwapCallback() 函数 tx.origin 验证通过,然后将资产从保险库中转移到攻击代币合约中(因为 pancakeV3SwapCallback 函数通常会将资产发送给 msg.sender)。

步骤 6:接下来是正常三明治交易流程。三明治机器人获利约 25 个 USDC。

步骤 7:攻击者提取代币合约中窃取的多种资产。所提取的窃取资产如下图所示,包括 WBNB、BSC-USD 和 BUSD:

注,上图截取自此处

本次攻击警示合约开发者合约接口一定要验证调用者的权限,也就是验证 msg.sender,仅仅验证 tx.origin 是不够的。

在类似的情景中,Fairyproof 建议首先验证 tx.origin,再验证下列两种情形之一:

1.初始调用合约的外部接口进行交易时,将交易对地址写入合约,在回调函数中对此进行验证。交易执行完毕后再重置这个交易对参数。虽然这样的操作会额外消耗 gas,但能极大提升安全性。

2.在合约中固定存入 Factory 地址,在回调函数中计算相应的交易对地址并进行相应的验证。

除此以外,对合约进行审计是确保项目安全的必要步骤。本例中出现的安全事故是完全可以通过安全审计发现并避免的。

Fairyproof 为区块链生态提供专业、完善、严谨的安全服务,涵盖合约审计、安全咨询、安全方案、实时监测、被盗资产追踪等。我们一直致力与生态中的合作伙伴共同携手,倾力打造安全的生态环境、保护用户的加密资产。

本文来自投稿,不代表 BlockBeats 观点