撰文:imToken
一个长期在以太坊上猎取普通交易者的 MEV 机器人,最终也掉进了一个价值 750 万美元的「定制版」陷阱。
6 月 21 日,以太坊上知名的三明治套利机器人 Jaredfromsubway.eth 遭到攻击,地址内的 WETH、USDC 等资产被转走,初步统计损失超 750 万美元(不过目前公开披露的损失口径仍有差异)。
有意思的是,这次攻击既不是私钥泄露,也没有利用传统意义上的智能合约漏洞,而是攻击者提前部署大量虚假代币、流动性池和辅助合约,将其包装成可能存在套利空间的交易路径,诱导机器人在自动化执行过程中,向恶意合约授予了 ERC-20 的 Approval,最终「合法」转走了该 MEV 机器人的资产。
截止发文时,Jaredfromsubway.eth 已通过链上消息向攻击者公开喊话,表示「若在 48 小时内归还 2150 枚以太坊,愿意支付五成白帽赏金,否则将采取一切可行的法律及执法手段追责」。
不过,连高度专业化代码驱动的 MEV 机器人,都会在 Approval 上栽跟头,也不禁让人重新审视,这个我们每天都在使用的「Approval」动作,究竟隐藏着多大的危险?
一、一场专为 MEV 机器人设计的反向围猎
如果认真复盘这次攻击事件,就会发现这并不是一次偶然触发的漏洞,而是一场针对 Jaredfromsubway.eth 交易逻辑设计的长期围猎。
Jaredfromsubway.eth 一直是以太坊上最知名的三明治套利机器人之一。所谓三明治攻击,简单来说,就是机器人发现一笔即将发生的链上交易后,抢先在用户之前买入,推动价格上涨;等用户以更差的价格完成交易,再立即卖出,从中赚取价差。
也正因如此,该策略要求机器人持续扫描链上交易,以极快速度判断套利机会,并组织交易路径,去调用不同的代币和合约,这也意味着速度越快、覆盖的资产与协议越多,机器人能够捕捉的机会也就越多。
但正是这一点,成为了这次事件的突破口。
根据事后复盘,攻击者并没有直接攻击机器人的资金合约,而是花费了数周时间,构造一组看起来能够盈利的交易环境:
- 第一步,是部署大量虚假代币与流动性池。这些代币在名称、接口和交易行为上模仿 WETH、USDC、USDT 等常见资产,让机器人的自动识别系统误以为发现了正常交易路径;
- 第二步,是逐渐获取机器人的信任。在早期测试中,机器人授予的授权随着交易正常使用,等到机器人的系统开始重复执行类似路径后,攻击者再调整合约逻辑,让机器人产生的部分授权不再被实际消耗,也没有在交易结束后归零,导致这些授权就这样留了下来;
- 最后,攻击者集中调用仍然有效的授权限额,将机器人合约里的真实 WETH、USDC 和 USDT 转出;
说白了,整套攻击完全瞄准了 MEV 机器人的运行特点,即先制造一个符合其盈利判断规则的环境,再利用其追求自动执行交易路径的机制,让系统主动交出资产调用权。
这也解释了为什么连高度专业化的 MEV 机器人都会中招。
它懂得如何计算价差、Gas 成本和交易顺序,却未必会对每一个新出现的合约进行充分的身份验证,从这个角度说,普通用户的问题是「没有看懂就点了确认」,自动化机器人的问题则是「没有确认就自动执行」。
表面上看,两者完全不同,底层风险却很接近,因为他们都把授权当成了完成交易之前的一个普通步骤,而没有清晰意识到它潜藏的风险有多高。
二、Approval 为什么总是被低估?
众所周知,在以太坊及 EVM 兼容链的 ERC-20 标准中,Approve(授权)是一个相当底层的设计。
不过用户在钱包里直接转账时,通常调用的是 transfer,一般不涉及 Approve,只有在 DEX、借贷、质押或者添加流动性等智能合约场景时,用户需要让智能合约代表自己调用代币,才涉及 Approval。
举个例子,当我们想在 Uniswap 上用 USDT 换成 ETH 时,Uniswap 的智能合约是不能直接去你钱包里拿走 USDT 的,必须先执行一次 Approve 去告诉系统「我允许 Uniswap 划走我钱包里的 X 个 USDT」。
只要授权完成后,获得权限的合约才能通过 transferFrom,在限定额度内调用用户的 USDT,后续的 Swap 也才能顺利完成。
也就是说,Approval 本身并不是漏洞,而是 DeFi 能够正常运转的重要基础。只不过,问题在于它有点像支付宝/微信的自动扣款权限:
用户没有把账户密码交给商户,但却允许商户在约定范围内主动扣款,只要授权仍然有效,后续扣款就不需要用户再次输入密码或者逐笔确认,这就天然带来一些问题。
首先是无限授权的问题,大家往往把一次交易变成长期权限。主要是为了减少重复授权产生的操作和 Gas 成本,不少 DApp 会默认申请一个极大的授权额度,也就是常说的「无限授权」。
用户原本可能只想用 100 USDC 完成一次交易,却允许合约未来动用自己地址里的全部 USDC。那只要该授权没有被撤销,即便用户当时的钱包里只有少量资产,未来重新转入的 USDC 也可能继续受到影响。
其次就是授权默认不会随着离开 DApp 而消失。很多用户会把「断开钱包连接」和「撤销授权」混为一谈,实际上,断开连接只是让网页暂时无法读取或请求当前钱包,并不会改变已经写入区块链的 Approval。
关闭网页、删除 DApp、清除浏览器缓存,甚至更换钱包应用,都不会让它自动失效。
最后,即便是正常合约,也可能在未来变得危险。因为很多授权风险并不只来自一开始就是恶意的钓鱼网站,就像此次的围猎,用户可能向一个当时正常的协议授予权限,但此后协议合约遭到攻击、管理员密钥泄露、可升级逻辑被替换,或者其调用的路由合约出现问题。
对于用户而言,资产仍然留在自己的地址里,但从权限角度看,另一个合约一直拥有调用这些资产的能力。因此,Approval 风险不只是「我有没有授权给坏人」,还包括「我授权的对象以后会不会出问题」。
三、那该如何管控 Approval 风险
面对 Approval 风险,最简单的建议就是「不要无限授权」。
但在真实的 DeFi 使用环境里,完全拒绝授权并不现实,正如上文所述,授权本身并不是漏洞,它是链上应用调用资产的基础方式。
真正需要改变的,是将 Approval 从一次性的确认动作,变成一套持续的权限管理机制。
那对于普通用户来说,首先需要建立几个基本习惯:
- 第一,遵循「最小权限」原则。在钱包弹出授权提示时,尽量根据本次交互的实际需要设置额度,比如只准备使用 100 USDT,就尽可能只授权接近 100 USDT 的额度,而不是直接开放无限权限;
- 第二,区分储存钱包和交互钱包。长期储存大额资产的地址,尽量不要频繁连接陌生 DApp;参与空投、Mint、新项目和高风险 DeFi 交互时,可以使用单独的地址,将潜在损失限制在较小范围内;
- 第三,定期检查并撤销不再需要的授权。用户可以通过 Revoke.cash 等工具,或在 imToken 中进入对应代币页面,点击左下角「Token Function」,再选择「授权管理」,查看该地址的授权对象、代币和额度,并对不再使用或来源不明的权限发起撤销(延伸阅读《手把手教你使用 Revoke.cash 进行授权管理》);
当然,说一千道一万,面对防不胜防的授权攻击,仅仅依靠用户的安全意识和定期检查还是不够的,毕竟大多数用户很难分辨一串合约地址究竟属于谁,也很难判断某个授权额度是否合理。
那作为用户进入 Web3 的第一道护城河,钱包必须在产品能力上提供主动防御。
以 imToken 为例,就会对已识别的风险代币、地址和 DApp 进行标记或拦截,当用户向普通外部账户授予代币权限,或者向合约地址直接转账时,也会提供针对性的风险提示,这些提示无法替代用户判断,但至少可以在真正签名之前,增加一道必要的安全缓冲。
除此之外,imToken 还在 DApp 登录、转账、代币兑换与授权等关键环节,对签名内容进行结构化解析与可读化呈现,尽可能帮助用户在确认之前理解自己正在同意什么,确保用户签署的内容,必须与其所看到的行为保持一致,而不是被压缩成一段难以辨识的哈希数据。
随着 ERC-7730 等 Clear Signing 标准进一步推进,这种「所见即所签(What You See Is What You Sign)」的可读化展示,也有望从单个钱包的产品能力,逐渐成为钱包、DApp 和智能合约之间共享的行业标准。
总的来看,私钥决定谁拥有账户,Approval 决定谁还能调用账户里的资产,两者并不是一回事,却同样重要。
这也意味着,钱包安全不能只停留在「私钥有没有泄露」,而且这需要从用户到钱包,大家共同努力:对用户来说,需要在授权前看清对象和额度,在交互结束后及时清理不再需要的权限;对钱包来说,则需要让这些原本隐藏在合约里的权限变得更可见、更容易理解,也更方便被限制和撤销。
毕竟,真正危险的未必是刚刚发生的那笔转账,也可能是一个早已被遗忘、却始终没有失效的授权。
