一些智慧合約存在筆誤，一個字母可造成代幣千萬市值蒸發！

FLy_鵬程萬里發表於2018-07-15

在昨日，BCSEC安全團隊發現了某已經流通於多個交易所的ERC20代幣存在一個高危漏洞，隨後便通報給了廠商，沒有馬上披漏。但是今天BCSEC安全團隊發現此漏洞已經被利用，而且廠商已經進行了相應的措施，於是我們決定將此漏洞詳情進行披漏。

編碼筆誤問題

在開發者進行編碼的過程中，出現筆誤是非常常見的問題，有些筆誤非常隱蔽，在IDE不進行提示或報錯的情況下，用人眼非常難以發現，而且這種問題在以往的傳統安全中就發生過不少。

  1. 2016年Chrome V8引擎因開發者筆誤造成任意程式碼執行

  2. 由開發者筆誤把>= 錯誤地寫成了 ==造成的CloudFlare漏洞洩露海量使用者資訊

  3. ...

這些是在以往開發者在傳統應用上由於編碼筆誤造成的嚴重漏洞，而上面的例子僅是冰山一角。

在傳統應用中出現了這種漏洞的時候，常見的做法是直接釋出新版本通過升級來修補漏洞。

但在區塊鏈應用上，修復漏洞將變得異常艱難。

然而，在區塊鏈應用漏洞難以修復的情況下，還是出現了很多非常低階的筆誤問題。

  1. LCX、YEED等ERC20代幣存在可被任意關停交易的漏洞，而其根本原因竟是由於開發者將許可權判斷中的==寫成了!=，最終導致許可權判斷失效。

  2. ERC20代幣FuturXe存在任意轉賬漏洞，其根本原因是由於開發者將可用餘額判斷中的<寫成了>=，最終導致可有餘額判斷失效。

  3. ...

以上編碼筆誤問題都直接造成了非常嚴重的經濟損失，而其原因僅僅是開發者將某個字元寫錯造成。

建構函式筆誤

在關鍵操作的程式碼中，任何一個字元都必須要謹慎，而建構函式是進行非常敏感的初始化操作。

這時候若存在編碼筆誤會造成怎樣的影響呢，我們來看下面這個案例。

MorphToken，一個具有數千萬市值萬的ERC20代幣。


以上是MorphToken的部分程式碼，仔細看這段程式碼其實是沒有問題的，但是這個合約繼承了一個名為Owned的合約，而問題就出在這裡，我們繼續看。

乍一看，沒有問題，一段短而精悍的鑑權合約。

但是我們仔細看看建構函式

function owned() public

我們再看看合約名

contract Owned

發現問題沒有?合約名和建構函式大小寫不一致！

這會造成什麼問題？建構函式被識別為普通函式，任何人可以竊取owner許可權...

這不是個例。

BCSEC團隊使用內部掃描器就掃描出來50多種筆誤合約，而其中可以竊取owner許可權的更是有十多個。


如何預防？

使用solidity高於0.4.22的編譯器，並把建構函式寫為constructor。

這是solidity編譯器再0.4.22新增的一個特性，可以將建構函式寫為constructor避免程式設計師筆誤。

漏洞已經被黑客利用

在昨天我們發現此漏洞的時候我們及時通報給了廠商，但廠商並沒有給予回應。

我們打算等待廠商修復之後再進行披漏！


然而！就在13小時前，漏洞就已經被利用！


0x82d71f44fe03a0ecfe6765d45a871b7b9c30dd3e使用者竊取了owner許可權

隨後此使用者開始利用owner許可權對自己進行發幣！



而管理員的反應也非常迅速，於是他們展開了一場巔峰對決。。。



0x1ff使用者就是原管理員，在原管理員發現漏洞之後火速使用了數次漏洞函式，原管理員和黑客在爭奪owner許可權！

最終，原管理員終於奪回了owner許可權！並使用合約函式拉黑了黑客的賬戶。




這場對決到到此結束，我們來看看市場反應。


果不其然，跌到了歷史最低！

而這位黑客已經功成身退，賺的盆滿缽滿了。


黑客賣了近60萬個Morph ，大約價值為430個以太坊，換成人民幣就是130萬！

最後 ，官方也釋出了公告。


總結

關於區塊鏈的程式碼只要被去中心化後相要再修復是非常艱難的，所以上公鏈之前必須要對程式碼進行多方審計，而且不能放過任何一個細節。


相關文章