编者按：5月11日，ATN Token遭受恶意攻击，攻击者利用DSAuth库与ERC223搭配使用具有的混合漏洞，窃取了ATN的所有权。****之后，攻击者进行了窃取代币操作。
这是一起严重的黑客攻击事件，可以导致Token的供应总量发生变化。
归根结底，黑客这次又是冲着智能合约的编写漏洞来的。我们今天就来给大家从技术上揭底这次事件，并透过这次事件，奉上实用的合约编写建议。在此鸣谢成都链安科技CEO杨霞提供的独家资料。
事情发生在5月中旬，ATN技术人员发现Token合约由于存在漏洞受到攻击。不过ATN基金会随后透露，将销毁1100万个ATN，并恢复ATN总量，同时将在主链上线映射时对黑客地址内的资产予以剔除，确保原固定总量不变。
以下是事件还原。
事件回顾
2018年5月11日中午，ATN技术人员收到异常监控报告，显示ATN Token供应量出现异常，迅速介入后发现Token合约由于存在漏洞受到攻击。以下是黑客的攻击操作以及利用合约漏洞的全过程。
攻击
这次攻击主要分为4步。首先，黑客利用ERC223方法漏洞，获得提权，将自己的地址设为owner：
image
第二，黑客在获得owner权限后，发行1100w ATN到自己的攻击主地址：
image
第三，黑客将owner设置恢复，企图隐藏踪迹：
image
最后，黑客从主地址将偷来的黑币分散到14个地址中：
image
image
利用合约漏洞
ATN Token合约采用的是在传统ERC20Token合约基础上的扩展版本ERC223 ，并在其中使用了dapphub/ds-auth库。采用这样的设计是为了实现以下几个能力：
-
天然支持Token互换协议，即ERC20Token与ERC20Token之间的直接互换。本质上是发送ATN时，通过回调函数执行额外指令，比如发回其他Token。
-
可扩展的、结构化的权限控制能力。
-
Token合约可升级，在出现意外状况时可进行治理。
单独使用ERC223或者ds-auth库时，
并没有什么问题，但是两者结合时，
黑客利用了回调函数回调了setOwner方法，
从而获得高级权限。
ERC223转账代 码如下：
image
当黑客转账时在方法中输入以下参数:
image
-
from: 0x2eca25e9e19b31633db106341a1ba78accba7d0f——黑客地址；
-
to: 0x461733c17b0755ca5649b6db08b3e213fcf22546——ATN合约地址；
-
amount: 0
-
data: 0x0
-
custom_fallback: setOwner(address)
该交易执行的时候，
receiver会被_to（ATN合约地址）赋值，
ATN 合约会调用_custom_fallback
即DSAuth中的setOwner(adddress)方法，
而此时的msg.sender变为ATN合约地址，
owner_参数为_from(黑客地址)
ds-auth库中setOwner代码如下：
image
此时setOwner会先验证auth合法性的，而msg.sender就是ATN的合约地址。
setOwner的modifier auth代码如下：
image
通过利用这个ERC223方法与DS-AUTH库的混合漏洞，黑客将ATN Token合约的owner变更为自己控制的地址。获取owner权限后，黑客发起另外一笔交易对ATN合约进行攻击，调用mint方法给另外一个地址发行1100w ATN。
最后，黑客调用setOwner方法将权限复原 。
**PS. 截至发稿前，ATN官方已声称：黑客将黑币分散在14个不同的新地址中，而这些地址中并没有ETH，暂时不存在立即转账到交易所销赃的风险。
漏洞是怎么造成的？
这次事件主要是利用了开发者对以太坊底层函数call、callcode、delegatecall**的不当使用造成的。
call、callcode、delegatecall**是以太坊智能合约编写语言Solidity提供的底层函数，用来与外部合约或者库进行交互。不当的使用会造成很严重的后果。
例如，以下情况：
image
上述例子中，call函数的调用地址（如上图中的_spender参数）是可以由用户控制的，攻击者可以将其设置为合约自身的地址，同时call函数调用的参数（如上图中的_extraData参数）也是可以由用户任意输入的，攻击者可以调用任意函数。
攻击者利用上述操作，伪造成合约账户进行恶意操作，可能造成如下影响：
-
绕过权限检查，调用敏感函数，例如setOwer；
-
窃取合约地址持有的代币；
-
伪装成合约地址与其他合约进行交互；
因此，在编写合约时，此类函数使用时需要对调用参数的安全性进行判定，建议谨慎使用。
怎样避免此类漏洞
为了避免此类漏洞，我们提醒开发者应注意以下几点。
-
谨慎使用call、delegatecall等底层函数。此类函数使用时需要对调用参数进行限定，应对用户输入的call调用发起地址、调用参数做出严格限定。比如，call调用的地址不能是合约自身的账户地址，call调用的参数由合约预先限定方法选择器字符串，避免直接注入bytes可能导致的恶意call调用。
-
对于一些敏感函数，不要将合约自身的账户地址作为可信地址。
-
准备修复措施，增加Guard合约禁止回调函数向ATN合约本身回调。
-
增加黑名单合约，随时冻结黑客地址。
合约无小事
综合上文的分析，我们认为，call函数的使用一定要小心，在智能合约开发中尽量避免call函数的使用，如果使用需要对其相关参数进行严格的限定。另一方面，智能合约在部署之前应进行安全审计，比如代码的形式化验证等。
合约的安全审计，仅依靠开发者的经验和能力总有隐患，过去业内的几次合约漏洞事件也说明了这个问题，开发者务必要引起重视。
关于作者：
杨霞，成都链安科技CEO，创始人。电子科技大学副教授，最早研究区块链形式化验证的专家。一直为航空航天、军事领域提供形式化验证服务。主持国家核高基、装发重大软件课题等近10项国家课题。CC国际安全标准成员、CCF区块链专委会委员。发表学术论文30多篇，申请20多项专利。
网友评论