transferProxy 与 approveProxy 的隐藏杀机：awesome-buggy-erc20-tokens 之 keccak256 哈希漏洞剖析

transferProxy 与 approveProxy 的隐藏杀机awesome-buggy-erc20-tokens 之 keccak256 哈希漏洞剖析【免费下载链接】awesome-buggy-erc20-tokensA Collection of Vulnerabilities in ERC20 Smart Contracts With Tokens Affected项目地址: https://gitcode.com/gh_mirrors/aw/awesome-buggy-erc20-tokens在 awesome-buggy-erc20-tokens 这个专门收集ERC20 代币合约漏洞的开源项目中有两类被编号为 A12 和 A13 的高危漏洞格外值得警惕——transferProxy与approveProxy中的keccak256 签名校验绕过漏洞CVE-2018-10376。这个漏洞的核心仅与一行代码有关当ecrecover()收到非法签名参数时会返回0x0地址而攻击者恰好可以把0x0作为_from参数传入从而绕过整个签名验证让任何人冒充任意账户转账或授权。SmartMeshSMT等 10 个已上币安之外的多家交易所的代币合约都栽在了这个零地址陷阱上。一、背景为什么 ERC20 合约漏洞如此普遍上图是 awesome-buggy-erc20-tokens 项目统计的以太坊主网每日 ERC20 合约创建量趋势图。可以看到 2018 年前后合约数量出现爆发式增长但其中大量合约是直接抄网上示例代码改出来的——而官方示例代码中恰好藏着一个著名的坑。在签名授权场景如委托转账、委托授权中合约常用这套内置函数组合来验证签名者是否本人keccak256()对交易内容计算哈希摘要ecrecover()根据哈希和签名v、r、s恢复出签名者地址再与_from比对。只要签名正确恢复出的地址必然等于_from验证通过。听起来天衣无缝对吧杀机就藏在ecrecover()的一个官方特性里。二、transferProxy 的 0x0 地址陷阱是怎么形成的transferProxy函数的本意是代替他人转账调用方提供一个签名合约验证签名属于_from就允许把_from的余额转走。其验证逻辑简化后只有两行计算hash keccak256(_from, _to, _value, nonce, name)若_from ! ecrecover(hash, v, r, s)则回滚。漏洞的关键在于ecrecover()在签名参数无效时并不会报错而是静默返回0x0地址。攻击者只需把_from参数填成0x0随便传入一组无效的 v、r、s。此时ecrecover()返回0x0与_from的0x0完全相等校验被合法通过交易照常执行——攻击者无需任何签名就能以0x0身份发起转账操作。在 approveProxy 中同样的手法可以让任何人替0x0地址批准任意花费额度破坏授权体系的完整性。这两类问题被项目统一归因为同一个 CVE-2018-10376proxyOverflow 漏洞家族。三、受害合约清单SMT 为何首当其冲项目为这两类漏洞分别维护了受影响的合约清单每类共收录10 个合约其中最有名的是 SmartMesh TokenSMT合约地址0x55F93985431Fc9304077687a35A1BA103dC1e081曾上线 Gate.io、HitBTC、Huobi、OKEx、YoBit 等 5 家交易所总供应量 3,141,592,653精度 18 位SMT 本身在 2018 年 4 月就已因整数溢出漏洞被黑客疯狂增发导致币价崩盘而其合约中的 proxy 签名漏洞又为它叠加了第二重风险——一个合约身背多个漏洞是复制粘贴式开发的典型恶果。你可以在以下数据文件中查到完整清单csv/transferProxy-keccak256.o.csv、json/transferProxy-keccak256.o.jsontransferProxy 漏洞合约列表csv/approveProxy-keccak256.o.csv、json/approveProxy-keccak256.o.jsonapproveProxy 漏洞合约列表raw/transferProxy-keccak256.txt、raw/approveProxy-keccak256.txt纯文本地址清单ERC20_token_issue_list.md全部 30 类漏洞的详细剖析A12、A13 章节bad_tokens.top.csv按排名汇总的问题代币总表SMT 同时命中 A12、A13、A16、A3 四类问题四、如何修复与防范一句话堵住零地址陷阱官方给出的修复方案非常简洁——在校验之前先拒绝零地址在执行keccak256ecrecover校验之前加入require(_from ! 0x0)让任何以0x0身份发起的代理交易直接回滚。除这一条最小修复外还有三条实战建议优先使用成熟安全库OpenZeppelin 等框架的签名校验已处理了零地址、重放攻击等边界情况不要手写裸的ecrecover逻辑。签名内容加入前缀与链标识哈希内容中加入域名/名称、nonce 等字段本例已含nonce与name可防跨合约重放但前提仍然是先把0x0挡在门外。上线前对照漏洞清单自查awesome-buggy-erc20-tokens 的 30 类问题几乎全是抄代码抄出来的开发时逐条对照ERC20_token_issue_list_CN.md中的问题清单是成本最低的安全实践。五、小结keccak256 哈希本身无可指摘杀机出在开发者忽略了ecrecover()的静默返回零地址行为。对普通用户而言投资前不妨用项目中的 CSV/JSON 数据表查一查目标代币是否命中transferProxy-keccak256或approveProxy-keccak256对开发者而言记住这一课凡是签名校验先require掉零地址。这份漏洞合集的价值正在于此——它把前人踩过的坑整理成了后来者的避雷地图。【免费下载链接】awesome-buggy-erc20-tokensA Collection of Vulnerabilities in ERC20 Smart Contracts With Tokens Affected项目地址: https://gitcode.com/gh_mirrors/aw/awesome-buggy-erc20-tokens创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考