以太坊再爆高危漏洞！黑客增發ATN 1100萬枚token事件始末

 

事情發生在5月中旬，ATN技術人員發現Token合約因爲存在漏洞受到攻擊。不過ATN基金會隨後透露，將銷燬1100萬個ATN，並恢復ATN總量，同時將在主鏈上線映射時對黑客地址內的資產予以剔除，確保原固定總量不變。

如下是事件還原。

事件回顧

2018年5月11日中午，ATN技術人員收到異常監控報告，顯示ATN Token供應量出現異常，迅速介入後發現Token合約因爲存在漏洞受到攻擊。如下是黑客的攻擊操做以及利用合約漏洞的全過程。

攻擊

此次攻擊主要分爲4步。首先，黑客利用ERC223方法漏洞，得到提權，將本身的地址設爲owner：

 

第二，黑客在得到owner權限後，發行1100w ATN到本身的攻擊主地址：

 

第三，黑客將owner設置恢復，企圖隱藏蹤影：

 

最後，黑客從主地址將偷來的黑幣分散到14個地址中：

 

利用合約漏洞

ATN Token合約採用的是在傳統ERC20Token合約基礎上的擴展版本ERC223 ，並在其中使用了dapphub/ds-auth庫。採用這樣的設計是爲了實現如下幾個能力：

1. 自然支持Token互換協議，即ERC20Token與ERC20Token之間的直接互換。本質上是發送ATN時，經過回調函數執行額外指令，好比發回其餘Token。
2. 可擴展的、結構化的權限控制能力。
3. Token合約可升級，在出現意外情況時可進行治理。

單獨使用ERC223或者ds-auth庫時，

並無什麼問題，可是二者結合時，

黑客利用了回調函數回調了setOwner方法，

從而得到高級權限。

ERC223轉帳代  碼以下：

 

當黑客轉帳時在方法中輸入如下參數:

 

 

• 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代碼以下：

 

此時setOwner會先驗證auth合法性的，而msg.sender就是ATN的合約地址。

setOwner的modifier auth代碼以下：

 

經過利用這個ERC223方法與DS-AUTH庫的混合漏洞，黑客將ATN Token合約的owner變動爲本身控制的地址。獲取owner權限後，黑客發起另一筆交易對ATN合約進行攻擊，調用mint方法給另一個地址發行1100w ATN。

最後，黑客調用setOwner方法將權限復原 。

PS. 截至發稿前，ATN官方已聲稱：黑客將黑幣分散在14個不一樣的新地址中，而這些地址中並無ETH，暫時不存在當即轉帳到交易所銷贓的風險。

漏洞是怎麼形成的？

此次事件主要是利用了開發者對以太坊底層函數call、callcode、delegatecall的不當使用形成的。

call、callcode、delegatecall是以太坊智能合約編寫語言Solidity提供的底層函數，用來與外部合約或者庫進行交互。不當的使用會形成很嚴重的後果。

例如，如下狀況：

 

 

上述例子中，call函數的調用地址（如上圖中的_spender參數）是能夠由用戶控制的，攻擊者能夠將其設置爲合約自身的地址，同時call函數調用的參數（如上圖中的_extraData參數）也是能夠由用戶任意輸入的，攻擊者能夠調用任意函數。

攻擊者利用上述操做，僞形成合約帳戶進行惡意操做，可能形成以下影響：

1. 繞過權限檢查，調用敏感函數，例如setOwer；
2. 竊取合約地址持有的代幣；
3. 假裝成合約地址與其餘合約進行交互；

所以，在編寫合約時，此類函數使用時須要對調用參數的安全性進行斷定，建議謹慎使用。

怎樣避免此類漏洞

爲了不此類漏洞，咱們提醒開發者應注意如下幾點。

1. 謹慎使用call、delegatecall等底層函數。此類函數使用時須要對調用參數進行限定，應對用戶輸入的call調用發起地址、調用參數作出嚴格限定。好比，call調用的地址不能是合約自身的帳戶地址，call調用的參數由合約預先限定方法選擇器字符串，避免直接注入bytes可能致使的惡意call調用。
2. 對於一些敏感函數，不要將合約自身的帳戶地址做爲可信地址。
3. 準備修復措施，增長Guard合約禁止回調函數向ATN合約自己回調。
4. 增長黑名單合約，隨時凍結黑客地址。
   1. 合約無小事
   2. 綜合上文的分析，咱們認爲，call函數的使用必定要當心，在智能合約開發中儘可能避免call函數的使用，若是使用須要對其相關參數進行嚴格的限定。另外一方面，智能合約在部署以前應進行安全審計，好比代碼的形式化驗證等。
   3. 合約的安全審計，僅依靠開發者的經驗和能力總有隱患，過去業內的幾回合約漏洞事件也說明了這個問題，開發者務必要引發重視。

 

安全上鍊哪家強？華爲雲區塊鏈服務（Blockchain Service）是面向企業及開發者的高性能、高可用和高安全的區塊鏈技術平臺服務，能夠幫助企業和開發人員在華爲雲上快速、低成本的建立、部署和管理區塊鏈應用。華爲雲區塊鏈開放易用：基於Hyperledger1.0、kubernetes搭建，配置簡單，數分鐘內便可完成部署，提供全流程、多維度的自動化運維服務。安全隱私有保障！完善的用戶、祕鑰、權限管理和隔離處理，多層加密保障，國密和同態加密等隱私處理，可靠的網絡安全基礎能力，運營安全無憂。

歡迎體驗！https://www.huaweicloud.com/product/bcs.html