昨天，去中心化交易所协议0x项目方称其发现严重安全漏洞。PeckShield安全人员跟进分析发现，0xExchange合约在校验订单签名时存在缺陷，导致攻击者可以进行恶意挂单，进而将用户的数字资产低价卖出，扰乱正常的交易秩序。所幸项目方及时发现并修复问题，截至目前，尚未有真实攻击发生，并没有产生数字资产损失。
背景
北京时间2019年07月13日，去中心化交易所0x协议项目方称其发现严重安全漏洞，并紧急关闭了0xExchangev2.0合约，随后部署了修复后的合约。受此影响，基于0x协议的交易所及钱包，包括RadarRelay，Tokenlon,StarBit等紧急暂停了相关交易服务。
PeckShield安全人员跟进分析发现，0xExchange合约在校验订单签名时存在缺陷，导致攻击者可以进行恶意挂单，进而将用户的数字资产低价卖出，扰乱正常的交易秩序。
0xScope：另一地址也曾在币安宣布上线RPL之时买入5353 RPL:金色财经报道，链上数据分析平台0xScope发推称，除了此前提到的以0x5f2c开头的地址外，另一个以0xac5ca开头的地址也在币安宣布上线RPL的数秒之后买入了5353枚RPL，此后该地址将3000枚RPL转入了币安，又在1inch将剩下的2353枚RPL卖出。
稍早之前，0xScope发推称一个以0x5f2c开头的地址在币安官宣上线RPL前10分钟买入近6200枚RPL，并在币安发布公告后10分钟卖出，在20分钟内盈利5.54万美元。[2023/1/18 11:19:07]
0x协议简介
0x协议是一个基于以太坊的开放协议，实现链上资产的点对点交易。它期望在以太坊上创建一种标准协议，使得任何人能够基于此协议运行去中心化交易所，实现以太坊上的代币之间的交易。0x协议上的交易特点是链下订单撮合，链上结算，其中为用户交易提供订单服务的参与者称为中继者。0x项目发行了自己的代币ZRX，一方面作为去中心化治理投票权的证明，同时也被作为交易服务费，用于建立在0x协议之上的中继者提供服务的收益。
标记为BitDAO的地址将9200万枚BIT转入“0xe51”开头地址:金色财经报道，根据Bit余烬的推特，链上标记为BitDAO：Bybit Locked的地址将9200万枚BIT转移至“0xe51”开头的地址。
据统计，“0xe51”开头的地址每个月都向几个到十几个地址分发BIT，其中在7月7日，向近300个地址各分发了几千至几万不等的BIT。[2022/12/16 21:48:06]
0x协议受到不少去中心化交易所和钱包的青睐，从Etherscan的DEX过去七天交易份额的饼图中能看到，排名靠前的RadarRelay和Tokenlon都是基于0x协议：
另外，从DAppTotal的DEX24小时交易额排名中也能看到它们的排名：
此前被传的0x99开头地址并非三箭资本钱包，或系隆领投资地址:6月15日消息，据KOL匿名博士，此前被传AAVE接近清算价格的地址0x997f0a825f24108f91218854e29936d546a1f532386949f2d8488735f77547d5并非三箭资本，经过链上查询，系美图创始人蔡文胜创立的隆领资本钱包地址。[2022/6/15 4:29:30]
由于Ethereum平台上大量的DEX都使用了0x协议，而作为最根本的TokenTranfer主合约出问题，这对于整个DEX领域来说，都是比较重大的事件。
漏洞原理分析
本次漏洞共涉及isValidWalletSignature和isValidValidatorSignature两个相似的漏洞，由于两者出问题的代码是相似的，本文只以前者为例说明。
SushiSwap联合创始人0xMaki作为顾问加入MITH Cash:官方消息，SushiSwap联合创始人0xMaki作为顾问加入MITH Cash。[2021/1/23 16:51:07]
isValidWalletSignature(bytes32,address,bytes)函数用于验证给定的Wallet合约所定义的签名信息与给定的签名是否一致，用于确保Order是由正确的Maker/Taker执行的交易。但是0xExchange合约在验证的过程中，存在着比较严重的问题：
上图是这一函数的全部逻辑，分为两部分：
组装签名具体字段为ABI编码格式；根据组装的ABI编码内容计算签名值正确性。其中，第2步的逻辑，在0xv2合约代码中是用汇编实现的:
SuShi社区启动0xMaki全职领导项目投票，东京时间晚8点前和社区共同起草最终条款:Sushiswap社区已经发起一项提案投票，旨在聘请0xMaki来领导该项目，此提案有Cinneamhain Venutres合伙人Adam Cochran提交，Adam Cochran也是“寿司”9位签名人之一。该提案指出，Sushiswap到目前为止还没有专职团队，0xMaki自己有一份日常工作，如果聘请他全职领导项目，将会：
1、预先支付50万SUSHI代币，并在锁定一份50万SUSHI币的创始人捐赠；
2、如果两年后继续为SUSHI工作还会支付额外50万SUSHI币报酬。0xMaki将作为核心团队负责人专注于构建SushiSwap，如果他不再为项目工作，社区可以撤销额外50万SUSHI代币，如果工作业绩出色，未来社区也可以投票为他建立额外预算和奖金。本文撰写时，赞成0xMaki领导“寿司”项目的投票率达到73.74%，本次投票结束时间为9月14日。
据0xMaki透露，他将在东京时间晚8点前和社区共同起草一份项目最终条款，以及未来工作的详细项目发展路线图，这样社区会对其后续工作有更直观的了解。[2020/9/12]
引入cdStart指针，指向calldata中对应的位置；对WalletAddress调用staticcallOpCode计算签名正确性，注意观察代码，其中的input和output都为cdStart这一指针，即复用input/output的内存；检验步骤2.2中的结果是否正确。WalletAddress为合约的前提下，这样子的流程没有问题。先来看下EVM中合约的执行流程是怎样的，PeckShield安全人员查阅EVM源码的时候发现：
当被调用的合约没有code,也就是EOA账号的情况下，什么都没有的执行，直接返回。因此，对应到isValidWalletSignature(bytes32,address,bytes)函数来说，其中的cdStart所对应的内存内容在调用staticcall前后并没有变化，而后面在判断签名是否正确的isValid取值的时候，也就取到了错误的值。
用户通过fillOrder(Order,uint256,bytes)函数完成Token买卖，PeckShield安全人员发现，这一函数的三个参数可以由用户自由配置：
分别为：
代表订单信息的Order类型；用户为此订单付出的Token数量；Order对应的签名信息signature其中比较关键的是Order及对应的signature信息的一致性正是通过上面的isValidWalletSignature类函数校验，因此，当攻击者精心构造signature为SignatureTypeWallet时，可『跳过』签名合法性检查，从而使得用户在不经意之间被恶意挂单，从而被攻击者顺利吃单，由于这一订单信息是由攻击者直接传入合约的，因此这一订单信息在线下的中继者也无法查询。
漏洞影响分析
基于上述分析发现，曾在0x协议Exchange上做过授权转账的普通用户帐号都将受到影响：
攻击者可伪造用户挂单，低价获得用户代币。
鉴于此安全漏洞的危害性，PeckShield安全人员发现0x项目方在漏洞被发现的时候先紧急关闭了0xExchangev2.0合约的Tokentransfer功能，将所有的ERC20、ERC721、以及MultiAsset的Transfer功能全部下线；随后部署了修复后的合约，同时告知用户及使用了0xExchange的所有DEX及Relayer，相关的迁移升级工作正在进行中。受此影响，基于0x协议的交易所及钱包，包括RadarRelay,Tokenlon,StarBit等紧急暂停了交易服务。
PeckShield安全人员通过漏洞特性分析链上数据发现，从0xExchange2018-09上线至今，并没有因此安全漏洞造成的用户直接资产损失。
对于使用了0x的DEX及钱包来说，当前的阶段需要暂停交易服务，如无法暂停交易服务的话，可将对应的0xExchange合约地址变更为当前已经修复的合约地址。
结语
0x协议本次出现漏洞的合约代码，主要是内联汇编代码编写签名验证功能出现的问题，直接编写汇编代码虽然在编译器无法优化合约代码的情况下非常有用，可控性更强且能提高执行效率，减少Gas消耗，但是编写Solidity汇编代码需要对EVM运行机制有非常熟悉的理解，不然EVM的某些特性可能导致编写的合约无法正常运行，同时也缺少了Solidity提供的多种安全机制。
PeckShield安全人员在此提醒广大开发者及时排查合约的相关代码，避免类似问题可能造成的安全风险，对于DEX等DeFi类项目，项目方在上线前需要找有资质的安全公司审计安全风险。
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。