以太坊蜜罐智能合約分析_FUN

鏈聞ChainNews：

本文將對文章《Thephenomenonofsmartcontracthoneypots》和其評論中提到的smart-contract-honeypots和Solidlity-Vulnerable項目中的各蜜罐智能合約進行分析，根據分析結果將蜜罐智能合約的欺騙手段分為四個方面。

作者|DrAdrianManning

0x00前言

在學習區塊鏈相關知識的過程中，拜讀過一篇很好的文章《Thephenomenonofsmartcontracthoneypots》，作者詳細分析了他遇到的三種蜜罐智能合約，并將相關智能合約整理收集到Github項目smart-contract-honeypots。

本文將對文中和評論中提到的smart-contract-honeypots和Solidlity-Vulnerable項目中的各蜜罐智能合約進行分析，根據分析結果將蜜罐智能合約的欺騙手段分為以下四個方面：

古老的欺騙手段神奇的邏輯漏洞新穎的賭博游戲黑客的漏洞利用基于已知的欺騙手段，我們通過內部的以太坊智能合約審計系統一共尋找到118個蜜罐智能合約地址，一共騙取了34

只要轉賬金額大于1ether，就可以取走該智能合約里所有的以太幣。

但事實絕非如此，讓我們做出錯誤判斷的原因在于github在顯示超長行時不會自動換行。下圖是設置了自動換行的本地編輯器截圖：

圖中第21行和第29行就是蜜罐作者通過超長空格隱藏起來的代碼。所以實際的脆弱點是這樣的：

if(msg

先將賬戶余額轉給合約的創立者，然后再將剩余的賬戶余額轉給轉賬的用戶

與之類似的智能合約還有TestToken，留待有興趣的讀者繼續分析：

Github地址：smart-contract-honeypots/TestToken

}functionGetGift(bytespass)returns(bytes32){if(hashPass==sha3(pass)){msg

returnsha3(pass);}functionPassHasBeenSet(bytes32hash){if(hash==hashPass){passHasBeenSet=true;}}

}

整個智能合約的邏輯很簡單，三個關鍵函數功能如下：

距離以太坊Shapella升級已不到100個Epoch:金色財經報道，據Beaconcha最新數據顯示，目前距離以太坊Shapella升級已不到100個Epoch，本文撰寫時以太坊鏈上Epoch為19366（已確認Epoch 為193,964），距離Shapella升級還剩82個Epoch。此外，當前以太坊距離Shapella升級的還剩2605 Slot。[2023/4/12 14:00:05]

SetPass():在轉賬大于1ether并且passHasBeenSet為false(默認值就是false),就可以設置密碼hashPass。

GetGift():在輸入的密碼加密后與hashPass相等的情況下，就可以取走合約里所有的以太幣。

PassHasBeenSet()：如果輸入的hash與hashPass相等，則passHasBeenSet將會被設置成true。

如果我們想取走合約里所有的以太幣，只需要按照如下流程進行操作：

推特用戶AlexeyPertsev還為此寫了一個獲取禮物的EXP。

但實際場景中，受害者轉入一個以太幣后并沒有獲取到整個智能合約的余額，這是為什么呢？

這是因為在合約創立之后，任何人都可以對合約進行操作，包括合約的創建者：

合約創建者在合約被攻擊前，設置一個只有創建者知道的密碼并將passHasBeenSet置為True，將只有合約創建者可以取出智能合約中的以太幣。

與之類似的智能合約還有NEW_YEARS_GIFT：

Github地址：Solidlity-Vulnerable/honeypots/NEW_YEARS_GIFT

}

對于multiplicate()而言，只要你轉賬的金額大于賬戶余額，就可以把賬戶余額和你本次轉賬的金額都轉給一個可控的地址。

在這里我們需要知道：在調用multiplicate()時，賬戶余額=之前的賬戶余額本次轉賬的金額。所以msg

modifieronlyOwner{if(msg

}

contractTestBankisOwned{addresspublicowner=msg

functionwithdraw(uintamount)publiconlyOwner{require(amount<=this

距以太坊合并還剩3000個區塊，剩余時間不到12個小時:金色財經報道，最新數據顯示，當前距離以太坊合并還剩3,000個區塊，預計剩余時間為11小時55分鐘。[2022/9/15 6:56:36]

根據關鍵代碼的內容，如果我們可以通過useEmergencyCode()中的判斷，那就可以將owner設置為我們的地址，然后通過withdraw()函數就可以取出合約中的以太幣。

如果你也有了上述的分析，那么就需要學習一下Solidity中繼承的相關知識參考鏈接5：

該部分引用自參考鏈接5重點：Solidity的繼承原理是代碼拷貝，因此換句話說，繼承的寫法總是能夠寫成一個單獨的合約。情況五：子類父類有相同名字的變量。父類A的test1操縱父類中的variable，子類B中的test2操縱子類中的variable，父類中的test2因為沒被調用所以不存在。解釋：對EVM來說，每個storagevariable都會有一個唯一標識的slotid。在下面的例子說，雖然都叫做variable，但是從bytecode角度來看，他們是由不同的slotid來確定的，因此也和變量叫什么沒有關系。*contractA{uintvariable=0;functiontest1(uinta)returns(uint){variable;returnvariable;}functiontest2(uinta)returns(uint){variable=a;returnvariable;}}contractBisA{uintvariable=0;functiontest2(uinta)returns(uint){variable;returnvariable;}}====================contractB{uintvariable1=0;uintvariable2=0;functiontest1(uinta)returns(uintv){variable1;returnvariable1;}functiontest2(uinta)returns(uintv){variable2;returnvariable2;}}

根據樣例中的代碼，我們將該合約的核心代碼修改如下：

contractTestBankisOwned{addresspublicowner1=msg

addresspublicowner2=msg

functionwithdraw(uintamount)publiconlyOwner{require(amount<=this

以太坊錢包 Rainbow 上線 NFT 隱藏功能:金色財經消息，以太坊錢包 Rainbow 宣布上線 NFT 隱藏功能，為用戶提供隱藏 NFT 的選項。[2022/8/29 12:54:45]

變量owner1是父類Owner中的owner變量，而owner2是子類TestBank中的變量。useEmergencyCode()函數只會修改owner2，而非owner1，自然無法調用withdraw()。由于調用useEmergencyCode()時需要轉作者設置的evaluewei的以太幣，所以只會造成以太幣白白丟失。

0x03新穎的賭博游戲

區塊鏈的去中心化給行業帶來了新的機遇，然而久賭必輸這句話也不無道理。本章將會給介紹四個基于區塊鏈的賭博游戲并分析莊家如何贏錢的。*

3

functionshuffle()internal{//randomlysetsecretNumberwithavaluebetween1and20secretNumber=uint8(sha3(now,block

functionplay(uint256number)payablepublic{require(msg

shuffle();lastPlayed=now;}functionkill()public{if(msg

}

}

該合約設置了一個1-20的隨機數：secretNumber,玩家通過調用play()去嘗試競猜這個數字，如果猜對，就可以取走合約中所有的錢并重新設置隨機數secretNumber。

這里存在兩層貓膩。第一層貓膩就出在這個play()。play()需要滿足兩個條件才會運行：

msg

addressowner;//addressoftheowneruintprivatesecretSeed;//seedusedtocalculatenumberofanaddressuintprivatelastReseed;//lastreseed-usedtoautomaticallyreseedthecontractevery1000blocksuintLuckyNumber=1;//ifthenumberofanaddressequals1,itwinsfunctionforceReseed(){//reseedinitiatedbytheowner-fortestingpurposesrequire(msg

以太坊核心開發者正在制定ETH2.0合并技術規范:在3月11日的Eth2開發者電話會議上，以太坊基金會研究員及開發者Danny Ryan表示，其和以太坊2.0客戶端Teku的Mikhail Kalinin，正在探索創建一個可交付產品，以保存一些功能供以后使用。

Mikhail Kalinin提議推出一個“可執行的信標鏈”(2020年11月底提出），其將簡化最初設計的復雜性。Kalinin已在GitHub上發布請求，以讓開發者參與實現該提議。

與此同時，V神希望能加快Eth1和Eth2的合并進程。對此，Ryan表示，將在未來兩周內與項目利益相關者進行公開電話會議，討論資源分配問題。

此外，Danny Ryan表示正在與Mikhail Kalinin合作制定技術規范，以制定最小限度的合并。Ryan提醒稱，這可能會放棄一些主網特性，比如驗證器提款。當發布主要功能時，最好至少考慮升級的最簡單版本，以及從這里出發找出增強性能的潛在路徑。簡化會使網絡運輸更快和更安全。

注：驗證器提款指的是從網絡中提取資金。即延遲集成該功能將使用戶質押的ETH在以太坊2.0合約中至少再被鎖定三個月，具體時間取決于開發人員何時決定添加該功能。該功能最初定于第1.5階段（Eth1和Eth2的合并）時實現。（Decrypt）[2021/3/12 18:38:30]

functiontest()public{SeedComponentss;s

}

在運行test()之前，addr、b、c、d的值如下圖所示：

在運行了test()之后，各值均被覆蓋。

這個bug已經被提交給官方，并將在Solidity0

functionTest(){owner=msg

functionfake_foo(uint256n)public{Seeds;s

}

如圖所示，攻擊者0x583031d1113ad414f02576bd6afabfb302140225在調用fake_foo()之后，成功將owner修改成自己。

在2

}

contractTestisOwner{structSeed{addressx;}

functionTest(){owner=msg

functionfake_foo()public{Seeds;s

}

Peer Mountain宣布已加入企業以太坊聯盟:據bitcoinist消息，將自主主權ID持有者與企業連接起來的跨區塊鏈協議Peer Mountain宣布已加入企業以太坊聯盟（EEA）。[2018/6/5]

相比于示例代碼1，示例代碼2更容易出現在現實生活中。由于示例代碼2配合復雜的邏輯隱蔽性較高，更容易被不良合約發布者利用。比如利用這種特性留后門。

在參考鏈接10中，開發者認為由于某些原因，讓編譯器通過警告的方式通知用戶更合適。所以在目前0

modifieronlyOwner{if(msg

}

contractKingOfTheHillisOwned{addresspublicowner;

function()publicpayable{if(msg

jackpot=msg

functiontakeAll()publiconlyOwner{require(block

}

這個合約的邏輯是：每次請求fallback()，變量jackopt就是加上本次傳入的金額。如果你傳入的金額大于之前的jackopt，那么owner就會變成你的地址。

看到這個代碼邏輯，你是否感覺和2

require(msg

}function()publicpayable{race();}

}

這個智能合約有趣的地方在于它設置了最大轉賬上限是50finney，最小轉賬下限是2wei(條件是大于1wei，也就是最小2wei)。每次轉賬之后，最大轉賬上限都會縮小成原來的一半，當總轉賬數量大于等于100finney，那就可以取出莊家在初始化智能合約時放進的錢。

假設我們轉賬了x次，那我們最多可以轉的金額如下：

5050(1/2)^150(1/2)^250(1/2)^3.....

}

}

了解過DAO事件以及重入漏洞可以很明顯地看出，CashOut()存在重入漏洞。

在了解重入漏洞之前，讓我們先了解三個知識點：

Solidity的代碼執行限制。為了防止以太坊網絡被攻擊或濫用，智能合約執行的每一步都需要消耗gas，俗稱燃料。如果燃料消耗完了但合約沒有執行完成，合約狀態會回滾。addr

functionsetVictim(addresstarget){victim=target;}functionstep1(uint256amount)payable{if(this

}functionstep2(uint256amount){victim

//selfdestruct,sendallbalancetoownerfunctionstopAttack(){selfdestruct(owner);}functionstartAttack(uint256amount){step1(amount);step2(amount/2);}function()payable{victim

}

模擬的攻擊步驟如下：

正常用戶A向該合約存入50ether。

惡意攻擊者B(地址：0x583031d1113ad414f02576bd6afabfb302140225)新建惡意智能合約Attack，實施攻擊。不僅取出了自己存入的10ether，還取出了A存入的50ether。用戶A的余額還是50ether，而惡意攻擊者B的余額也因為發生溢出變成115792089237316195423570985008687907853269984665640564039407584007913129639936。

雖然此時用戶A的余額仍然存在，但由于合約中已經沒有以太幣了，所以A將無法取出其存入的50個以太幣

根據以上的案例可以得出如下結論：當普通用戶將以太幣存取該蜜罐智能合約地址，他的代幣將會被惡意攻擊者通過重入攻擊取出，雖然他依舊能查到在該智能合約中存入的代幣數量，但將無法取出相應的代幣。

4

}

}

邏輯看起去很簡單，只要在調用withdrawal()時發送超過1ether，該合約就會把余額全部轉給發送者。至于通過delegatecall()調用的logEvent()，誰在意呢？

在DASPTOP10的漏洞中，排名第二的就是訪問控制漏洞，其中就說到delegatecall()。

delegatecall()和call()功能類似，區別僅在于delegatecall()僅使用給定地址的代碼，其它信息則使用當前合約(如存儲，余額等等)。這也就意味著調用的logEvent()也可以修改該合約中的參數，包括adr。

舉個例子，在第一個合約中，我們定義了一個變量adr，在第二個合約中通過delegatecall()調用第一個合約中的logEvent()。第二個合約中的第一個變量就變成了0x1111。這也就意味著攻擊者完全有能力在logEvent()里面修改adr的值。

為了驗證我們的猜測，使用evmdis逆向0x25df6e3da49f41ef5b99e139c87abc12c3583d13地址處的opcode。logEvent()處的關鍵邏輯如下：

翻譯成Solidity的偽代碼大致是：

functionlogEvent(){if(storage==0x46FEEB381E90F7E30635B4F33CE3F6FA8EA6ED9B){storage=addressofcurrentcontract;}}

這也就意味著，在調用蜜罐智能合約firstTest中的withdrawal()時，emails

functiondivest(uintamount)public{if(investors

該智能合約大致有存錢、計算利息、取錢等操作。在最開始的分析中，筆者并未在整個合約中找到任何存在漏洞、不正常的地方，使用Remix模擬也沒有出現任何問題，一度懷疑該合約是否真的是蜜罐。直到打開了智能合約地址對應的頁面：

在Solidity0

functiondivest()public{this

}

在Remix中將編譯器版本修改為0.4.11commit.68ef5810.Emscripten.clang后，執行divest()函數結果如下：

在這個智能合約中也是如此。當我們需要調用divest()取出我們存進去的錢，最終將會調用this.loggedTransfer(amount,"",msg.sender,owner);。

因為編譯器的bug，最終調用的是this.loggedTransfer(amount,msg.sender,owner);，具體的轉賬函數處就是owner.call.value(amount)。成功的將原本要轉給msg.sender()的以太幣轉給合約的擁有者。合約擁有者成功盜幣！

0x05后記

在分析過程中，我愈發認識到這些蜜罐智能合約與原始的蜜罐概念是有一定差別的。相較于蜜罐是誘導攻擊者進行攻擊，智能合約蜜罐的目的變成了誘導別人轉賬到合約地址。在欺騙手法上，也有了更多的方式,部分方式具有強烈的參考價值，值得學習。

這些蜜罐智能合約的目的性更強，顯著區別與普通的釣魚行為。相較于釣魚行為面向大眾，蜜罐智能合約主要面向的是智能合約開發者、智能合約代碼審計人員或擁有一定技術背景的黑客。因為蜜罐智能合約門檻更高，需要能夠看懂智能合約才可能會上當，非常有針對性，所以使用「蜜罐」這個詞，我認為是非常貼切的。

這也對智能合約代碼審計人員提出了更高的要求，不能只看懂代碼，要了解代碼潛在的邏輯和威脅、了解外部可能的影響面，才能知其然也知其所以然。

對于智能合約代碼開發者來說，先知攻才能在代碼寫出前就擁有一定的警惕心理，從源頭上減少存在漏洞的代碼。

目前智能合約正處于新生階段，流行的solidity語言也還沒有發布正式1.0版本，很多語?的特性還需要發掘和完善；同時，區塊鏈的相關業務也暫時沒有出現完善的流水線操作。正因如此，在當前這個階段智能合約代碼審計更是相當的重要，合約的部署一定要經過嚴格的代碼審計。

最后感謝404實驗室的每一位小伙伴，分析過程中的無數次溝通交流，讓這篇文章羽翼漸豐。

更多精彩內容，關注鏈聞ChainNews公眾號，或者來微博@鏈聞ChainNews與我們互動！轉載請注明版權和原文鏈接！

來源鏈接：blog.sigmaprime.io

本文來源于非小號媒體平臺：

鏈聞研究院

現已在非小號資訊平臺發布1篇作品，

非小號開放平臺歡迎幣圈作者入駐

入駐指南：

/apply_guide/

本文網址：

/news/3630315.html

以太坊ETH

免責聲明：

1.資訊內容不構成投資建議，投資者應獨立決策并自行承擔風險

2.本文版權歸屬原作所有，僅代表作者本人觀點，不代表非小號的觀點或立場

上一篇：

細節！EOS抵押漏洞分析

Tags：CTINEROWNFUNCOLLECTIVENext Generation NetworkiOWN TokenButterfly Fund 11

幣贏交易所