趙 輝 ，李 星 ，譚嘉誠 ，蓋珂珂

(1.河南大學(xué) 軟件學(xué)院，河南 開封475000；2.北京理工大學(xué) 網(wǎng)絡(luò)空間安全學(xué)院，北京100081)

0 引言

智能合約的概念最早由美國著名計算機(jī)學(xué)科學(xué)家SZABO N[1]提出，由于當(dāng)時技術(shù)發(fā)展和缺乏可信執(zhí)行環(huán)境等原因，智能合約并沒有得到良好的應(yīng)用。直到一個化名為中本聰?shù)膶W(xué)者提出了比特幣的概念[2]，其底層技術(shù)區(qū)塊鏈的興起重塑了智能合約，解決了之前技術(shù)不成熟和應(yīng)用場景缺失等問題。

區(qū)塊鏈具有去中心化、不可篡改等特性，為智能合約提供了一個解決信任問題的機(jī)制。相較于傳統(tǒng)的金融合同，智能合約有很多的優(yōu)點(diǎn)，智能合約執(zhí)行的過程不需要可信的第三方的參與，一旦滿足合約中的條件，相應(yīng)的條款將會被強(qiáng)制自動地執(zhí)行。智能合約降低了信任成本，并且將用戶使用合約的門檻降低?；谥悄芎霞s的區(qū)塊鏈技術(shù)廣泛應(yīng)用于金融[3]、能源[4]和物聯(lián)網(wǎng)[5]等領(lǐng)域。

隨著智能合約的迅速發(fā)展，智能合約復(fù)雜性不斷增加，面臨著許多不可忽視的安全問題，頻發(fā)的合約攻擊事件表明，智能合約的安全問題十分嚴(yán)重，智能合約漏洞的研究受到了廣泛的關(guān)注。

本文的主要貢獻(xiàn)：

(1)對2016 年以來發(fā)生的典型智能合約攻擊事件進(jìn)行了總結(jié)。

(2)對智能合約的常見漏洞進(jìn)行了總結(jié)，并詳細(xì)介紹其原理。

(3)對常見的安全分析工具進(jìn)行了介紹，并對各個分析工具進(jìn)行了比較。

本文首先對近年來發(fā)生的典型合約攻擊事件進(jìn)行了簡介和分析；接著詳細(xì)地分析了智能合約的安全漏洞；然后介紹了常見的安全分析工具；再對常見的分析工具進(jìn)行了詳細(xì)分析；最后對本文的工作進(jìn)行了總結(jié)。

1 智能合約的安全事件

隨著智能合約技術(shù)的快速發(fā)展，近年來智能合約的攻擊事件頻頻發(fā)生，本節(jié)著重介紹了近年來發(fā)生的典型合約攻擊事件。

2016 年6 月17 日The DAO[6]受到攻擊。主要由于splitDAO 函數(shù)中存在的漏洞，該函數(shù)先向用戶進(jìn)行了轉(zhuǎn)賬，之后才對用戶的余額等變量進(jìn)行了更新，同時轉(zhuǎn)賬調(diào)用了攻擊者的fallback 函數(shù)，產(chǎn)生了重入漏洞。The DAO 事件對以太坊[7]的發(fā)展產(chǎn)生巨大的影響，造成了以太坊的分叉，形成了兩條鏈：一條為ETC，另一條為ETH。

2017 年7 月19 日，Parity Multisig[8]電子錢包由于合約漏洞造成以太幣被竊取。該漏洞主要是由于Delegatecall 函數(shù)使用不當(dāng)造成的。攻擊者通過Delegatecall 函數(shù)調(diào)用了initWallet 函數(shù)，通過initWallet 函數(shù)調(diào)用initMultiowned 函數(shù)，由于initMultiowned 函數(shù)未作校驗(yàn)使得錢包初始化函數(shù)順利執(zhí)行，攻擊者成為了合約的擁有者，之后攻擊者調(diào)用execute 函數(shù)進(jìn)行轉(zhuǎn)賬。

2018 年4 月22 日，黑客對美鏈的智能合約進(jìn)行了整數(shù)溢出的攻擊，漏洞由batchTransfer 函數(shù)引起，該函數(shù)用于同時給多個人轉(zhuǎn)賬。由于沒有對溢出進(jìn)行檢測，攻擊者通過構(gòu)建較大的轉(zhuǎn)賬金額_value，導(dǎo)致轉(zhuǎn)出總金額amount 被溢出為0，轉(zhuǎn)賬方減去被溢出的amount，而接收方卻收到_value 金額的轉(zhuǎn)賬。攻擊者通過這種方法憑空產(chǎn)生了大量的代幣。

2019 年，EOSPlay 遭到了新型的隨機(jī)數(shù)攻擊，由于EOSPLay 采用未來區(qū)塊的哈希作為開獎的依據(jù)。攻擊者通過發(fā)送大量交易，達(dá)到預(yù)測未來區(qū)塊哈希的目的。

2020 年4 月，攻擊者對DeFi 平臺Uniswap 的智能合約實(shí)施可重入攻擊，該攻擊者利用遵守ERC777協(xié)議規(guī)定的代幣發(fā)生轉(zhuǎn)賬會調(diào)用代幣發(fā)送者的tokensToSend 函數(shù)實(shí)施攻擊。漏洞合約先向攻擊者進(jìn)行了轉(zhuǎn)賬ETH，其次才將代幣轉(zhuǎn)進(jìn)合約。代幣轉(zhuǎn)進(jìn)合約時調(diào)用攻擊者經(jīng)過惡意修改的tokensToSend函數(shù)從而再次調(diào)用漏洞合約。由于此時代幣未被轉(zhuǎn)進(jìn)合約，根據(jù)合約兌換比例公式，攻擊者可以獲取額外的利益。

2 智能合約的常見漏洞

近年來，頻發(fā)的合約攻擊事件對區(qū)塊鏈的生態(tài)帶來了巨大的損失，多數(shù)是由合約常見漏洞[9]引起的，本節(jié)對典型的合約漏洞進(jìn)行總結(jié)，并詳細(xì)介紹其原理。

2.1 重入漏洞

重入漏洞是智能合約的典型漏洞之一，引發(fā)了The DAO 事件。重入攻擊發(fā)生在轉(zhuǎn)賬操作，攻擊借助于fallback 函數(shù)的特性和足夠的gas。漏洞合約首先對用戶進(jìn)行了轉(zhuǎn)賬，之后才從用戶余額中減去金額。由于Solidity 語言的特性，轉(zhuǎn)賬操會調(diào)用fallback函數(shù)，攻擊者對fallback 函數(shù)進(jìn)行修改，再次調(diào)用漏洞合約的轉(zhuǎn)賬操作，此時合約未將余額從用戶地址中減去，在gas 耗盡之前，循環(huán)轉(zhuǎn)賬將不斷發(fā)生。

針對重入漏洞進(jìn)行說明，當(dāng)攻擊者調(diào)用漏洞合約的轉(zhuǎn)賬函數(shù)，漏洞合約將會向攻擊者進(jìn)行轉(zhuǎn)賬操作，進(jìn)而觸發(fā)攻擊合約的fallback 函數(shù)中的惡意代碼，攻擊者在其fallback 函數(shù)中再次惡意調(diào)用漏洞合約的轉(zhuǎn)賬函數(shù)，將會使漏洞合約重復(fù)轉(zhuǎn)賬，對其造成巨大的經(jīng)濟(jì)損失。預(yù)防重入漏洞可以使用限制gas數(shù)量的send 函數(shù)或transfer 函數(shù)代替call 函數(shù)進(jìn)行轉(zhuǎn)賬，對用戶余額的改變在轉(zhuǎn)賬之前進(jìn)行。原理如圖1 所示。

圖1 重入漏洞原理

2.2 Delegatecall 漏洞

Delegatecall 操作是一種特殊的消息調(diào)用，普通消息調(diào)用執(zhí)行之后，執(zhí)行環(huán)境會進(jìn)行改變，目標(biāo)代碼在被調(diào)用者的合約上下文中執(zhí)行。而Delegatecall 的特殊之處在于，執(zhí)行環(huán)境不進(jìn)行改變，目標(biāo)代碼是在調(diào)用者合約的上下文環(huán)境中執(zhí)行的,并且msg.sender和msg.value 的值依舊是調(diào)用者的值,調(diào)用棧同樣保持不變。

對Delegatecall 函數(shù)的濫用會導(dǎo)致嚴(yán)重的安全問題，如Delegatecall 調(diào)用的合約會直接對調(diào)用者的狀態(tài)變量進(jìn)行修改，從而引發(fā)不可預(yù)期的后果。使用Delegatecall 調(diào)用應(yīng)該謹(jǐn)慎，需要保證調(diào)用合約的可靠。

2.3 整數(shù)溢出

造成整數(shù)溢出的主要原因是由智能合約的編程語言Solidity 的整數(shù)類型導(dǎo)致的。在以太坊虛擬機(jī)中整數(shù)是無符號、固定大小的數(shù)據(jù)類型，因此整型變量在以太坊虛擬機(jī)中是具有一定的范圍的，如果超過了這個范圍就會出現(xiàn)錯誤，導(dǎo)致整數(shù)上溢或下溢。

針對整數(shù)溢出進(jìn)行說明，一個uint8 類型的變量，只能存儲的范圍是0 到255，如果將255 這個數(shù)字存儲在一個uint8 類型中，使其進(jìn)行加一操作，數(shù)字最終會變成0，這就是整數(shù)上溢，整數(shù)下溢與上溢的原理類似。原理如圖2 所示。

圖2 整數(shù)溢出原理

2.4 tx.origin 依賴漏洞

tx.origin 為Solidity 智能合約中的全局變量，通過回溯整個調(diào)用棧并返回原始發(fā)送者的賬戶地址。使用tx.origin 來檢測合約調(diào)用者可能會使合約變得脆弱。采用tx.origin 進(jìn)行授權(quán)，授權(quán)地址將會被存儲到tx.origin，對方可以使用fallback 函數(shù)調(diào)用合約并獲得授權(quán)。msg.sender 是當(dāng)前發(fā)生調(diào)用的賬戶或合約地址。在智能合約授權(quán)時應(yīng)盡量使用msg.sender代替tx.origin。

利用tx.origin 攻擊需要提前部署攻擊者合約，通過釣魚等手段使漏洞合約向攻擊者合約轉(zhuǎn)賬，達(dá)到調(diào)用攻擊者的fallback 函數(shù)和獲取tx.origin 值的目的。由于tx.origin 指向最初發(fā)起交易的地址，通過fallback 函數(shù)調(diào)用漏洞合約中以tx.origin 作為授權(quán)的轉(zhuǎn)賬函數(shù)，授權(quán)會獲得通過，攻擊者因此可以發(fā)起惡意轉(zhuǎn)賬操作。原理如圖3 所示。

圖3 tx.orgin 依賴漏洞原理

2.5 短地址攻擊

短地址攻擊主要出現(xiàn)在基于ERC20 類型的代幣合約中，在EVM 層面中，十六進(jìn)制的字節(jié)碼構(gòu)成了交易消息的輸入。該字節(jié)碼主要由三個部分組成，分別為方法名哈希值、交易目標(biāo)地址和轉(zhuǎn)賬金額，所占字節(jié)分別為4 個字節(jié)、32 個字節(jié)和32 個字節(jié)。

短地址的攻擊是指攻擊者首先通過構(gòu)造末尾為零的地址進(jìn)行合約調(diào)用，然后在調(diào)用參數(shù)中故意將地址末尾的零舍去，利用虛擬機(jī)在讀取合約調(diào)用輸入時，對長度不符合要求的字段自動進(jìn)行末尾補(bǔ)零的操作，從而造成參數(shù)的移位擴(kuò)大。

針對短地址攻擊進(jìn)行說明，假設(shè)一段68 個字節(jié)的字節(jié)碼為L：

2.6 訪問控制

智能合約中，如果沒有標(biāo)明函數(shù)的可見性，就不能做到充足的權(quán)限檢查，這就表明攻擊者可以訪問到不該訪問的函數(shù)和變量，并且可以進(jìn)行修改。

以Solidity 編程語言為例，在Solidity 中對函數(shù)有4 種可見性修飾分別為public、internal、private、external。如果用Solidity 來編寫智能合約時沒有指定可見性修飾符，那么函數(shù)默認(rèn)的可見性為public，則轉(zhuǎn)賬等重要函數(shù)就缺少訪問控制，攻擊者就可以從合約賬戶中提取以太幣。因此會產(chǎn)生訪問控制不當(dāng)?shù)穆┒?，造成用戶的損失。

3 安全分析工具

智能漏洞引發(fā)的安全事件造成巨大的損失，諸多工具被提出用于分析合約漏洞，LUU L[10]等較早關(guān)注合約安全提出了Oyente，基于Oyente 一些方法被提出，如TORRES C F[11]在Oyente 的基礎(chǔ)上關(guān)注整數(shù)相關(guān)的漏洞；TSANKOV P[12]等人提出了一種靜態(tài)分析框架Slither；FEIST J[13]等人提出了自動化的安全分析工具Securify；KALRA S 等人為了驗(yàn)證合約的公平性和正確性提出了Zeus；TIKHOMIROV S[14]提出SmartCheck。本節(jié)對這些安全分析工具進(jìn)行了介紹。

3.1 Oyente

Oyente 是基于符號執(zhí)行進(jìn)行漏洞檢測工具，以智能合約的字節(jié)碼和以太網(wǎng)全局狀態(tài)作為輸入，以合約存在的安全問題和有問題的符號路徑作為輸出，包括4 個核心組件：控制流生成器、探索器、分析器、驗(yàn)證器?？刂屏魃善魃晒羌芸刂屏鲌D；探索器會通過添加邊來完善控制流圖；分析器以探索器輸出的符號路徑為基礎(chǔ)，收集表現(xiàn)出不同以太流的路徑用以漏洞分析；驗(yàn)證器主要作用是消除漏洞檢測可能發(fā)生的誤報。

Oyente 是較早針對智能合約漏洞提出的檢測工具，能夠檢測嚴(yán)重的智能合約錯誤，但是仍然存在缺點(diǎn)。Oyente 會出現(xiàn)假陽性，不能為智能合約提供完全的保護(hù)。在識別合約自殺和濫用發(fā)送源等方面也是不成功的。

3.2 Secruify

Secruify 提出了符合模式和違反模式，通過這兩種模式來反映智能合約的安全屬性。該工具首先對EVM 字節(jié)碼進(jìn)行反編譯。隨后，Securify 分析智能合約以推斷語義事實(shí)，其中包括數(shù)據(jù)和控制流的依賴關(guān)系，因?yàn)樗鼈兛刂浦霞s的所有行為。在獲得語義事實(shí)之后，Securify 給出符合性和違反性安全模式，得出安全分析結(jié)果。Secruify 所有模式都是用特定于該領(lǐng)域的語言。

相比于Oyente，Securify 分析了所有的合約行為，從而避免了不必要的錯誤否定。然而，Secruify 也存在一些問題，首先它不能識別整數(shù)溢出，其次它沒有提供正式的語義或可靠性證明，因此會導(dǎo)致一些潛在的安全問題存在。

3.3 Slither

Slither 是一種靜態(tài)分析框架。其輸入為智能合約經(jīng)過編譯后得到的Solidity 抽象語法樹。首先，Slither 獲得合約繼承圖、控制流圖和表達(dá)式列表。其次，Slither 將合約的代碼轉(zhuǎn)換為SlithIR。在代碼分析階段，Slither 進(jìn)行預(yù)先定義的分析，包括變量依賴、變量的讀寫和函數(shù)的權(quán)限控制。最后，Slither 可以將處理過的信息輸入給漏洞檢測等第三方工具。

相比于Secruify，Slither 提高了準(zhǔn)確性，縮短了平均執(zhí)行時間，提高了魯棒性。然而由于Slither 缺乏形式語義，限制了它執(zhí)行更詳細(xì)的安全分析能力。Slither 的中間表示語言SlithIR 過于高級，無法準(zhǔn)確反映gas 計算等低級信息。

3.4 Zeus

Zeus 是驗(yàn)證智能合約正確性和公平性的形式化驗(yàn)證工具。Zeus 首先將Solidity 源代碼和借助策略生成器構(gòu)建的基于XACML 風(fēng)格模板的驗(yàn)證規(guī)則作為輸入。其次Zeus 從驗(yàn)證規(guī)則中提取斷言，根據(jù)驗(yàn)證規(guī)則將斷言插入合約代碼正確的位置。利用源代碼翻譯器將嵌入斷言語句的合約代碼轉(zhuǎn)為LLVM 中間語言表示。最后利用已有的驗(yàn)證工具，如SeaHorn[15]，進(jìn)行形式化驗(yàn)證。

Zeus 將Solidity 代碼轉(zhuǎn)為LLVM 中間語言，因此可以調(diào)用已有的工具作為驗(yàn)證器，但缺點(diǎn)是源代碼翻譯器不可能準(zhǔn)確表達(dá)合約代碼的所有語義。和Oyente 相比，Zeus 減少了誤報率并使驗(yàn)證時間縮短了一個數(shù)量級。但Zeus 在涉及數(shù)學(xué)方程屬性方面無法完全驗(yàn)證，只能依賴用戶來進(jìn)行測試。

3.5 SmartCheck

SmartCheck 是一種可擴(kuò)展的靜態(tài)分析工具，該工具首先在Solidity 源代碼執(zhí)行詞法和句法分析，將合約代碼轉(zhuǎn)變?yōu)?XML 形式的中間表示。SmartCheck 可以將合約代碼完全轉(zhuǎn)變?yōu)橹虚g表示，并且SmartCheck 為了更好的本地化分析結(jié)果，將代碼的行號也存儲進(jìn)XML。利用Xpath 進(jìn)行漏洞的檢測，SmartCheck 的Xpath 匹配支持所有元素，因而不會遺漏Solidity 特有的元素。

SmartCheck 有其局限性，Xpath 無法很好表達(dá)過于復(fù)雜的規(guī)則，對復(fù)雜漏洞的檢測容易導(dǎo)致誤報的產(chǎn)生，更側(cè)重于檢測簡單漏洞。

4 分析與比較

智能合約安全分析工具是智能合約安全方面的重要研究領(lǐng)域，安全分析工具采用的方法主要有靜態(tài)分析、符號執(zhí)行、形式化驗(yàn)證等方法，本節(jié)對靜態(tài)分析、符號執(zhí)行[16]、形式化驗(yàn)證[17]這三種方法進(jìn)行了介紹，對Zeus、Slither、Oyente、Securify 和SmartCheck進(jìn)行了比較，對每個安全分析工具適用的漏洞進(jìn)行了總結(jié)，并對安全分析工具所面臨的問題進(jìn)行了簡要的分析。

4.1 靜態(tài)分析

靜態(tài)分析可以在不執(zhí)行智能合約的情況下，通過對合約源代碼或編譯產(chǎn)生的中間語言的反匯編進(jìn)行分析，從而發(fā)現(xiàn)合約中的漏洞。靜態(tài)分析一般包括幾個階段。首先，靜態(tài)分析需要構(gòu)建中間表示(IR)。其次，利用控制流分析、污染分析等技術(shù)來豐富IR 的信息。最后，利用IR 構(gòu)建漏洞的分析。

Slither、SmartCheck 是典型的靜態(tài)分析工具，Zeus也借鑒了靜態(tài)分析方法。其中Slither 將Solidity 源代碼轉(zhuǎn)為SlithIR。SmartCheck 將合約代碼轉(zhuǎn)為XML 形式的中間表示，Zeus 將插入斷言的Solidity 代碼轉(zhuǎn)為LLVM 形式的中間語言。

4.2 符號執(zhí)行

符號執(zhí)行原理是將外部輸入抽象化為符號值，將智能合約中的程序抽象為執(zhí)行樹，然后根據(jù)外部輸入值和程序的語義，進(jìn)行遍歷執(zhí)行樹。符號執(zhí)行的主要思想是在程序執(zhí)行過程中將不確定的輸入轉(zhuǎn)化為符號值，推動程序的執(zhí)行。

與靜態(tài)分析相比，符號執(zhí)行對程序的分析更加全面和準(zhǔn)確。Oyente 屬于符號執(zhí)行工具，Oyente 中的控制流生成器會為智能合約建立控制流圖，探索器對智能合約進(jìn)行符號驗(yàn)證。

4.3 形式化驗(yàn)證

形式化驗(yàn)證用于驗(yàn)證程序和代碼的邏輯，通過對程序用邏輯或者描述性語言進(jìn)行描述，然后進(jìn)行數(shù)學(xué)推理與證明，確保程序能按照規(guī)范進(jìn)行工作。

Secruify 和Zeus 屬于形式化驗(yàn)證工具。Secruify體現(xiàn)形式化驗(yàn)證的是通過用Datalog 指定的推理規(guī)則導(dǎo)出語義事實(shí)，然后對語義事實(shí)進(jìn)行檢測。Zeus是首先用中間語言翻譯Solidity 代碼，并在翻譯過的代碼上運(yùn)用特定語言編寫的驗(yàn)證規(guī)則，最后借助于SeaHorn 來進(jìn)行形式化驗(yàn)證。

4.4 工具比較

Slither、Oyente、Secruify、SmartCheck 在GitHub 上發(fā)布了源代碼。在這幾個工具中只有Slither 可以檢測訪問控制漏洞，都不支持短地址攻擊漏洞。大多工具都對重入漏洞、tx.origin 漏洞、Delegatecall 漏洞進(jìn)行了檢測。本文介紹的常見漏洞中Slither、Security不支持整數(shù)溢出漏洞，Zues、SmartCheck 不支持Delegatecall 漏洞，Oyente 不支持tx.origin 漏洞。表1 為 部分工具對常見漏洞的支持比較。

表1 部分工具對常見漏洞的支持比較

當(dāng)前漏洞分析工具對常見漏洞的支持不夠完整，并且和手動審查相比，漏報率和誤報率偏高，普遍出現(xiàn)假陽性的情況。分析工具的準(zhǔn)確率較低，同時工具的可擴(kuò)展性較差，無法有效防御新出現(xiàn)的漏洞。今后對漏洞分析工具的研究主要集中于提高準(zhǔn)確率，降低漏報率和誤報率。

5 結(jié)論

智能合約提供了優(yōu)于傳統(tǒng)合約的安全方法，并減少交易成本。但是隨著智能合約的快速發(fā)展，智能合約安全問題越來越受到關(guān)注，各種安全分析工具被提出。本文對近年來由于合約漏洞造成的安全事件進(jìn)行了列舉，對合約漏洞進(jìn)行了基本分類，同時對常見漏洞進(jìn)行了介紹，并對當(dāng)前主流的安全分析工具進(jìn)行了概括。