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

編者按：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：

第二，黑客在獲得owner權限后，發行1100w ATN到自己的攻擊主地址：

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

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

利用合約漏洞

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

天然支持Token互換協議，即ERC20Token與ERC20Token之間的直接互換。本質上是發送ATN時，通過回調函數執行額外指令，比如發回其他Token。

可擴展的、結構化的權限控制能力。

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參數）也是可以由用戶任意輸入的，攻擊者可以調用任意函數。

攻擊者利用上述操作，偽造成合約賬戶進行惡意操作，可能造成如下影響：

繞過權限檢查，調用敏感函數，例如setOwer；

竊取合約地址持有的代幣；

偽裝成合約地址與其他合約進行交互；

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

怎樣避免此類漏洞

為了避免此類漏洞，我們提醒開發者應注意以下幾點。

謹慎使用call、delegatecall等底層函數。此類函數使用時需要對調用參數進行限定，應對用戶輸入的call調用發起地址、調用參數做出嚴格限定。比如，call調用的地址不能是合約自身的賬戶地址，call調用的參數由合約預先限定方法選擇器字符串，避免直接注入bytes可能導致的惡意call調用。

對于一些敏感函數，不要將合約自身的賬戶地址作為可信地址。

準備修復措施，增加Guard合約禁止回調函數向ATN合約本身回調。

增加黑名單合約，隨時凍結黑客地址。

合約無小事

綜合上文的分析，我們認為，call函數的使用一定要小心，在智能合約開發中盡量避免call函數的使用，如果使用需要對其相關參數進行嚴格的限定。另一方面，智能合約在部署之前應進行安全審計，比如代碼的形式化驗證等。

合約的安全審計，僅依靠開發者的經驗和能力總有隱患，過去業內的幾次合約漏洞事件也說明了這個問題，開發者務必要引起重視。

關于作者：

楊霞，成都鏈安科技CEO，創始人。電子科技大學副教授，最早研究區塊鏈形式化驗證的專家。一直為航空航天、軍事領域提供形式化驗證服務。主持國家核高基、裝發重大軟件課題等近10項國家課題。CC國際安全標準成員、CCF區塊鏈專委會委員。發表學術論文30多篇，申請20多項專利。

《新程序員》：云原生和全面數字化實踐50位技術專家共同創作，文字、視頻、音頻交互閱讀

總結

以上是生活随笔為你收集整理的以太坊再爆高危漏洞！黑客增发ATN 1100万枚token事件始末的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。