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

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

以下是事件還原。

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

攻擊

這次攻擊主要分為4步。

首先,黑客利用ERC223方法漏洞,獲得提權,將自己的地址設為owner:

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

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

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

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

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

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

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

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

利用合約漏洞

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

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

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

3、Token合約可升級,在出現意外狀況時可進行治理。

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

並沒有什麼問題,但是兩者結合時,

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

從而獲得高級權限。

ERC223轉賬代 碼如下:

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

當黑客轉賬時在方法中輸入以下參數:

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

from: ·0x2eca25e9e19b31633db106341a1ba78accba7 d0f——黑客地址;

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代碼如下:

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

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

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

PS. 截至發稿前,ATN官方已聲稱:黑客將黑幣分散在14個不同的新地址中,而這些地址中並沒有ETH,暫時不存在立即轉賬到交易所銷贓的風險。

漏洞是怎麼造成的

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

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

例如,以下情況:

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

上述例子中,call函數的調用地址(如上圖中的_spender參數)是可以由用戶控制的,攻擊者可以將其設置為合約自身的地址,同時call函數調用的參數(如上圖中的_extraData參數)也是可以由用戶任意輸入的,攻擊者可以調用任意函數。

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

繞過權限檢查,調用敏感函數,例如setOwer;

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

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

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

怎樣避免此類漏洞

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

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

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

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

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

合約無小事

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

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

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


分享到:


相關文章: