小心那些利用Etherscan招搖撞騙的人

去中心化金融社区｜2022-03-07 15:24

區塊鏈索引服務依賴於合約事件來幫助歸檔數據，並在一個漂亮的用戶界面中給我們提供交易記錄，其通常被稱為“區塊瀏覽器”，比如Etherscan。但惡意合約可以表現得無比“正常”，卻會污染這些事件，從而欺騙區塊瀏覽器，向毫無戒備的用戶提供關於代幣來源的誤導性信息。例如，惡意用戶可以部署一個簡單ERC20

區塊鏈索引服務依賴於合約事件來幫助歸檔數據，並在一個漂亮的用戶界面中給我們提供交易記錄，其通常被稱為“區塊瀏覽器”，比如Etherscan。但惡意合約可以表現得無比“正常”，卻會污染這些事件，從而欺騙區塊瀏覽器，向毫無戒備的用戶提供關於代幣來源的誤導性信息。

例如，惡意用戶可以部署一個簡單ERC20合約和“空投”代幣給一群用戶，在自動做市商上創建一個看起來健康的流動資金池，等待用戶根據錯誤的宣傳購買或出售代幣，認為此代幣是已知開發人員/實體的一部分。

分解

ERC20代幣(它是代幣接口的通用標準)是合約的屬性、函數、輸入、輸出和事件的集合。只要我們的合約具有正確的函數特徵，我們就可以在這些函數中使用自定義邏輯——即使是提供不正確數據的函數。

例如，如果合約部署者發送一個代幣，我們可以讓一些/所有區塊瀏覽器向最終用戶（在某些視圖中）顯示不同的地址。假設如下；

合約部署者是有惡意的，想要為他們的代幣製造一些炒作。代幣在AMM中有一些流動性(如Uniswap)供用戶購買/出售，主要的流動性提供者頭寸屬於代幣背後的團隊。許多用戶都知道發送者，而不是某個隨機的地址。

這不僅僅是ERC20的問題……受污染的數據可以被插入到任何代幣標準事件中，如NFT (ERC721, ERC1155)，以迷惑用戶和潛在投資者，讓他們認為項目有特定的利益方/影響者，而實際上並沒有。

這個問題並不“新鮮”，但我們寫這篇文章是為了強調正在發生的事情，以及用戶在“模仿”“看起來合法”的項目之前應該做些什麼。

當區塊瀏覽器看到交易發出的事件時，他們將其記錄在他們的鏈下數據庫中，並與其他數據建立關係，這樣他們就可以建立一個很好的交易關係圖，在他們的UI中顯示給終端用戶。

概念驗證

我們將部署一個概念驗證合約，使用一個老版本的Solidity，同時也要證明它與任何Solidity版本或以太坊中的任何東西都沒有問題，其是一個來自鏈下應用程序信任合約的信任問題。一般來說，對事件的繼承信任是“正確”的，它是一種合約將可用數據提供給鏈下程序進行索引的方式。

在上面的合約(位於0x3afe99bd92b1aed3237196b26743681766d4940e)中，我們修改了邏輯，將Transfer 事件中的發送者地址更改為流行區塊瀏覽器上標記為“OpenSea：Wallet”的地址，前提是我們（創建合約的人）發送代幣。

它所做的是，當區塊瀏覽器索引該事件時，它從Transfer事件中看到地址為0x5b32…1073發送了代幣，而不是實際的發起者0x11b6…04C9，這可能導致該方法被不良行為者利用，誘使用戶認為;

一個受歡迎的人物在代幣上有既得利益一個受歡迎的人物正在“卸載”大量的代幣代幣是合法的，因為在區塊瀏覽器上，它顯示了已知的實體與代幣合約“交互”

讓我們從合約部署者地址調用transfer()，看看區塊瀏覽器索引了什麼。我們只是將代幣從我的地址(0x11b6…04C9)移動到一個目標地址(0x4bbe…1520)。

“OpenSea: Wallet”ERC20活動視圖顯示它似乎已經發送了一個名為OpenSeaRevenueShare的代幣到目的地。

交易表明(在“token Transferred”中)“OpenSea: Wallet”將代幣發送到目標地址。

目標地址顯示“OpenSea: Wallet”給他們轉移了10個代幣。

尋找什麼？

大多數這樣的以利用用戶的惡意合約都沒有被“驗證”，又因為我們只能接觸到區塊瀏覽器上的字節碼，如果事件被污染了不良數據，再基於某些條件，都很難讓用戶進行驗證，就像我們的概念驗證一樣。如果合約沒有被驗證，比如我們無法看到Solidity/Vyper/...代碼，並且只暴露於字節碼，那麼在與合約交互之前，我們應該採取預防措施。

如果一個代幣被“空投”給我們或其他實體，我們應該謹慎，特別是當我們試圖在DEX上清算代幣時，因為過去有一些事件是利用人為製造價格的方法從竊取的。