Quantcast
Channel: CodeSection,代码区,网络安全 - CodeSec
Viewing all articles
Browse latest Browse all 12749

以太坊代币“假充值”漏洞细节披露及修复方案

0
0

以太坊代币“假充值”漏洞细节披露及修复方案

披露时间线

以太坊代币“假充值”漏洞影响面非常之广,影响对象至少包括:相关中心化交易所、中心化钱包、代币合约等。单代币合约,我们的不完全统计就有 3619 份存在“假充值”漏洞风险,其中不乏知名代币。相关项目方应尽快自查。由于这不仅仅是一个漏洞那么简单,这已经是真实在发生的攻击!出于影响,我们采取了负责任的披露过程,这次攻击事件的披露前后相关时间线大致如下:

2018/6/28 慢雾区情报,USDT “假充值”漏洞攻击事件披露 2018/7/1 慢雾安全团队开始分析知名公链是否存在类似问题 2018/7/7 慢雾安全团队捕获并确认以太坊相关代币“假充值”漏洞攻击事件 2018/7/8 慢雾安全团队分析此次影响可能会大于 USDT “假充值”漏洞攻击事件,并迅速通知相关客户及慢雾区伙伴 2018/7/9 慢雾区对外发出第一次预警 2018/7/10 慢雾安全团队把细节同步给至少 10 家区块链生态安全同行 2018/7/11 细节报告正式公开

漏洞细节

以太坊代币交易回执中 status 字段是 0x1(true) 还是 0x0(false),取决于交易事务执行过程中是否抛出了异常(比如使用了 require/assert/revert/throw 等机制)。当用户调用代币合约的 transfer 函数进行转账时,如果 transfer 函数正常运行未抛出异常,该交易的 status 即是 0x1(true)。


以太坊代币“假充值”漏洞细节披露及修复方案
如图代码,某些代币合约的 transfer 函数对转账发起人(msg.sender)的余额检查用的是 if 判断方式,当 balances[msg.sender] < _value 时进入 else 逻辑部分并 return false,最终没有抛出异常,我们认为仅 if/else 这种温和的判断方式在 transfer 这类敏感函数场景中是一种不严谨的编码方式。而大多数代币合约的 transfer 函数会采用 require/assert 方式,如图:
以太坊代币“假充值”漏洞细节披露及修复方案

当不满足条件时会直接抛出异常,中断合约后续指令的执行,或者也可以使用 EIP 20 推荐的 if/else + revert/throw 函数组合机制来显现抛出异常,如图:


以太坊代币“假充值”漏洞细节披露及修复方案

我们很难要求所有程序员都能写出最佳安全实践的代码,这种不严谨的编码方式是一种安全缺陷,这种安全缺陷可能会导致特殊场景下的安全问题。攻击者可以利用存在该缺陷的代币合约向中心化交易所、钱包等服务平台发起充值操作,如果交易所仅判断如 TxReceipt Status 是 success(即上文提的 status 为 0x1(true) 的情况) 就以为充币成功,就可能存在“假充值”漏洞。如图:


以太坊代币“假充值”漏洞细节披露及修复方案

参考示例 TX:

https://etherscan.io/tx/0x9fbeeba6c7c20f81938d124af79d27ea8e8566b5e937578ac25fb6c68049f92e

修复方案

除了判断交易事务 success 之外,还应二次判断充值钱包地址的 balance 是否准确的增加。其实这个二次判断可以通过 Event 事件日志来进行,很多中心化交易所、钱包等服务平台会通过 Event 事件日志来获取转账额度,以此判断转账的准确性。但这里就需要特别注意合约作恶情况,因为 Event 是可以任意编写的,不是强制默认不可篡改的选项:

emit Transfer(from, to, value); // value 等参数可以任意定义

作为平台方,在对接新上线的代币合约之前,应该做好严格的安全审计,这种安全审计必须强制代币合约方执行最佳安全实践。

作为代币合约方,在编码上,应该严格执行最佳安全实践,并请第三方职业安全审计机构完成严谨完备的安全审计。

后记 Q&A

Q:为什么我们采取这种披露方式?

A:本质是与攻击者赛跑,但是这个生态太大,我们的力量不可能覆盖全面,只能尽我们所能去覆盖,比如我们第一时间通知了我们的客户,然后是慢雾区伙伴的客户,再然后是关注这个生态的安全同行的客户,最终不得不披露出细节。

Q:为什么说披露的不仅仅是漏洞,而是攻击?

A:其实,以我们的风格,我们一般情况下是不会单纯去提漏洞,漏洞这东西,对我们来说太普通,拿漏洞来高调运作不是个好方式。而攻击不一样,攻击是已经发生的,我们必须与攻击者赛跑。披露是一门艺术,没什么是完美的,我们只能尽力做到最好,让这个生态有安全感。

Q:至少 3619 份存在“假充值”漏洞风险,这些代币该怎么办?

A:很纠结,一般来说,这些代币最好的方式是重发,然后新旧代币做好“映射”。因为这类代币如果不这样做,会像个“定时炸弹”,你不可能期望所有中心化交易所、中心化钱包等平台方都能做好安全对接,一旦没做好这个“假充值”漏洞的判断,那损失的可是这些平台方。而如果平台方损失严重,对整个市场来说必然也是一种损失。

Q:有哪些知名代币存在“假充值”漏洞?

A:我们不会做点名披露的事。

Q:有哪些交易所、钱包遭受过“假充值”漏洞的攻击?

A:恐怕没人会公开提,我们也不会点名。

Q:这些代币不重发是否可以?

A:也许可以,但不完美。不选择重发的代币要么很快是发布主网就做“映射”的,要么得做好通知所有对接该代币的平台方的持续性工作。

Q:为什么慢雾可捕获到这类攻击?

A:我们有健壮的威胁情报网络,捕获到异常时,我们默认直觉会认为这是一种攻击。

Q:除了 USDT、以太坊代币存在“假充值”漏洞风险,还有其他什么链也存在?

A:暂时不做披露,但相信我们,“假充值”漏洞已经成为区块链生态里不可忽视的一种漏洞类型。这是慢雾安全团队在漏洞与攻击发现史上非常重要的一笔。


Viewing all articles
Browse latest Browse all 12749

Latest Images

Trending Articles



Latest Images