EOSIO智能合約的安全性分析
責編：gltian ｜2021-05-12 10:35:07譯文僅供參考，具體內容表達以及含義原文為準
EOSIO區塊鏈是具有代表性的權益證明（DPoS）區塊鏈平臺之一，最近發展迅速。同時，在野還發現并觀察到針對熱門EOSIO DApp及其智能合約的許多漏洞和攻擊，造成了嚴重的經濟損失。大多數EOSIO智能合約不是開源的，它們通常會編譯為WebAssembly（Wasm）字節碼，因此很難分析和檢測可能存在的漏洞。在本文中提出了EOSAFE，這是第一個可用于自動檢測EOSIO智能合約中字節碼級別漏洞的靜態分析框架工具。框架包括一個用于Wasm的實用符號執行引擎，一個用于EOSIO智能合約的定制庫模擬器，以及四個啟發式掃描器，用于識別EOSIO智能合約中四個最流行的漏洞的存在。實驗結果表明，EOSAFE在檢測漏洞方面取得了較優結果，F1-measure為98％。截至2019年11月15日，已將EOSAFE應用于生態系統中所有有效的53,666份智能合約。結果表明，超過25％的智能合約易受攻擊。進一步分析了對這些易受攻擊的智能合約的可能的利用嘗試，并確定了48種在野攻擊（其中25種已由DApp開發人員確認），造成的財務損失至少為170萬美元。
0x01 Introduction
隨著加密貨幣（例如比特幣）的繁榮發展，區塊鏈技術變得越來越有吸引力，并在許多領域被采用。由于工作證明共識的帶來的吞吐量有限（例如TPS），因此不能使用傳統的區塊鏈平臺（例如比特幣和以太坊）來支持高性能應用程序。研究人員提出了不同的共識協議，例如權益證明（PoS）和委托權益證明（DPoS）以解決性能問題。
作為最具代表性的DPoS平臺之一，EOSIO已成為最活躍的全球社區之一。 EOSIO采用了基于DPoS共識協議的多線程機制，能夠實現數百萬的TPS。 EOSIO的性能優勢使其在去中心化應用程序（DApps）開發人員中很受歡迎。 EOSIO在其于2018年6月推出的三個月內，在DApp交易中成功超過了以太坊，并在接下來的幾個月中將其主導地位進一步提高了數十倍，EOSIO的交易量平均是以太坊的100倍以上。截至2019年，EOSIO的鏈上交易總價值已超過60億美元。
智能合約是一種計算機協議，允許用戶以便捷安全的方式進行數字協商。與傳統合約法相比，智能合約的交易成本大大降低，并且共識協議確保了其執行的正確性。 EOSIO智能合約可以用C ++編寫，然后將其編譯為WebAssembly（又名Wasm）并在EOS虛擬機（EOS VM）中執行。 Wasm是一個Web標準，為基于堆棧的VM指定二進制指令格式。它可以在現代Web瀏覽器和其他環境中運行。
但是，要保證執行智能合約的安全性并不容易，特別是EOSIO。 EOSIO智能合約中發現了許多漏洞，而在野發現了嚴重的攻擊，這造成了巨大的經濟損失。例如，在2018年秋天，由于虛假EOS（fake EOS）和虛假收據（fake receipt）漏洞，一個DApp EOSBet在短短一個月中遭受了兩次攻擊，分別造成40,000和65,000 EOS損失。因此，有必要識別智能合約的安全性問題，以防止此類攻擊。
不幸的是，EOSIO上的大多數智能合約都不是開源的，并且很少有分析工具來分析Wasm字節碼，這使得自動檢測EOSIO智能合約的漏洞更加困難。盡管已經有很多工具可以分析以太坊智能合約，但是它們都不能應用于EOSIO智能合約，因為這兩個生態系統完全不同，從虛擬機，字節碼結構到漏洞的類型。
具體來說，分析EOSIO智能合約存在一些挑戰。首先，就數量和種類而言，EOS VM比以太坊VM更復雜。例如，EOS VM支持浮點操作，類型轉換和br_table之類的高級跳轉指令。其次，與以太坊字節碼相比，Wasm字節碼本身由于函數中的多層嵌套結構而使分析更加復雜，從而導致基本塊之間的跳轉關系復雜。第三，到目前為止發現的大多數EOSIO漏洞比以前發現的簡單漏洞（例如整數溢出）更為復雜。因此，它通常需要更多的語義信息，例如平臺特定的數據結構的字段作為索引，以對其進行建模和分析。例如要檢測到虛假EOS，需要檢查apply函數中參數code的特定值。
本研究已經實現了EOSAFE，這是第一個用于檢測EOSIO智能合約漏洞的系統靜態分析框架。具體來說，首先為Wasm字節碼實現一個符號執行引擎，然后通過應用啟發式引導剪枝方法來緩解路徑爆炸問題。其次，為了分析EOSIO智能合約并模擬其外部交互環境，實現了一個模擬器來模擬關鍵EOSIO庫特征的行為，這些特征對于檢測漏洞至關重要。第三，提出了一個通用的漏洞檢測框架，該框架允許安全分析人員輕松地將自己的漏洞掃描器實現為插件。在這項工作中，實現了四個掃描器，旨在檢測四個重要的漏洞，包括虛假EOS，虛假收據，回滾（rollback）和缺失權限檢查（missing permission check）。
為了評估EOSAFE的有效性，首先手動設計了一個基準套件，其中包括52個智能合約，由從公開驗證的攻擊中收集的易受攻擊的智能合約及其相應的修補補丁組成，實驗結果表明EOSAFE在識別現有漏洞方面取得了出色的性能。為了衡量EOSIO生態系統中漏洞的存在，進一步將EOSAFE應用于生態系統中的所有智能合約（總計53,666）。實驗結果表明，安全漏洞在EOSIO生態系統中十分普遍：超過25％的智能合約（包括歷史版本）易受攻擊，并且其中很大一部分沒有及時修補。為了進一步衡量漏洞的影響，收集了交易記錄（總計超過25億筆交易），并精心設計了一套保守的啟發式策略，以識別針對這些脆弱智能合約的攻擊。已經識別出48起攻擊，以及183起缺少權限檢查的行為。截至撰寫本文時，DApp開發者已確認25起攻擊，已造成超過170萬美元的經濟損失。
2 Background
作為第一個工業級規模的分布式操作系統，EOSIO平臺可以實現高性能，即數百萬個TPS，以有效執行復雜的DApp。它如此高效地執行的事實很大程度上歸功于它使用的共識算法，即DPoS。與傳統的PoW（比特幣和以太坊采用）相比，它不會在不必要的挖掘過程中花費大量的計算資源。接下來，介紹一些關鍵概念以促進對這項工作的理解。
EOSIO中的帳戶是識別實體的基本單位，它可以觸發與EOSIO中其他帳戶的交易。此外，為了確保帳戶安全并防止身份欺詐，EOSIO實施了基于權限的高級訪問控制系統。具體而言，該帳戶可以將公共/專用密鑰分配給特定的操作，并且特定的密鑰對將只能執行相應的操作。默認情況下，EOSIO帳戶附加到兩個公用密鑰：ownerkey（用于指定帳戶的所有權）和active key（用于授予對帳戶活動的訪問權限）。這兩個密鑰授權兩個本機命名權限：owner和active權限，以管理帳戶。除了本機權限，EOSIO還允許自定義命名權限以進行高級帳戶管理。
與以太坊不同，EOSIO智能合約不被視為單獨的實體。智能合約只是帳戶中存儲的一小段代碼，這可以輕松解釋為什么EOSIO中的智能合約是可更新的，而不是所有者無法自由更改和銷毀的東西，因此，當一個帳戶被另一個人調用時，它所駐留的智能合約將負責處理收到的調用。這樣，合約中最關鍵的組件就是dispatcher，它可以將請求調度到相應的函數。由EOSIO官方定義，智能合約中的調度程序被命名為apply，如下所示。
事務是要由節點驗證的基本單位，它被打包在塊中。如下圖所示，一個事務由一個或多個action組成。動作是觸發函數的基本單位。例如，上面第1行的操作指定了目標函數名稱。一個動作負責攜帶調用者的權限。
一個動作可以通過兩種方式在同一上下文中觸發其他動作：inlined和deferred。具體來說，內聯動作可以看作是繼承其父級上下文（包括所攜帶的權限）的普通動作。至于延遲動作，引入該動作的原因是每個事務的執行時間上限為30毫秒，并且所有不必要的動作都可以分為延遲動作以執行。因此，如上圖所示，在不同的事務中執行了延遲的操作。
除了交易和動作外，還有另一種排他性機制，即notifification。如上圖所示，EOS是帳戶eosio.token發行的正式token。它維護一個表格以記錄持有人及其余額。因此，要將EOS轉移到DApp，用戶必須在eosio.token中請求transfer函數。對于上圖中的步驟1，指示實際調用其代碼的代碼是eosio.token；代表動作或通知的接收者的接收者也是eosio.token。更新余額表后，eosio.token將通知付款人和收款人（參閱步驟2和3）。請注意，步驟3中的代碼仍然是eosio.token，因為通知根本不是一個動作，而接收者是DApp。最后，通知也將由調度程序處理，就像使用相同的動作調用一樣姓名。
EOSIO智能合約用C ++編寫，然后編譯為WebAssembly（Wasm）字節碼，該字節碼將在EOS VM中執行。Wasm是基于堆棧的虛擬機的二進制指令格式。盡管它被設計為支持高性能Web應用程序的開放標準，但它也可以用于支持其他環境，例如區塊鏈。由于其高效性和可移植性，除了EOSIO之外，其他流行的區塊鏈（例如，以太坊2.0）也將支持Wasm。
EOSIO Wasm二進制文件稱為模塊。 在模塊內部，存在許多部分。 具體而言，在Function”部分中確定函數的順序，該順序與Code部分中函數（在低級指令中）的實現順序相對應。 出現在Element部分的所有函數索引都可以視為當前模塊的條目。 此外，字符串文字常用于初始化“內存”部分并存儲在Data部分中。
像以太坊VM一樣，EOS VM支持Stack，Local和Global，它們通過多個指令（例如local_set，global_get）從虛擬堆棧中推送和彈出。 同樣，EOS VM具有一個稱為Memory的區域，這是一個隨機可訪問的線性字節數組，只能通過使用特定指令（例如load和store）進行訪問。
0x03 Vulnerabilities in EOSIO Smart Contracts
在合約執行的生命周期內，可以隨時進行攻擊。因此首先游戲以DApp為例，介紹智能合約執行的一般生命周期，如下圖所示。首先，玩家在eosio.token中調用轉移以參與游戲。然后，當DApp收到通知時，它將分派要通過分派器進行transfer的請求。在那之后，transfer將調用reveal以計算一個隨機數，以確定玩家是否在本回合中中了頭獎。如果是，DApp將觸發eosio.token中的transfer，以將獎品返還給玩家。但是，攻擊者可以在每個步驟中利用這些漏洞來獲取利潤。例如，在第3步和第4步中，攻擊者可能無法嚴格驗證輸入參數的值。最重要的是，整個游戲過程都有可能被惡意回滾。在本節中討論與合約執行生命周期有關的四種常見漏洞。
任何人都可以創建和發行稱為EOS的token，因為token名稱和符號在EOSIO中不需要符合唯一性。因此，在上圖中的步驟3對code進行的不正確驗證可能會導致漏洞。
漏洞描述：由于eosio.token的源代碼是完全公開的，因此任何人都可以復制其源代碼并發行具有相同名稱，符號和代碼的token。虛假EOS與官方的EOS唯一的區別在于，它們的發行人不同。因此，如果攻擊者通過復制的合約的transfer函數將虛假EOS轉移到游戲DApp，則項目方收到的通知代碼將不會是beeosio.token。此外，如果DApp碰巧不檢查code的值，那么將繞過調度程序中的驗證。為了緩解上述問題，一些開發人員縮小了接受code的范圍，如前文的第6行所示“ code == self”用于處理來自其他帳戶的直接調用，而“ code == N（eosio.token ）”僅接受來自官方帳戶的通知。但是，由于短路評估，如果攻擊者直接在DApp中調用transfer，則驗證也將是無效的，因為兩個實體的余額都沒有變化。
由于這兩種情況僅與虛假EOS token有關，因此在本文中，將兩者都稱為虛假EOS漏洞。
如果DApp開發人員對code進行了全面檢查，則通知將由調度程序轉發到transfer，如上圖中的步驟4所示。但是，如果開發人員在此步驟中未執行驗證，則DApp可以被攻擊。
漏洞描述：通知可以轉發，并且code不會更改。因此，DApp可能會被同時扮演發起者和共犯雙重角色（帳戶）的攻擊者欺騙。具體來說，啟動器通過eosio.token調用對同伙（由to表示，transfer函數的參數）的常規轉移。當eosio.token通知共犯時，它將立即將通知轉發給DApp，而無需進行任何修改。這樣，code就不會更改，這是官方發行者：eosio.token。因此，調度器將不會發現任何異常情況。但是，如果不檢查transfer中的參數to，則DApp將被欺騙，因為token的轉移已在攻擊者控制的兩個帳戶之間完成。這會給DApp開發人員造成直接的財務損失。由于通知是由require_recipient觸發的，因此將此漏洞稱為虛假收據。
在前圖中，transfer和reveal是關鍵函數。在transfer中，DApp處理隨玩家轉帳而收到的壓注；在reveal中，開發人員經常使用各種鏈上狀態值作為種子（例如current_time，該值表示執行操作的時間戳）來生成偽隨機數，并最終通過將生成的數字與玩家的輸入進行比較來獲得結果。請注意，通常，回滾情況只能在游戲DApp中找到。假設reveal函數始終存在，并且對于每個游戲DApp而言都可以從入口點（即apply函數）到達。
漏洞描述：即使開發人員仔細檢查了輸入的每個參數，并在采取任何敏感措施之前檢查了調用者的權限，與前圖中的模型匹配的游戲仍然可能受到攻擊。具體而言，所有動作都是內聯調用的，即位于單個事務中。因此，當玩家在步驟8之后收到通知時，他可以立即調用eosio.token的另一個內聯動作來檢查其余額。如果他的平衡減少，則意味著他沒有贏得本輪比賽。他可以使用斷言語句來強制當前操作失敗。動作失敗可能導致整個交易恢復。這樣，玩家可以繼續嘗試，直到他中獎為止。將此惡意回滾稱為回滾漏洞。
在執行任何敏感操作之前，開發人員應檢查動作是否攜帶了相應的權限。例如，在前圖中的步驟5之前，DApp應檢查調用者是否可以代表實際付款人參加游戲。
漏洞描述：權限檢查由EOSIO中的require_auth（acct）強制執行，用于檢查調用者是否已被acct授權來觸發相應的函數。請注意，內聯操作繼承了其父級的上下文，包括權限（請參見第2.1節）。因此，如果攜帶不足權限的攻擊者調用了一個函數，該函數通過內聯動作并且沒有權限檢查就執行敏感操作，則可能會發生意外行為。將所有沒有權限檢查的函數視為缺少權限檢查漏洞。
0x04 Technical Challenges and Our Solutions
在EOSIO中，此問題主要是由于兩種情況造成的：執行條件跳轉指令（例如br_if）或調用函數調用。具體而言，與僅生成兩個新分支的普通條件跳轉指令不同，EOSIO中的br_table將其元素為目標指針的數組作為參數。結果，單個br_table可以導致n個新分支，其中n是數組的長度。除了這些條件跳轉指令外，函數調用還強加了許多新分支來表示已發送所有可能的被調用者。顯然，如果存在深度調用堆棧，則分支的數量將成倍增加。不幸的是，在EOSIO合約中，多個深度調用堆棧的串聯是很常見的。因此，實際需要緩解此問題，否則符號執行解決方案將不適用。
為此，采用啟發式指導的剪枝方法(heuristic-guided pruning approach)來解決挑戰。一方面,依靠幾種常規的修剪策略來緩解分支和深層函數調用帶來的問題。例如，操作觀察結果表明，根據場景確定的特定深度閾值下的路徑丟棄不會影響（幾乎）所有情況下結果的精度。具體來說公開:1）一個名為call depth的選項，它限制了調用堆棧的深度； 2）名為timeout的選項，供用戶限制符號執行的過程。
但是，一般緩解策略的有效性在實踐中是有限的。幸運的是，執行漏洞檢測時，EOSIO中的此問題可以得到進一步（部分）解決，因為只需要注意易受攻擊的代碼片段的某些特定函數/結構即可。例如，在檢測到虛假EOS和虛假收據漏洞時，僅考慮apply和transfer函數。
Wasm的存儲區可以看作是未解釋字節的向量，這意味著用戶可以通過load和store以不同的值類型來解釋這些原始位。模擬內存的傳統方法是使用線性數組，但是由于模擬了EOSIO智能合約的稀疏內存布局，因此非常耗費內存。因此決定使用key-value映射來模擬內存，其中鍵是用于指定地址范圍的元組，而值是要存儲的數據：(lower-bound,upper-bound) → data。
但是，此策略可能導致內存重疊（參見下圖）。如果使用映射而不進行優化，則可以直接存儲鍵（A + 2，A + 3），（A + 3，A + 4）和（A + 2，A + 4），而不會發生沖突。結果，如果使用鍵（A，A + 4）檢索數據，則存在兩種滿足條件的情況（下圖中的情況1和2），這可能導致檢索錯誤的數據。此外，在情況3中，如果要更新（A + 1，A + 3）中的數據，則必須遍歷鍵空間以確定是否只有一個實體包含提供的地址范圍，必須保證確保數據一致性。在情況4中，必須串聯相鄰的存儲數據塊，以確定如何將數據加載到存儲區中。簡而言之，所有這些問題都是由于內存重疊和映射策略不正確造成的。
本文提出了一種內存合并方法，通過合并分配的內存來解決此問題。如前所述，Wasm提供了20多個與內存訪問相關的指令。將首先為遇到的所有與存儲相關的指令創建鍵-值映射，其中值是按位存儲的數據。之后，可以根據所提出的內存合并算法處理兩個鍵的范圍相鄰或重疊的情況，該算法將更新相應的數據塊以保證執行的準確性。簡而言之，盡力確保任意兩個任意鍵之間的間隔至少為一位。通過這樣做可以成功克服上圖中提出的挑戰。
為了促進智能合約的開發，EOSIO允許將外部函數作為庫導入，這意味著這些導入函數的主體將不會編譯為Wasm字節碼。 EOSIO官方為DApp開發人員提供了大量諸如系統庫之類的函數。它們已在許多（如果不是大多數）智能合約中得到廣泛使用。結果，由于缺少那些導入的函數調用的主體，因此分析將被錯誤地終止。
為了解決依賴關系，提出了一種按需且語義感知的方法來模擬導入的函數。 僅關注其功能和副作用與本文的分析有關的功能。 必須正確模擬這些函數，以保證最終結果的正確性。 模擬的強度和覆蓋范圍取決于執行分析的需要。 對于某些函數，必須涵蓋參數，返回值和副作用。 例如，與內存有關的函數memmov，在其中必須考慮其對符號內存的所有副作用。 對于其他一些可能只需要考慮可能的副作用。 例如，對于那些沒有返回值且對漏洞檢測沒有影響的與表相關的函數，例如db_store_i64，可以平衡堆棧而無需模擬其行為。
0x05 System Design
下圖描繪了EOSAFE的總體架構，該架構以EOSIO智能合約的Wasm字節碼作為輸入，并最終確定該字節碼是否易受攻擊。具體來說，EOSAFE基于Octopus（用于Wasm模塊的安全分析框架）來啟動預處理。每個智能合約將被發送到Octopus，以使用反匯編的Wasm指令構建其相應的控制流圖（CFG）。
EOSAFE主要由三個模塊組成，即Wasm符號執行引擎（簡稱Engine），EOSIO 庫模擬器（簡稱Emulator）和漏洞掃描程序（Scanner）。如上圖所示，將預處理后的輸入（CFG）輸入到Scanner，以使用Engine和Emulator通過兩步過程（定位可疑函數和檢測漏洞）執行漏洞檢測。具體來說，Engine會相應地執行符號執行以及路徑約束，Scanner將使用路徑約束來執行漏洞檢測。此外，當Engine遇到對導入函數的調用時，Engine會請求Emulator實現建模的行為。
該引擎被設計為通用框架，可在基于堆棧的EOS VM上模擬智能合約的執行。它接受CFG和反匯編的Wasm指令作為輸入，并象征性地在基本塊內執行指令，以獲取所有可行的路徑。在此過程中，會相應地生成路徑約束。具體來說，該模塊必須維護兩個關鍵組件：路徑樹和狀態。對于路徑樹，不僅記錄由符號執行產生的約束，而且記錄沿路徑導入的函數的所有參數和返回值，這有助于分析漏洞檢測。關于狀態，維護一些必要的狀態相關信息，包括局部/全局變量，線性存儲器，堆棧以及后續指令及其相應的程序計數器。
本研究提供了兩個選項，包括call depth和time-out，供用戶通過犧牲準確性來緩解此問題。一方面，選項call depth用于限制調用堆棧的深度，以防止分析陷入處理復雜分支或深度函數調用的麻煩。眾所周知，單個函數可能具有與該函數內可行路徑相對應的幾組約束，這可能導致路徑數量呈指數增長。因此，限制了調用堆棧的深度以提高覆蓋范圍。另一方面，遇到一些非常耗時的情況時可能仍然會遇到麻煩。為了保證整個系統的進度，引擎提供了另一個名為time-out的選項，以控制路徑級分析的最大執行時間。當然，超時結果將被記錄以供進一步調查。請注意，路徑爆炸問題將在漏洞掃描器中進一步解決，因為只需要注意易受攻擊的代碼片段的某些特定函數即可。
本文實現了一個符號存儲器來表示Wasm的存儲器，并且還提出了一種存儲器合并算法來模擬存儲指令。該算法將符號存儲器，地址，字節數據長度和數據作為輸入，最后返回合并的符號存儲器，而沒有重疊/相鄰的鍵作為輸出。具體來說，給定要存儲的新鍵，將檢查現有密鑰的地址范圍是否與新密鑰的地址范圍重疊。如果是這樣，將直接執行插入操作；否則，它將相應地更新重疊的部分并連接不重疊的部分。此外，按鍵以起始位置的升序排列。如果兩個相鄰的鍵不重疊，它們將合并在一起以形成一個新的鍵值對。例如，現有的鍵值對是：symbolic memory := {(0,2) → a0|a1,(3,4) → a3}。當（2,4）→a2 | a’3到達時，它將更新重疊的部分并在必要時將不重疊的部分連接起來：symbolic memory := {(0,2) → a‘|a1,(2,4) → a2|a’3}。之后，它將合并相鄰的鍵：symbolic memory := {(0,4) → a0|a1|a2|a‘3}。簡而言之，該算法通過強制所有有效地址在鍵空間中僅出現一次來保證數據的一致性。
使用按需和語義感知的方法來解決EOSIO庫依賴關系。已經手動分析了排名前100位的流行DApp的智能合約和現有已知的易受攻擊的智能合約，以從Function部分提取所有導入的函數。然后，根據其主要函數（如下表所示）將所有導入的函數分為五類進行模擬。最后，可以從模擬的導入函數中檢索副作用。
區塊鏈狀態函數：這些函數返回與區塊鏈系統相關的常量，這些常量通常由智能合約用作種子以生成偽隨機數。由于它們不會帶來任何副作用，因此只是通過直接返回一個代表區塊鏈狀態的符號值來模擬它們。
與內存相關的函數：顧名思義，此類函數與已實現的符號內存有關。因此，將這些行為作為其初始進行模擬，并在插入新數據時應用內存合并算法。由于約束解決，為未定義的行為（例如memcpy函數的負長度）拋出了異常。
控制流相關函數：這些函數是可以根據其返回結果更改或終止智能合約的控制流的函數。因此如有必要，將分叉兩條路徑。例如，如果eosio_assert函數的謂詞是符號值而不是特定的布爾值，則將生成兩條路徑。
與授權相關的函數：由于權限系統僅與缺少權限檢查漏洞的檢測有關，因此只需要檢查這些函數的存在，而無需考慮特定的權限。因此，只返回一個符號值來平衡堆棧。
與表相關的函數：?EOSIO中有一個特殊的數據結構，可以持久存儲數據。與以太坊中的存儲概念類似，此類數據保存在稱為表的區塊鏈中。通過一些特定于平臺的指令，可以將Table視為支持CRUD操作（即，創建，檢索，更新和刪除）的數據庫。對于這些函數只需要關注內存的副作用，而不是內部操作。具體來說，使用用于更新內存的返回值實現了它們，如下所示：
請注意，對于沒有任何返回值但修改表內容的函數（例如db_update_i64），將其函數名稱和參數記錄在約束中。
C.漏洞掃描器
為了檢測多個漏洞，Scanner被設計為執行檢測的通用框架。它主要包括兩個步驟，即查找可疑函數和檢測漏洞。
只需要關注有價值的函數，這些函數可以調用具有更改鏈上狀態的外部函數，包括send_inline，db_update_i64和db_store_i64。根據觀察，在大多數情況下，這些有價值的函數可以試探性地視為目標函數，從而可以顯著減少分析時間。結果，借助CFG和路徑樹（由約束和有價值的函數組成），可以高效、準確地識別漏洞。具體來說，定義以下公式：
這里conX表示給定函數的約束，其中X是要分析的函數的名稱。僅當conX滿足三個條件中的至少一個條件時，X才是有價值的函數。
結果，檢測框架的兩個步驟可以進一步轉移并簡化為以有價值的函數為中心的過程：1）定位有價值的函數； 2）驗證其可發起攻擊的能力。請注意，該過程的第二步是可選的，因為在某些情況下始終可以保證可達性。基于此框架，將介紹四個掃描器的詳細信息。
如前文所述，虛假EOS漏洞只能通過調用傳遞函數來觸發，該傳遞函數成為可以導致財務損失的有價值的函數，它滿足以下條件：
而且，攻擊者必須能夠從條目（即apply函數）訪問transfer函數，這意味著在pply函數中沒有適當的code驗證。具體地說，掃描器遍歷通過象征性地執行apply函數生成的所有可行路徑，以檢查當前路徑的約束條件是否符合以下條件：
具體來說，它限制了只能分析與transfer函數關聯的路徑。為了加速分析，引擎將提前終止不相關的路徑（如果目的地不是transfer），以避免進一步執行。然后，掃描器將檢查code值。因此，滿足與code相關的任何條件都意味著存在不正確的驗證。綜上所述，滿足以上條件的智能合約被認為是易受攻擊的。
此漏洞是由于transfer函數內部的驗證不足所致。但是，相應的send_inline函數非常深，這總是導致調用深度溢出來破壞引擎。因此，直接通過符號執行從條目（即apply函數）中定位有價值的函數（即transfer函數）是不可行的。
為了解決該問題，改為采用基于啟發式的方法。具體而言，掃描器首先識別apply函數，然后枚舉所有相關的基本塊以驗證其跳轉目標的索引可能指向可疑的transfer函數。找到可疑的transfer函數后，掃描器將根據1到3的標準來確定有價值的transfer函數。請注意，對于給定的智能合約，應確切地存在一個transfer函數，這意味著transfer函數是可疑函數之一，或內聯在apply函數中，如下所示：
對于以上兩種情況中的任何一種，將進一步檢查以下保護的存在：
滿足以上條件的智能合約被視為容易受到偽虛假收據漏洞的攻擊。此外，該掃描器還采用盡早終止的方法來加速整個過程。具體來說，對于有價值的transfer，應在更新有關鏈上狀態的更改之前驗證保護。因此，在遇到三個標準中的任何一個而沒有沿途保護的情況下終止分析是合理的。
reveal函數通常會生成隨機數來確定頭獎中獎者，并通過內聯動作調用eosio.token中的傳遞函數以返還獎品。因此，根據標準1，reveal函數成為有價值的函數。但是，在某些情況下，處理reveal函數時必須考慮計算負擔，即send_inline函數的調用深度對于引擎來說太深了。
幸運的是，由于沒有必要考慮任何目標游戲DApp的路徑中send_inline函數的可達性，因此能夠應用兩種策略來加快定位reveal函數的過程。具體而言，第一種策略是按需遍歷可行的路徑。除了枚舉所有路徑外，僅檢查可用于解析目標send_inline函數的數據/變量依賴關系的路徑。另一方面，第二種策略在提取有價值的函數后減小了引擎正在檢查的路徑集的大小，即刪除了基本路徑完全是其他路徑的子集的冗余路徑。因此，可以獲得最小的路徑集，以覆蓋盡可能多的基本塊。
最后，檢測邏輯與兩個屬性相關聯。首先，研究表明，reveal函數將使用rem指令沿構造的路徑集中的路徑生成隨機數。其次，如果模運算的操作數（部分）是由區塊鏈狀態函數生成的，則智能合約將受回滾漏洞的影響。總之，檢測邏輯必須滿足：
這里operand2始終是與區塊鏈狀態無關的常量或變量。如果滿足上述條件，可以確認該合約容易受到回滾漏洞的影響。請注意，將刪除EOSIO官方庫（例如eoslib）生成的所有rem指令，以減少誤報。
將重點放在那些在敏感操作之前是有價值的和缺乏權威驗證的函數上。同樣，這些函數應該可以通過apply函數實現。根據1到3的標準對所有有價值的函數進行過濾后，將檢查約束條件是否符合以下條件：
具體而言，第一個條件首先要求該函數（由func標識）是攻擊者可以通過apply函數實現的。然后，第二個條件意味著可以直接觸發函數。最后，第三個條件檢查函數是否缺乏權限驗證。如果滿足上述條件，則智能合約容易受到缺少權限檢查漏洞的影響。
0x06 Implementation and Experimental Setup
實現：利用Octopus構建Wasm字節碼的CFG，并使用Z3定理證明（版本4.8.6）作為約束求解器。所有其他主要組件，包括Wasm符號執行引擎，庫模擬器和漏洞掃描程序，均由自己設計和實現。該實現基于Python，其中包括超過5.5k行代碼。
實驗設置：實驗是在運行Debian的服務器上執行的，該服務器具有2.10GHz @ 64G RAM的四個Intel?Xeon?E5-2620 v4。Wasm引擎提供了兩個配置選項（即調用深度和超時）來部分解決路徑爆炸問題。在實驗過程中，根據經驗將調用深度設置為2層，它足以識別大多數漏洞。關于檢測時間，由于以下兩個主要原因，根據經驗將上限設置為5分鐘。首先，在5分鐘內，可以對基準中的所有智能合約進行全面分析并檢測出有希望的結果。其次，當試圖將EOSAFE應用于所有EOSIO智能合約時，必須在準確性和可擴展性之間進行權衡。因此，每個合約的檢測時間最多設置為5分鐘。請注意，所有這些設置都可以在工具中輕松配置和自定義，以滿足不同的要求。
研究問題：本文評估以下三個研究問題（RQ）
RQ1：?EOSAFE在檢測EOSIO智能合約的漏洞方面的準確性如何？
RQ2：這些漏洞在生態系統中是否普遍存在？
RQ3：攻擊者利用了多少智能合約，這些攻擊的影響是什么？
為了回答RQ1，在研究社區中沒有建立基準的情況下，本文收集實際攻擊并手動檢查受害智能合約以制定可靠的基準。為了回答RQ2，收集了EOSIO上所有可用的智能合約及其歷史版本。然后，應用EOSAFE來檢測安全漏洞的存在，并描述漏洞的演變。為了回答RQ3，進一步收集與已標記的易受攻擊合約相關的所有鏈上交易，然后提出啟發式方法以查明可能的攻擊。
0x07 Experimental Results
基準：為了評估EOSAFE，首先努力制定一個基準，并將其提供給社區。不時報告EOSIO攻擊。因此訴諸于知名區塊鏈安全公司發布的安全報告，以收集所有相關的公開驗證的攻擊作為數據。已經收集了38次攻擊，針對總共34個不同的易受攻擊智能合約。盡管這些攻擊已由相應DApp的官方團隊確認，但發現某些攻擊與智能合約本身無關，但與其他外部因素有關，例如服務器的問題。因此，進一步手動檢查了所有涉及的智能合約。具體來說，發現10種虛假EOS攻擊中有3種與服務器問題有關。對于回滾，21種攻擊中有11種是由于服務器的錯誤顯示策略所致。此外，其中兩個是回滾的變體，它們與EOS MainNet上某些節點的配置有關。最后，將上述所有合約從基準中排除，以確保所有攻擊均來自智能合約本身中的代碼。
基準的分布顯示在上表中，還收集了相應的修補智能合約（無漏洞）作為評估EOSAFE有效性的比較。此外，據報告，僅有兩個與缺少權限檢查漏洞有關的易受攻擊的智能合約，并且尚未對其進行修補。因此，進一步手動創建了4對智能合約（有和沒有缺少權限檢查漏洞）以補充基準。最終總共將52個智能合約標記為基準。
結果：在52份智能合約中，EOSAFE將26份標記為易受攻擊，只有一個漏報性案例（屬于回滾），沒有誤報性，導致準確率和召回率分別為100％和96.97％。上表顯示了詳細的結果。對于回滾的唯一錯誤否定情況，即fair-dogegame / betdogewallt，根本原因是可疑的揭示數量過多，無法建立路徑，并且在給定的超時時間（此處為5分鐘）內象征性地執行了它們。手動定位易受攻擊的函數（即func73）后，可以獲得正確的結果。因此，優化策略引入了漏報性，這是準確性和可伸縮性之間的折衷。例如，通過探索更多路徑并增加分析時間，很容易調整本文的方法以涵蓋該方法。盡管如此，由于大多數智能合約并不太復雜，因此在實驗過程中很少見到這種例外情況。
數據集：考慮了從2018年6月9日（EOS MainNet的最開始）到2019年11月15日的所有53,666份智能合約（包括歷史版本）。請注意，與以太坊智能合約一旦部署便無法修改的不同，EOSIO合約可以按照前文中的說明更新并綁定相同的帳戶。因此使用EOSIO帳戶來標記每個唯一的智能合約，即一個帳戶可能對應于多個合約版本。結果有53,666個不同版本的合約，它們屬于5,574個EOSIO帳戶。由于回滾漏洞僅與游戲DApp有關，因此可以在此處縮小候選列表。使用DAppTotal-一種可靠的多平臺DApp瀏覽器來標記游戲DApp，并使用此類合約（17,394）進行回滾漏洞檢測。對于其他三種漏洞，將掃描器應用于所有53,666個合約（請參見下表）。
上表顯示了總體結果。令人驚訝的是，在53,666個智能合約中，有25％以上是易受攻擊的（請參閱第3列）。缺少權限檢查漏洞是最普遍的漏洞，影響了超過15％的智能合約。偽造的收據漏洞也很普遍（13％）。對于回滾漏洞，盡管僅分析了游戲DApp的17,000個智能合約，但其中有1000多個易受攻擊。偽造的EOS漏洞影響大約2.7％的智能合約。這表明EOSIO智能合約生態系統中普遍存在安全漏洞，這表明識別和防止此類漏洞的緊迫性。
存在漏洞的唯一智能合約：由于一個智能合約可能對應多個版本，因此從唯一合約（帳戶）的角度進一步描述漏洞的分布。如上表的第5列所示，對于5,574個唯一合約，大約有一半具有至少一個易受攻擊的版本。 10％的唯一智能合約占易受攻擊版本的61.24％，這表明大多數易受攻擊的版本是由一小部分智能合約導入的。此外，有1,793個唯一智能合約，它們的版本都容易受到攻擊（其中41％的版本至少具有兩個版本）。合同eossanguoone是一種流行的游戲DApp，具有最多易受攻擊的版本（356個版本）。通過手動檢查，發現2019年9月4日之前發布的所有版本都遭受了虛假收據漏洞，然后該漏洞由開發人員修補。自2019年8月以來，已發現缺少權限檢查漏洞，這可能是由于未經授權就導入了新函數所致。
當分析了不同版本的漏洞的演變時，因此有必要進一步研究修復每個唯一智能合約的漏洞的時間，這些時間可用于衡量攻擊者利用這些漏洞的窗口期。
結果：如上表所示，截至本研究，對于具有漏洞版本的2759個唯一智能合約，其中超過75％的最新版本仍至少存在一個安全漏洞。 679個唯一的智能合約在其演變過程中修補了所有漏洞，平均窗口期為16.84天。
補丁率：進一步分析漏洞的補丁率。回滾漏洞的補丁程序率最高（超過66％），平均窗口期約為4天。其及時響應的原因可能是回滾漏洞僅存在于游戲DApp中，這些DApp通常在其帳戶中具有較高的余額。如果開發人員不理會該漏洞，則財務損失可能是災難性的。對于缺少的權限檢查，有349個智能合約對其所有缺少的檢查操作進行了修補。請注意，在此處測量了操作級別的平均補丁時間，因為一個易受攻擊的合約可能有多個缺少權限檢查操作。總共有647個補丁操作，其中大約500個補丁補丁在一天之內被修復，而總補丁時間為4.38天。這表明大多數丟失的權限檢查操作都會得到及時修補，而少數合約則需要相對較長的時間才能解決。相反，虛假EOS和虛假收據漏洞具有最低的補丁率（即大約20％），并且補丁時間相對較長（即平均2到3周）。手動檢查發現，與虛假收據相關的智能合約中有一半是在24小時內修補的，這進一步表明一些不活躍的智能合約拖延了平均修補時間。大多數不活動的智能合約（帳戶）沒有余額，交易很少，通常不是攻擊者的目標。
（1）方法
探索攻擊者成功利用了多少個易受攻擊的智能合約并不是一件容易的事。直到最近，安全研究人員仍需要大量臨時工作（通常是手動工作）來進行驗證。因此，在存在易受攻擊的智能合約的情況下，首先收集其所有相關的鏈上交易，然后設計一套啟發式方法來定位可疑攻擊，這將用于促進進一步的手動驗證以確定實際攻擊。總計，已經收集了超過25億筆交易記錄。
虛假EOS攻擊：此攻擊的最重要行為是通過使用偽造的EOS token從易受攻擊的智能合約中欺騙官方EOS token，可以通過存儲token發行者信息的交易記錄來識別這些偽造的EOS token。根據觀察，將首先過濾掉所有token符號為“ EOS”的token轉移交易。然后，將根據以下定義對這些交易進行分組：
?發送偽造的EOS token的偽造交易；
?發送真實EOS token的真實發送交易；
?接收真實EOS token的真實接收交易。
結果，可以將潛在的攻擊定義為假冒發送交易之后是真實接收交易的序列。請注意，假冒發送交易A可以與真實接收交易B合并，前提是且僅當它們出現在同一時期，而A發生在B之前。對于所有這些潛在交易，主要關注那些獲得了更多收益的交易。真正的EOS代幣所花費的金額為此，進一步檢查了攻擊者與易受攻擊的合約之間的投入產出比，以確定可疑的攻擊。最后，基于可疑攻擊，將在收到偽造的EOS令牌后驗證易受攻擊的智能合約是否將恢復正常執行（例如，為真實玩家開獎）。如果是這樣，會將可疑交易標記為偽造的EOS攻擊。
虛假收據攻擊：攻擊的主要特征是易受攻擊的智能合約被虛假通知誤導以接收token，而實際的token轉移發生在屬于同一攻擊者的兩個帳戶之間。為簡單起見，下面將使用from_account和to_account表示這兩個帳戶，其中to_account將偽造的收據發送給易受攻擊的合約，而from_account是最終的受益人。
因此，將首先查詢其token由eosio.token發行且token符號為“ EOS”的所有token轉移交易，以獲取所有真實的EOS token轉讓。然后，將篩選出既不是eosio.token也不是from_account或to_account的接收者的交易。這些交易將被視為帶有虛假通知的偽造收據。接下來，如果from_account在從易受攻擊的合約獲利之前發送了虛假收據，會將相應的交易標記為潛在交易。之后，通過消除無關的EOS支出交易（例如，出于攻擊者發起的測試目的），主要關注那些獲得了比其花費更多的真實EOS代幣的人。如果投入產出比仍然很高，則將相應的交易標記為可疑。最后將手動檢查可疑交易，在收到虛假收據后，易受攻擊的智能合約是否將恢復正常執行。如果是這樣，會將此類交易標記為偽造的收據攻擊。
回滾攻擊：此攻擊的事務由動作的順序調用組成，可以用作識別攻擊的模式。具體來說，將首先篩選出至少包含四個動作作為潛在交易的所有交易。接下來，將選擇可滿足以下四個條件的可疑交易：（1）必須在同一合約中調用第一個和最后一個動作，第一個動作是發起攻擊的手段，最后一個動作將決定是否發起攻擊。從易受攻擊的智能合約中獲得獎勵后，必須進行回滾。 （2）中間的兩個動作必須是通過eosio.token進行的token轉移，兩個動作的發送者和接收者（必須是易受攻擊的智能合約）彼此相對。 （3）交易方中的至少一個，即發送者或接收者，被標記為游戲DApp。 （4）從易受攻擊的智能合約轉移的代幣數量超過其收到的數量。此外，值得注意的是，回滾的事務將不會記錄在鏈上。因此，必須手動檢查玩家每單位時間的成功率，即如果該成功率比其他人高，會將可疑交易標記為回滾攻擊。
缺少權限檢查攻擊：由于授權信息與調用的事務一起存在，因此可以檢查它是否屬于被調用方合約以識別此攻擊。更準確地說，將首先篩選出所有目標操作為易受攻擊操作的交易，以獲取可疑交易。然后，如果交易的權限不屬于該操作所屬的智能合約，會將其標記為缺少權限檢查攻擊。
總體結果如上表所示。總共確定了48個攻擊，包括9個虛假EOS攻擊，27個虛假收據攻擊和12個回滾攻擊。此外，還確定了183個未執行權限檢查的調用操作（屬于144個合約）。請注意，對于這些缺少權限檢查的操作，其中一些是有意設計的，而不是意外的實現。很難區分它們是否是攻擊，并且無法估計經濟損失。因此將其視為濫用行為，而不是攻擊。
攻擊影響：識別出的48種攻擊導致EOS損失超過341K，按攻擊日期的收盤價計算，大約相當于170萬美元。請注意，已經與一家領先的區塊鏈安全公司合作，向DApp開發人員報告了這些攻擊，其中27起已得到確認，占總損失的99％以上。所有未確認的可疑攻擊事件僅與少數EOS有關，并且大多數不再活躍。上表列出了前5大已確認的攻擊事件。
未被漏洞利用的合約：有趣的是，盡管成千上萬個合約易受攻擊，但攻擊者僅成功利用了其中的幾個合約。手動采樣了一些智能合約以進行逆向工程并檢查其交易，發現主要原因有兩個。首先，流行的智能合約（具有高余額）是攻擊者的主要目標，但是這些易受攻擊的合約可以及時修補，并且為攻擊者留出了很短的窗口期。根據交易發現攻擊者一直在嘗試利用流行的合約，并且某些攻擊確實是成功的（請參見上表），而大多數攻擊都失敗了。第二，正如前文中提到的那樣，考慮到低利潤和攻擊成本之間的折衷，大多數未打補丁的智能合約都是余額較低的非活動智能合約，因此吸引了攻擊者較少的注意力。
0x08 Threats to Validity
首先，本文系統繼承了符號執行的局限性，即路徑爆炸。盡管已經實施了幾種優化策略，但是EOSAFE仍然報告錯誤否定情況。但是，這對于系統來說不是一個大問題。一方面，大多數智能合約不像其他軟件那樣復雜。可以在短時間內全面分析大部分智能合約。另一方面，在搜索可以消除大多數不相關路徑的漏洞時，提出了特定的優化方法。盡管如此，可以利用先進的符號執行技術來緩解這一問題。其次，依靠試探法和半自動方法來驗證攻擊。當然，這可能無法擴展，這意味著本文僅提供了較低級別的攻擊的檢測。但是，確定的大部分攻擊已由DApp團隊確認，這表明本文方法相當可靠。不過，可以采用某些技術（例如動態測試）來幫助本文工具自動識別攻擊。在本文中主要貢獻是自動檢測安全漏洞，而攻擊驗證不是這項工作的主要重點。第三，可能存在一些當前版本中未涵蓋的新漏洞，以及其他軟件系統中的常規漏洞，例如緩沖區溢出。在本文中僅關注EOSIO特定的漏洞，主要原因是缺乏其他安全漏洞的真實性。盡管如此，將本文系統擴展為涵蓋其他漏洞很容易，因為符號執行引擎和掃描程序框架是通用的。
0x09 Conclusion
本文是首個有關檢測EOSIO智能合約中的安全漏洞工作。在文中提出了EOSAFE，這是一個準確且可擴展的框架，該框架能夠檢測EOSIO特定的漏洞。實驗結果表明，EOSAFE具有良好的性能。本研究的大規模評估研究進一步揭示了生態系統中的嚴重安全問題，即超過25％的智能合約易受攻擊，并且成功造成了許多著名攻擊事件。
來源：安全客