“如果你在etherscan中找到一個0day(零日)漏洞,你會怎麼做?我決定構建一個'彈球機'。" ——paradigm研究合夥人samczsun

注:原文作者是samczsun。

我喜歡挑戰假設。

我喜歡嘗試做不可能的事情,找到別人錯過的東西,用他們從未見過的事來使他們震驚。去年的時候,我根據一個非常費解的Solidity漏洞為Paradigm CTF 2021 編寫了一個挑戰。雖然公開披露了一種變體,但我找到的漏洞從未真正被討論過。結果,幾乎所有嘗試過挑戰它的人,都被它看似不可能的性質所難倒。

幾週前,我們正在討論關於Paradigm CTF 2022的計劃,當時Georgios在推特上發布了一條難題推文,我認為在啟動電話會議的同一天發布一個挑戰會非常酷。然而,這不可能只是一次老掉牙的挑戰。我想從這個世界得到一些東西,一些沒有人會看到的東西,一些超越人們想像極限的東西。我想編寫第一個利用0day(零日)漏洞的以太坊CTF 挑戰。

1

如何製造0day(零日)漏洞

作為安全研究人員,為了優化我們的時間,我們會做出一些基本假設。一是我們正在閱讀的源代碼確實產生了我們正在分析的合約。當然,只有當我們從可信的地方讀取源代碼時,這種假設才成立,比如說Etherscan。因此,如果我能找到一種方法讓Etherscan錯誤地驗證某些東西,我就能夠圍繞它設計出一個真正迂迴的謎題。

為了找出如何利用Etherscan的合約驗證系統,我必須驗證一些合約。我在Ropsten測試網部署了一些合約來折騰並嘗試驗證它們。很快,我就看到了下面的界面。

我選擇了正確的設置並進入下一頁。在這裡,我被要求提供我的合約源代碼。

我輸入了源代碼並單擊了驗證按鈕,果然,我的源代碼現在附在了我的合約上。

既然我知道了事情是如何運作的,我就可以開始戲弄驗證過程了。我嘗試的第一件事是部署一個新的合約,將foo更改為bar,並用原始源代碼驗證該合約。毫不奇怪的是,Etherscan拒絕驗證我的合約。

然而,當我手動比較兩個字節碼輸出時,我注意到一些奇怪的事情。合約字節碼應該是十六進制的,但顯然有一些並非是十六進制的。

我知道Solidity會將合約元數據附加到部署的字節碼中,但我從未真正考慮過它是如何影響合約驗證的。顯然,Etherscan 正在掃描元數據的字節碼,然後用一個標記替換它,“這個區域中的任何東西都可以不同,我們仍然會認為它是相同的字節碼。”

對於潛在的0day(零日)漏洞,這似乎是一個很有希望的線索。如果我可以欺騙Etherscan 將非元數據解釋為元數據,那麼我將能夠在標記為{ipfs} 的區域中調整我部署的字節碼,同時仍然讓它驗證為合法的字節碼。

我能想到的在創建事務中包含一些任意字節碼的最簡單方法,是將它們編碼為構造函數參數。 Solidity 通過將ABI 編碼形式直接附加到創建交易數據上來對構造函數參數進行編碼。

然而,Etherscan太聰明了,它將構造函數參數排除在任何類型的元數據嗅探之外。你可以看到構造函數參數是斜體的,以表明它們與代碼本身是分開的。

這意味著我需要以某種方式欺騙Solidity 編譯器,使其發出我控制的字節序列,以便使其類似於嵌入的元數據。然而,這似乎是一個很難去解決的問題,因為如果沒有一些嚴重的編譯器爭論,我幾乎無法控制Solidity選擇使用的操作碼或字節,之後源代碼看起來會非常可疑。

我考慮了一會兒這個問題,直到我意識到:導致Solidity發出(幾乎)任意字節實際上是非常容易的。以下代碼將導致Solidity 發出32 個字節的0xAA。

bytes32 value = 0xaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa;

受到鼓舞,我很快寫了一個小合約,它將推送一系列常量,以便Solidity 會發出與嵌入的元數據完全相似的字節碼。

令我高興的是,Etherscan 在我的合約中間標記了IPFS 哈希的存在。

我快速復制了預期的字節碼,並用一些隨機字節替換了IPFS 哈希,然後部署了生成的合約。果然,Etherscan 像往常一樣考慮了不同的字節業務,並允許我的合約得到驗證。

有了這個合約,源代碼建議在調用example() 時應該返回一個簡單的字節對象。但是,如果你真的嘗試調用它,就會發生這種情況。

$ seth call 0x3cd2138cabfb03c8ed9687561a0ef5c9a153923f "example()"seth-rpc: {"id":1,"jsonrpc":"2.0","method":"eth_call","params":[{"data":"0x54353f2f", "to":"0x3CD2138CAbfB03c8eD9687561a0ef5C9a153923f"},"latest"]}seth-rpc: error: code -32000seth-rpc: error: message stack underflow (5 <=> 16)

我在Etherscan 中成功發現了一個0day(零日)漏洞,現在我可以驗證行為與源代碼建議完全不同的合約。而現在,我只需要圍繞它設計一個解密遊戲。

2

一個錯誤的開始

顯然,這個解密遊戲將圍繞這樣一個想法,即Etherscan 上看到的源代碼並不意味著合約的實際行為方式。我還想確保玩家不能簡單地直接重放交易,因此解決方案必須是每個地址唯一的。最好的方法顯然是要求籤名。

但是在什麼情況下會要求玩家簽署一些數據呢?我的第一個設計是一個具有單一公開函數的簡單puzzle。玩家將使用一些輸入調用該函數,對數據進行簽名以證明他們提出了解決方案,如果輸入通過了所有各種檢查,那麼他們將被標記為solver。然而,當我在接下來的幾個小時內充實這個設計時,我很快就對事情的結果感到不滿意了,它開始變得非常笨重和不優雅,我無法忍受在一個設計如此糟糕的puzzle上毀掉如此棒的0day(零日)漏洞想法。

不得不承認,我無法在周五前完成這件事,於是我決定睡一覺。

3

Pinball彈球難題

週末我繼續嘗試迭代我的初始設計,但沒有取得更多的進展。就好像我現在的方法碰壁了,儘管我不想承認,但我知道如果我想要我滿意的東西,我可能不得不重新開始。

最終,我發現自己從第一原理重新審視了這個問題。我想要的是一個解密遊戲,玩家必須在其中完成各種知識檢查。但是,我沒有要求完成知識檢查本身就是獲勝的條件,相反,這可能是允許玩家選擇的眾多路徑之一。也許玩家可以在整個puzzle中累積分數,利用這個漏洞可以獲得某種獎勵。贏的條件只是最高的分數,因此間接鼓勵使用漏洞。

我回想起我去年設計的一個挑戰,Lockbox‌,它迫使玩家構建一個單一的數據塊,以滿足六個不同合約的要求。合約會對相同的字節應用不同的約束,迫使玩家在構建有效載荷的方式上變得聰明。我意識到我想在這裡做一些類似的事情,我會要求玩家提交一個單一的數據blob,我會根據滿足特定要求的某些數據部分來獎勵分數。

正是在這一點上,我意識到我基本上是在描述pinboooll‌,這是我在DEFCON CTF 2020 決賽期間面臨的一個挑戰。 pinboooll 的噱頭是當你執行二進製文件時,執行會在控制流圖上反彈,就像一個球在彈球機中反彈一樣。通過正確構造輸入,你將能夠找到特定的代碼部分並獲得分數。當然,也有一個漏洞,但坦率地說,我已經忘記了它是什麼,我也不打算再去尋找它。除此之外,我已經有了自己想要利用的漏洞。

由於我在處理的是一個運行當中的零日漏洞,我決定要盡快解決這個難題。最後,我花了幾個小時讓自己重新認識pinboooll的工作原理,並花了幾天時間將其重新實現。這就解決了puzzle的支架問題,現在我只需要集成這個漏洞。

4

武裝化一個零日漏洞

我讓Solidity 輸出正確字節的方法一直是只加載幾個常量,並讓Solidity 發出相應的PUSH 指令。然而,這樣的任意常數可能是一個巨大的危險信號,我想要一些能更好地融入其中的東西。我還必須加載一行中的所有常量,這在實際代碼中很難解釋。

因為我真的只需要硬編碼兩個神奇的字節序列(0xa264...1220 和0x6473...0033),所以我決定看看是否可以在它們之間夾入代碼,而不是第三個常量。在已部署的合約中,我只需要用一些其他指令替換夾在中間的代碼。

address a = 0xa264...1220;uint x = 1 + 1 + 1 + ... + 1;address b = 0x6473...0033;

經過一些實驗,我發現這是可能的,但前提是啟用了優化器。否則,Solidity 會發出過多的值清理代碼。這是可以接受的,所以我繼續改進代碼本身。

我只能在兩個地址內修改代碼,但是在最後看到一個懸空的地址會很奇怪,所以我決定在條件語句中使用它們。我還必須證明第二個條件的必要性,所以最後我投了一點分數獎勵。我做了第一次有條件的檢查,檢查tx.origin是否匹配了硬編碼的值,以給人們一個最初的印象,即沒有必要進一步追求這個代碼路徑。

if (tx.origin != 0x13378bd7CacfCAb2909Fa2646970667358221220) return true;state.rand = 0x40;state.location = 0x60;if (msg.sender != 0x64736F6c6343A0FB380033c82951b4126BD95042) return true;state.baseScore += 1500;

現在源代碼都準備好了,我必須編寫實際的後門。我的後門需要驗證玩家是否正確觸發了漏洞利用,如果他們沒有正確觸發,則不給出任何提示就失敗,如果他們成功觸發,則獎勵他們。我想確保漏洞不會被輕易重放,所以我決定只要求玩家簽署自己的地址,並在交易中提交簽名。為了增加樂趣,我決定要求籤名位於交易數據中的偏移量0x44處,球通常會從這裡開始。這將需要玩家了解ABI 編碼的工作原理,並手動將球數據重新定位到其他地方。

但是,在這裡我遇到了一個大問題:根本不可能將所有這些邏輯都放入31 字節的手寫彙編中。幸運的是,經過一番考慮,我意識到我還有另外31 個字節可以使用。畢竟,真正嵌入的元數據包含了另一個Etherscan 也會忽略的IPFS 哈希。

在打了一些代碼高爾夫之後,我抵達了一個可以工作的後門。在第一個IPFS 哈希中,我會立即彈出剛剛推送的地址,然後跳轉到第二個IPFS 哈希。在那裡,我會哈希調用方,並部分設置memory/堆棧以調用ecrecover。然後我會跳回第一個IPFS 哈希,在那裡我完成設置堆棧並執行調用。最後,我將分數乘數設置為等於 (msg.sender == ecrecover()) * 0x40 + 1,這意味著不需要額外的分支。

在把後門編碼成一定大小後,我在推特上發布了我的Rinkeby地址,以便從水龍頭處獲取一些測試網ETH,然後向任何觀看這條推文的人暗示可能會發生一些事情。接著,我部署了合約並對其進行了驗證。

現在剩下要做的,就是等待有緣人發現隱藏在視線中的後門。

注:截至發稿時,來自Rocket Pool的軟件開發者Kane Wallmann已經解出了這個謎題,具體過程在這裡:https://medium.com/@kanewallmann_71759/an-untrustworthy-pinball-machine-d9dcd07882c

此外,Etherscan開發者Caleb Lau也已經修復了該漏洞。