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

鏈聞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;}}

}

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

數據：10.54萬枚ETH在近一周被質押至以太坊2.0合約:據歐科云鏈鏈上大師數據顯示，當前以太坊2.0存款合約地址已收到658.86萬ETH，占以太坊供應量的5.64%，近一周新增質押105440 ETH，新增質押量環比增長62.71%。近一周驗證人收入7838 ETH，環比增長0.32%。[2021/8/9 1:43:15]

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

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

Compound治理提案010：將每個以太坊區塊“產出”的COMP由0.5個下調至0.44個:社區已向去中心化借貸協議Compound的治理模塊中提交治理提案010，該提案共有兩個內容：

1. 調整COMP產出速度，從每個以太坊區塊轉出0.5 COMP降至轉出0.44 COMP。COMP的分發計劃中，每個以太坊區塊都會轉出0.5個COMP（也就是每天約2880個 COMP），但這一計劃是根據以太坊網絡上15秒的期望出塊時間制定的，而當前以太坊網絡的出塊速度為13.1秒，這就導致每天產出的COMP遠高于2880個，約為3297個。通過將每個區塊轉出的COMP下調至0.44個，可以將每日COMP的產出控制在原計劃的2880個左右。

2. 將抵押BAT、REP、ZRX借出其他資產的系數由10%提高至50%。如果該投票通過，用戶可將BAT、REP、ZRX作為抵押物借出其價值最多50%的其他資產。[2020/6/23]

如果你也有了上述的分析，那么就需要學習一下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;}}

V神：以太坊供應量比原先預期少4000萬:金色財經報道，V神（Vitalik Buterin）今天在推特上表示，以太坊供應量比原始白皮書中估計的要少4000萬。他認為，這駁斥了以太坊是由通貨膨脹主義技術官僚統治的理論。[2020/6/18]

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

contractTestBankisOwned{addresspublicowner1=msg

addresspublicowner2=msg

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

變量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

研究：以太坊基于帳戶的模式使其比其他協議更容易受到監視:匈牙利羅蘭大學一份研究論文認為，以太坊基于帳戶的模式使其比其他協議更容易受到監視。

論文指出，“一些粗心的用戶很容易暴露存款和取款之間的聯系，這樣也會影響其他用戶的匿名性，因為如果存款可以與取款掛鉤，它將不再屬于匿名集。而缺乏財務隱私對大多數加密貨幣用例都是有害的。”（Coindesk）[2020/6/4]

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

}

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

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

modifieronlyOwner{if(msg

}

contractKingOfTheHillisOwned{addresspublicowner;

function()publicpayable{if(msg

jackpot=msg

functiontakeAll()publiconlyOwner{require(block

}

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

動態 | 以太坊開發者提出“可逆ICO”:據coindesk報道，周二在位于布拉格的以太坊年度開發者大會Devcon4上，開發人員Fabian Vogelsteller提出了“可逆ICO”或RICO概念，允許代幣投資者在該項目生命周期的任何階段收回他們的資金，旨在使投資方案對潛在投資者更安全。具體而言，該概念涉及創建一種特殊用途的智能合約，允許投資者“扭轉其資金承諾”。[2018/10/31]

看到這個代碼邏輯，你是否感覺和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：CTINEROWNFUNData TransactionNero TokenTown StarFUND幣

Polygon