MIT:智能合約安全審計入門篇 —— 搶跑_OMMI

背景概述

在上篇文章中我們了解了合約中隱藏的惡意代碼，本次我們來了解一個非常常見的攻擊手法——搶跑。

前置知識

提到搶跑，大家第一時間想到的一定是田徑比賽，在田徑運動中各個選手的體能素質幾乎相同，起步越早的人得到第一名的概率越大。那么在以太坊中是如何搶跑的呢？

想了解搶跑攻擊必須先了解以太坊的交易流程，我們通過下面這個發送交易的流程圖來了解以太坊上一筆交易發出后經歷的流程：

可以看到圖中一筆交易從簽名到被打包一共會經歷7個階段：

1.使用私鑰對交易內容簽名；

2.選擇GasPrice；

3.發送簽名后的交易；

4.交易在各個節點之間廣播；

5.交易進入交易池；

6.礦工取出GasPrice高的交易；

7.礦工打包交易并出塊。

交易送出之后會被丟進交易池里，等待被礦工打包。礦工從交易池中取出交易進行打包與出塊。根據Eherscan?的數據，目前區塊的Gas限制在3000萬左右這是一個動態調整的值。若以一筆基礎交易21,000Gas來計算，則目前一個以太坊區塊可以容納約1428筆交易。因此當交易池里的交易量大時，會有許多交易沒辦法即時被打包而滯留在池子中等待。這里就衍生出了一個問題，交易池中有那么多筆交易，礦工先打包誰的交易呢？

礦工節點可以自行設置參數，不過大多數礦工都是按照手續費的多少排序。手續費高的會被優先打包出塊，手續費低的則需要等前面手續費高的交易全部被打包完才能被打包。當然進入交易池中的交易是源源不斷的，不管交易進入交易池時間的先后，手續費高的永遠會被優先打包，手續費過低的可能永遠都不會被打包。

那么手續費是怎么來的呢？

我們先看以太坊手續費計算公式：

zkSync發布新的支持智能合約驗證的插件:金色財經報道，基于ZK Rollup的以太坊二層網絡zkSync宣布發布了一個新的支持智能合約驗證的插件。hardhat-zksync-verify插件允許開發人員從終端和編程方式驗證部署在 zkSync 2.0 上的智能合約。[2023/1/4 9:50:49]

TxFee＝GasUsed*?GasPrice

其中GasUsed是由系統計算得出的，GasPrice是可以自定義的，所以最終手續費的多少取決于GasPrice設置的多少。

舉個例子：

例如GasPrice設置為10GWEI，GasUsed?為21,000。因此，根據手續費計算公式可以算出手續費為：

10GWEI*21,000=0.00021Ether

在合約中我們常見到Call函數會設置GasLimit，下面我們來看看它是什么東西：

GasLimit可以從字面意思理解，就是Gas限制的意思，設置它是為了表示你愿意花多少數量的Gas在這筆交易上。當交易涉及復雜的合約交互時，不太確定實際的GasUsed，可以設置GasLimit，被打包時只會收取實際GasUsed作為手續費，多給的Gas會退返回來，當然如果實際操作中GasUsed>GasLimit就會發生Outofgas，造成交易回滾。

當然，在實際交易中選擇一個合適的GasPrice也是有講究的，我們可以在ETHGASSTATION上看到實時的GasPrice對應的打包速度：

由上圖可見，當前最快的打包速度對應的GasPrice為2，我們只需要在發送交易時將GasPrice設置為>=2的值就可以被盡快打包。

好了，到這里相信大家已經可以大致猜出搶跑的攻擊方式了，就是在發送交易時將GasPrice調高從而被礦工優先打包。下面我們還是通過一個合約代碼來帶大家了解搶跑是如何完成攻擊的。

波卡生態智能合約平臺Clover與BoringDAO達成戰略合作:1月28日消息，波卡生態智能合約平臺Clover Finance宣布與跨鏈協議BoringDAO達成戰略合作，雙方將共同探索波卡生態跨鏈資產在DeFi中的應用。BoringDAO是一個去中心化的資產橋，將助力Clover平臺DApp資產的多鏈高效流通，同時Clover作為波卡生態的智能合約平臺，將為BoringDAO提供便捷的基礎設施，助力BoringDAO接入波卡生態。[2021/1/28 14:14:41]

合約示例

//?SPDX-License-Identifier:?MITpragmasolidity^0.8.17;contractFindThisHash{??bytes32publicconstanthash=????0x564ccaf7594d66b1eaaea24fe01f0585bf52ee70852af4eac0cc4b04711cd0e2;??constructor()payable{}??functionsolve(stringmemorysolution)public{????require(hash==keccak256(abi.encodePacked(solution)),"Incorrectanswer");????(boolsent,)=msg.sender.call{value:10ether}("");????require(sent,"FailedtosendEther");??}}

攻擊分析

通過合約代碼可以看到?FindThisHash?合約的部署者給出了一個哈希值，任何人都可以通過solve()?提交答案，只要solution的哈希值與部署者的哈希值相同就可以得到10個以太的獎勵。我們這里排除部署者自己拿取獎勵的可能。

我們還是請出老朋友Eve看看他是如何使用搶跑攻擊拿走本該屬于Bob的獎勵的：

1.Alice使用10Ether部署FindThisHash合約；

2.Bob找到哈希值為目標哈希值的正確字符串；

小蜜蜂Bee智能合約已通過知道創宇安全審計:據官網消息，知道創宇近日已完成小蜜蜂Bee智能合約項目的安全審計服務。

據介紹，小蜜蜂Bee是基于波場底層打造的第二代DeFi協議。旨在改善上一代DeFi協議在交易速度、成本等方面，面臨的一些固有挑戰，突破較大規模 DeFi 應用的瓶頸。

小蜜蜂Bee將于2020年10月15日晚20:00開啟創世挖礦，目前小蜜蜂Bee已上線bitkeep錢包defi專欄推薦位，并已在Justswap開啟流通。小蜜蜂Bee無ICO、零預挖且零私募，社區高度自治。

?合約地址：TNUXHrnHFJ89cgT8kCLmxYCVj3PeEqyJ4C[2020/10/13]

3.Bob調用solve("Ethereum")并將Gas價格設置為15Gwei；

4.Eve正在監控交易池，等待有人提交正確的答案；

5.Eve看到Bob發送的交易，設置比Bob更高的GasPrice，調用solve("Ethereum")；

6.Eve的交易先于Bob的交易被礦工打包；

7.Eve贏得了10個以太幣的獎勵。

這里Eve的一系列操作就是標準的搶跑攻擊，我們這里就可以給以太坊中的搶跑下一個定義：搶跑就是通過設置更高的GasPrice來影響交易被打包的順序，從而完成攻擊。

那么這類攻擊該如何避免呢？

修復建議

在編寫合約時可以使用Commit-Reveal方案：

https://medium.com/swlh/exploring-commit-reveal-schemes-on-ethereum-c4ff5a777db8

SoliditybyExample中提供了下面這段修復代碼，我們來看看它是否可以完美地防御搶跑攻擊。

//SPDX-License-Identifier:MITpragmasolidity^0.8.17;import"github.com/OpenZeppelin/openzeppelin-contracts/blob/release-v4.5/contracts/utils/Strings.sol";contractSecuredFindThisHash{??//Structisusedtostorethecommitdetails??structCommit{????bytes32solutionHash;????uintcommitTime;????boolrevealed;??}??//Thehashthatisneededtobesolved??bytes32publichash=????0x564ccaf7594d66b1eaaea24fe01f0585bf52ee70852af4eac0cc4b04711cd0e2;??//Addressofthewinner??addresspublicwinner;??//Pricetoberewarded??uintpublicreward;??//Statusofgame??boolpublicended;??//Mappingtostorethecommitdetailswithaddress??mapping(address=>Commit)commits;??//Modifiertocheckifthegameisactive??modifiergameActive(){????require(!ended,"Alreadyended");????_;??}??constructor()payable{????reward=msg.value;??}??/*???Commitfunctiontostorethehashcalculatedusingkeccak256(addressinlowercase+solution+secret).???Userscanonlycommitonceandifthegameisactive.??*/??functioncommitSolution(bytes32_solutionHash)publicgameActive{????Commitstoragecommit=commits;????require(commit.commitTime==0,"Alreadycommitted");????commit.solutionHash=_solutionHash;????commit.commitTime=block.timestamp;????commit.revealed=false;??}??/*????Functiontogetthecommitdetails.Itreturnsatupleof(solutionHash,commitTime,revealStatus);?????UserscangetsolutiononlyifthegameisactiveandtheyhavecommittedasolutionHash??*/??functiongetMySolution()publicviewgameActivereturns(bytes32,uint,bool){????Commitstoragecommit=commits;????require(commit.commitTime!=0,"Notcommittedyet");????return(commit.solutionHash,commit.commitTime,commit.revealed);??}??/*????Functiontorevealthecommitandgetthereward.????UserscangetrevealsolutiononlyifthegameisactiveandtheyhavecommittedasolutionHashbeforethisblockandnotrevealedyet.????Itgeneratesankeccak256(msg.sender+solution+secret)andchecksitwiththepreviouslycommitedhash.?????Frontrunnerswillnotbeabletopassthischecksincethemsg.senderisdifferent.????Thentheactualsolutionischeckedusingkeccak256(solution),ifthesolutionmatches,thewinnerisdeclared,????thegameisendedandtherewardamountissenttothewinner.??*/??functionrevealSolution(????stringmemory_solution,????stringmemory_secret)publicgameActive{????Commitstoragecommit=commits;????require(commit.commitTime!=0,"Notcommittedyet");????require(commit.commitTime<block.timestamp,"Cannotrevealinthesameblock");????require(!commit.revealed,"Alreadycommitedandrevealed");????bytes32solutionHash=keccak256(??????abi.encodePacked(Strings.toHexString(msg.sender),_solution,_secret)????);????require(solutionHash==commit.solutionHash,"Hashdoesn'tmatch");????require(keccak256(abi.encodePacked(_solution))==hash,"Incorrectanswer");????winner=msg.sender;????ended=true;????(boolsent,)=payable(msg.sender).call{value:reward}("");????if(!sent){??????winner=address(0);??????ended=false;??????revert("Failedtosendether.");????}??}}

Hubble Chain 智能合約協議框架完成優化:哈勃公鏈（Hubble Chain）技術團隊宣布，基于Hubble Chain主網架構的智能合約協議框架，已經完成結構優化，合約代碼即將編寫完成。哈勃技術團隊負責人介紹，哈勃智能合約以數字化的形式寫入Hubble Chain主網中，由哈勃公鏈區塊鏈技術的特性保障存儲、讀取、執行整個過程的透明、可跟蹤，以及不可篡改。[2020/6/17]

首先可以看到修復代碼中使用了結構體Commit記錄玩家提交的信息，其中：

commit.solutionHash=_solutionHash=keccak256

commit.commitTime=block.timestamp

commit.revealed=false

下面我們看這個合約是如何運作的：

1.Alice使用十個以太部署SecuredFindThisHash合約；

2.Bob找到哈希值為目標哈希值的正確字符串；

3.Bob計算solutionHash=keccak256(Bob’sAddress+“Ethereum”+Bob’ssecret)；

4.Bob調用commitSolution(_solutionHash)，提交剛剛算出的solutionHash；

5.Bob在下個區塊調用revealSolution("Ethereum",Bob'ssecret)函數，傳入答案和自己設置的密碼，領取獎勵。

這里我們看下這個合約是如何避免搶跑的，首先在第四步的時候，Bob提交的是這三個值的哈希，所以沒有人知道Bob提交的內容到底是什么。這一步還記錄了提交的區塊時間并且在第五步的revealSolution()?中就先檢查了區塊時間，這是為了防止在同一個區塊開獎被搶跑，因為調用revealSolution()?時需要傳入明文答案。最后使用Bob輸入的答案和密碼驗證與之前提交的solutionHash哈希是否匹配，這一步是為了防止有人不走commitSolution()?直接去調用revealSolution()。驗證成功后，檢查答案是否正確，最后發放獎勵。

動態 | BM提交智能合約代碼 取消增發的4%獎勵:據IMEOS報道，11小時前，BM在EOS的智能合約代碼庫中提交了更新，添加了移除4%通脹的hash表，該更新將停止向eosio.savings賬戶發送增發的4%。在該版本變動中，BM表示：如果社區將來希望有這種通脹，它可以實現。但是現在它只是生產了大量的閑置EOS代幣，這是不必要的工作。

注：智能合約的升級需要超過15個BP投票同意，才可生效。[2018/8/8]

所以這個合約真的完美地防止了Eve抄答案嗎？

Ofcoursenot！

咋回事呢？我們看到在revealSolution()?中僅限制了commit.commitTime<block.timestamp?，所以假設Bob在第一個區塊提交了答案，在第二個區塊立馬調用revealSolution("Ethereum",Bob'ssecret)?并設置GasPrice=15Gwei?Eve，通過監控交易池拿到答案，拿到答案后他立即設置GasPrice=100Gwei，在第二個區塊中調用commitSolution()?，提交答案并構造多筆高GasPrice的交易，將第二個區塊填滿，從而將Bob提交的交易擠到第三個區塊中。在第三個區塊中以100Gwei的GasPrice調用revealSolution("Ethereum",Eve'ssecret)?，得到獎勵。

那么問題來了，如何才能有效地防止此類攻擊呢？

很簡單，只需要設置uint256revealSpan?值并在commitSolution()中檢查?require(commit.commitTime+revealSpan>=block.timestamp,"Cannotcommitinthisblock");，這樣就可以防止Eve抄答案的情況。但是在開獎的時候，還是無法防止提交過答案的人搶先領獎。

另外還有一點，本著代碼嚴謹性，修復代碼中的revealSolution()?函數執行完后并沒有將commit.revealed?設為True，雖然這并不會影響什么，但是在編寫代碼的時候還是建議養成良好的編碼習慣，執行完函數邏輯后將開關設置成正確的狀態。

Tags：MITCOMMMIOMMILimitSwapCOMP價格MMIT幣OMMI價格

波場