區塊鏈釣魚攻擊綜合分析

05-29

本文為機器翻譯

展示原文

本文由X-explore與WuBlockchain聯合發佈。

介紹

根據 Chainalysis 在 2024 年的文章，非法地址已收到價值 242 億美元的資金，佔鏈上總交易量的 0.34%。隨著人們對區塊鏈行業的興趣日益濃厚，越來越多的用戶和資產開始流入 Web 3 市場，但用戶報告的網絡攻擊事件也越來越多。

在各種攻擊中，釣魚仍然是網絡攻擊的主要方面之一。攻擊者瞄準各種代幣，例如穩定幣、ETH 甚至山寨幣。他們誘使用戶簽署惡意交易或輸入私鑰以控制用戶的帳戶。本文將進一步研究現有的釣魚詐騙方法，並探討未來預防或識別惡意帳戶的方法。

背景與相關工作

現有的釣魚攻擊方法框架（鏈下）

網絡釣魚攻擊的重點是誘使用戶在網絡世界中輸入私人信息。誘使用戶的方法多種多樣，但大多數網絡釣魚都是在電子郵件、社交媒體渠道或看似合法的克隆網站等平臺上進行的。此類電子郵件或網站誘使用戶輸入私人信息或簽署交易，從而將控制權交給騙子。本文將首先研究騙子在鏈下使用的 3 個主要框架。

魚叉式網絡釣魚

魚叉式網絡釣魚攻擊針對的是特定個人或組織。通過事先收集定製信息，攻擊者可以製作一封個性化電子郵件發送給特定群體，從而使該電子郵件合法化。此外，隨著生成式人工智能的興起，一個騙子現在有能力收集個性化信息並製作個性化電子郵件，針對比以前更廣泛的用戶群體。

域名釣魚攻擊

域名釣魚攻擊會製作重定向到虛假網站的 URL。例如，在 Slack 網站上，將“ www.apple.com ”的“i”替換為大寫“I”後，看起來與“ www.appie.com ”完全相同。通過這種方法，詐騙者會製作惡意 URL，並通過電子郵件或 Telegram 或 Slack 等 SNS 渠道進行分發。

假冒瀏覽器擴展程序

詐騙者編寫惡意擴展程序，製作下載鏈接，通過電子郵件或SNS渠道分發。點擊後，此類擴展程序將下載到用戶環境中，並尋找助記詞和私鑰等隱私信息。

請注意，一旦用戶點擊下載鏈接、輸入私人信息或簽署交易，詐騙者將完全控制該帳戶，用戶無法回滾。因此，用戶不要點擊不信任的來源至關重要。

區塊鏈上的資金提取（鏈上）

鑑於鏈下框架，本文將研究詐騙者如何完全控制鏈上錢包。在區塊鏈領域，攻擊者可以通過各種方式控制用戶的賬戶。尤其是對於 ERC-20 代幣合約（例如穩定幣和山寨幣），詐騙者不一定需要用戶的私鑰，而是需要用戶的簽名登錄鏈上或鏈下。本文將研究攻擊者用來竊取資金的各種方式。

私鑰

如今，提取私鑰已經不是一種常用的方法。攻擊者會製作網站或電子郵件，要求用戶輸入種子短語或私鑰。一旦攻擊者獲得用戶的私鑰或種子短語，攻擊者就完全控制了錢包和地址。

基於私鑰的網絡釣魚攻擊示例圖。（來源：X）

雖然這是一種簡單的方法，但是過去的用戶由於缺乏區塊鏈領域的知識，很容易陷入陷阱。

批准並轉移

在 ERC-20 標準下，ERC-20 代幣支持推送和拉取交易，適用於 De-Fi 協議的應用。推送交易由付款人發起，付款人決定向收款人發送多少錢。而在拉取交易中，收款人指示付款人發送多少錢。因此，第三方可以控制交易。拉取交易指令在 Web 3 中按照以下流程進行管理。

用戶調用並簽署 Approve()。 approve( owner, spender, amount)設置收款人地址可以從用戶地址中取出多少代幣。請注意，可以利用increaseAllowance( spender, amount) 。approve 和 increaseAllowance 之間的區別在於，approve 設置新的限額，而 increaseAllowance 增加現有限額 [設置硬性限制]。
一旦設置了邊界，收款人就可以調用transferFrom(to, from, amount) ，將用戶的代幣移動到收款人的地址。

在實際應用中，收款人通常是智能合約。用戶將 ERC-20 代幣轉移到智能合約，智能合約將據此管理資金。但需要注意的是，一旦智能合約被黑客入侵，用戶的資金將根據設置的限額被盜走。在某些情況下，為了簡化用戶的 UI，智能合約可能會要求高額（無限量）的限額，這樣用戶就不必每次都簽名來設置限額以節省 gas 費用。由於金額設置為無限量，用戶必須確保第三方是可靠的來源。

長期以來，設置授權和使用 transferFrom 方法一直是薄弱環節。然而，由於其在去中心化金融 (De-Fi) 和 dApp 中的實際應用，Approve & TransferFrom 如今已得到廣泛使用，並進行了改進。

例如，由於EVM的最大容量設置為1024，set allowance → transferFrom等複雜過程通常會導致“1024堆棧深度問題”，因為堆棧超出了給定空間的限制，從而導致交易回滾。

因此，如果調用每個方法並繼續執行下一個方法，則調用它將引入一個巨大的漏洞點。主要的利用方式可能是重入攻擊。Vitalik 意識到了某些情況，並在 2017 年進行了改進，並引入了 ERC-223 標準。

Vitalk 對 1024 堆棧深度的評論截圖。（來源：Github）

已經引入了其他改進的協議，例如 permit 或 permit2，但錢包的安全性取決於用戶簽署交易。因此，檢查 3 個主要方面以防止潛在的詐騙非常重要。

批准金額：詐騙者經常會創建具有異常高額度的批准請求，以獲取對專用 ERC-20 代幣的完全控制權。簽訂合同時，請務必檢查批准金額。
已驗證的智能合約：確保您簽署了由已知 dApp 提供的已驗證智能合約的授權簽名。檢查 Etherscan 或任何其他區塊鏈瀏覽器的標籤和備忘錄可以幫助確定合約是否被標記為惡意。
檢查安全警報：如果您正在與潛在的詐騙合約進行交互，錢包提供商（例如 Meta Mask 或 Wallet Connect）會生成提示。請務必檢查此類警報。

案例

讓我們直觀地看一下實際攻擊是如何在區塊鏈瀏覽器中進行和記錄的。

區塊鏈：BSC 鏈

日期：2023–05–11

攻擊者： 0x49Dc14Dd851B6EaE8d685715e12a06cc1BFC5d8d

受害者： 0x5F464c94e93CEbd56aE2F1220912BA0ab0a27a38

步驟1 ：用戶簽署批准合同

當通過電報頻道、Instagram 或釣魚網站在 Web 2 環境中收到虛假信息時，用戶會收到批准簽名請求。

受害者批准騙子獲取柴犬代幣

批准和轉移請求。受害者批准了總計 426923054270173310680061630 SHIB，由詐騙者控制

Dex 或 Cex → 受害者 → 詐騙者的資金流向截圖

第 2 步：耗盡資金

現在，由於騙子已經控制了受害者地址中426923054270173310680061630或更少的 ERC-20 代幣資金，騙子開始將受害者的代幣轉移到其賬戶中。如下所示，受害者賬戶中已盜取總計256153832.56 SHIB。

該交易由攻擊者完成，竊取了 256153832.56 SHIB

允許

ERC-2612 引入了 Permit，作為對 approved 和 transferFrom 工作流程的改進。與 approved 和 transferFrom 不同，Permit 會創建鏈下簽名，這意味著用戶不必事先在鏈上簽名批准。Permit 和 transferFrom 的工作流程如下：

Permit 協議技術流程（來源：Medium）

用戶需要通過permit (owner, spender, value, nounce, deadline)創建簽名，返回值r,s,v為已經創建的簽名的3個分割。
一旦用戶使用 r、s 和 v 創建許可證簽名，第三方將使用以下值調用permit(owner,spender, value, deadline, v, r, s) 。一旦進行階段變更交易，它將相應地設置限額。
在一筆交易內，一旦設定了限額，第三方就會執行轉賬。

通過利用 permit() 創建離線簽名，可以節省 gas 費用，因為無需在鏈上籤署許可。此外，通過創建 r、s、v，安全性得到了極大提高，用戶永遠不會暴露自己的私鑰來創建簽名。

需要注意的是，並非所有 ERC-20 標準 token 都支持 permit() 方法。而且 permit() 的核心機制在 approved & transferFrom 的流程中。漏洞點在於用戶創建或簽署 Permit() 時。

案例

讓我們直觀地看一下實際攻擊是如何在區塊鏈瀏覽器中進行和記錄的。

區塊鏈：ETH

日期：2024–05–24

攻擊者： 0x77865b925f96fc49837cfe27ec04cd5a691e61ef

受害者： 0x7cdd2a99fc014194218119a7100c259e31a10bf2

步驟 1 ：用戶生成鏈下簽名

由於這個過程是在鏈下進行的，因此無法在區塊鏈瀏覽器上追蹤。騙子會誘使受害者通過簡單的點擊生成鏈下簽名。即使受害者沒有在線簽署交易，通過錢包簽署鏈下簽名已經允許騙子稍後執行 TransferFrom。

步驟 2 ：詐騙者通過鏈下簽名簽署許可合同

騙子通過鏈上交易將簽名的消息提交給 ERC-20 Token 合約，驗證受害者地址和 nonce 後，會發出批准請求。注意，通過 permit 只發生過一次鏈上交易，相比傳統的 Approve&TransferFrom 少了一次交易，節省了 gas 費。

在一次執行中調用了 Permit 和 transferFrom

注意批准數量異常大

共計 173455570204 USDC 已被提取

ERC-4337（賬戶抽象或智能合約錢包）

Vitalk 於 2021 年推出的新型 AA 方案是基於當前現有的共識層協議創建的。與之前引入的EIP-86 （Bare multi-sig AA）、 EIP-3074 （Auth 和 Authcall）和EIP-2938 （Account Abstraction）等 AA 方案不同，這是第一個在現有共識層協議中引入 AA 的方案，可更輕鬆地融入當前市場。

帳戶抽象（AA）

區塊鏈中主要存在兩種類型的賬戶：外部賬戶和智能合約賬戶。兩種賬戶的特點如下表所示。

AA 的目標是創建一個統一的賬戶，該賬戶兼具 EOA 和 SC 的優點：完全可編程，並具有發起交易的能力。AA 的優點包括：

能夠直接響應合同調用
輕鬆轉移賬戶所有權（無法通過 EOA 完成）
引入新的驗證規則（可以在 SC 級別內檢查密碼）
消除從 EOA 到智能合約的 gas 費用
管理一個地址，而不是 EOA 和 SC
引入新的 gas 費支付方式（不必是原生代幣）

ERC-4337 的工作流程

AA 是一個新的標準，可以創建統一的賬戶，大大改善用戶的 UI。ERC-4337 的技術流程如下：

ERC-4337 的流程圖（來源：Eden Network）

ERC-4337 技術流程圖（來源：ERC-4337 官方文檔）

ERC-4337 可以分為四個主要流程。

步驟 1：創建用戶操作

通過 dApp 和錢包，用戶可以與 AA 方案操作進行交互以創建用戶操作。用戶擁有更好的用戶界面，因為該應用程序可以支持多種功能，例如多重簽名、社交恢復等。創建用戶操作後，它將離線創建一個簽名，稍後將由帳戶驗證該簽名，然後再執行。

步驟 2 ：打包處理

一旦用戶提交了用戶操作，它將被存儲在用戶操作內存池中，打包器將在那裡收集並聚合成一個包。打包器將檢查交易的有效性，一旦通過，打包的交易將被髮送到鏈上進行處理。

步驟 3 ：入口點合約

關於 EntryPoint 合約的規則。（來源：ERC-4337 官方文檔）

上述規則中提到，鏈上有一個統一的 Entrypoint Contract，在收到打包交易後會進行 Gas 計算，確定智能合約賬戶需要支付多少 Gas 費。通過 Entrypoint Contract，用戶無需像智能合約賬戶或 Paymaster 那樣支付 Gas 費。而且該方案最重要的優勢是 Gas 費不必以 Native Token 支付，費用可以在 dApp 上進行管理，並通過 PayMaster 以 ERC-20 Token 支付。這樣的安排提高了用戶的交易體驗。

步驟 4 ：驗證和執行

在收到來自入口點合約的方法後，將驗證原始用戶操作。驗證後，它將相應地執行交易。請注意，這是一個入口點合約，它將把交易添加到 ETH 網絡內存池中。

漏洞點

從安全角度來看，仍然存在很多漏洞點。由於 AA 方案允許將用戶操作從鏈下託管的打包器執行到鏈上，這為騙子操縱用戶執行用戶操作提供了很多漏洞。本文將提供整個操作執行過程中的潛在漏洞點。

偽造的入口點合約

請注意，每條鏈只能有一個 EntryPoint 合約。但是，詐騙者可以在鏈上製作他或她自己的 EntryPoint 合約版本來執行用戶操作。由於大多數安全協議和監控將重點關注單例 EntryPoint 合約，因此詐騙者可能希望創建他或她的版本來避免這種情況。然而，使用當前的區塊鏈監控系統可以輕鬆檢測到此類合約並進行相應的管理。

惡意捆綁器

詐騙者可以製作帶有用戶操作內存池的 Bundler 服務版本。Bundler 服務由四個主要部分組成：配置、RPC 服務器、替代內存池和捆綁 UserOperations。

配置設置 EntryPoint 和受益人賬戶的地址。

RPC 服務器根據給定的 EntryPoint 地址來處理操作。

 async handleMethod (method: string, params: any[]): Promise<any> { let result: any switch (method) { case 'eth_supportedEntryPoints': result = await this.methodHandler.getSupportedEntryPoints() break case 'eth_sendUserOperation': result = await this.methodHandler.sendUserOperation(params[0], params[1]) break case 'eth_estimateUserOperationGas': result = await this.methodHandler.estimateUserOperationGas(params[0], params[1]) break case 'eth_getUserOperationReceipt': result = await this.methodHandler.getUserOperationReceipt(params[0]) break case 'eth_getUserOperationByHash': result = await this.methodHandler.getUserOperationByHash(params[0]) break // ... default: throw new RpcError(`Method ${method} is not supported`, -32601) } return result }

備用內存將操作以數組格式存儲，然後再將其發送到鏈。從打包器的角度來看，應在此處管理 DoS 攻擊的預防。

 // add userOp into the mempool, after initial validation. // replace existing, if any (and if new gas is higher) // revets if unable to add UserOp to mempool (too many UserOps with this sender) addUserOp (userOp: UserOperation, userOpHash: string, prefund: BigNumberish, senderInfo: StakeInfo, referencedContracts: ReferencedCodeHashes, aggregator?: string): void { const entry: MempoolEntry = { userOp, userOpHash, prefund, referencedContracts, aggregator } const index = this._findBySenderNonce(userOp.sender, userOp.nonce) if (index !== -1) { const oldEntry = this.mempool[index] this.checkReplaceUserOp(oldEntry, entry) debug('replace userOp', userOp.sender, userOp.nonce) this.mempool[index] = entry } else { debug('add userOp', userOp.sender, userOp.nonce) this.entryCount[userOp.sender] = (this.entryCount[userOp.sender] ?? 0) + 1 this.checkSenderCountInMempool(userOp, senderInfo) this.mempool.push(entry) } this.updateSeenStatus(aggregator, userOp) }

最後，對於捆綁用戶操作，它會創建將發送到 EntryPoint 合約的捆綁包。捆綁者必須確保在轉發操作之前驗證其支付費用的能力，以防止 DoS 攻擊。否則，詐騙者可以製作看似支付了費用但會撤銷的操作，從而導致鏈的內存池擁堵。

此外，驗證步驟不應違反狀態變化，這意味著它將根據與發送者相關的數據進行驗證。Bundle 的驗證和創建在下面的代碼中

async createBundle (): Promise<[UserOperation[], StorageMap]> { const entries = this.mempoolManager.getSortedForInclusion() const bundle: UserOperation[] = []

 // paymaster deposit should be enough for all UserOps in the bundle. const paymasterDeposit: { [paymaster: string]: BigNumber } = {} // throttled paymasters and deployers are allowed only small UserOps per bundle. const stakedEntityCount: { [addr: string]: number } = {} // each sender is allowed only once per bundle const senders = new Set<string>() // all entities that are known to be valid senders in the mempool const knownSenders = entries.map(it => { return it.userOp.sender.toLowerCase() }) const storageMap: StorageMap = {} let totalGas = BigNumber.from(0) debug('got mempool of ', entries.length) // eslint-disable-next-line no-labels mainLoop: for (const entry of entries) { // check reputation system // check duplicate UserOps per sender // check stake // check storage access // check UserOp call gas limit // check Paymaster deposit if present // If sender's account already exist: replace with its storage root hash senders.add(entry.userOp.sender) bundle.push(entry.userOp) totalGas = newTotalGas } return [bundle, storageMap] }

PayMaster 漏洞利用

由於PayMaster是處理交易的定製合約，因此詐騙者可以通過利用代碼漏洞來轉移Gas費。未來將進行進一步研究。目前PayMaster漏洞利用的案例還不多。

案例

讓我們直觀地瞭解一下實際攻擊是如何在區塊鏈瀏覽器中進行和記錄的。請注意，AA 是一種以捆綁操作方式處理交易的方案。詐騙者通常利用 AA 方案來處理 Perimt 或 Approve 等交易。以下示例將查看 Approve 和 TransferFrom 請求。

區塊鏈：BSC 鏈

日期：2024–03–23

攻擊者： 0x454b8b645a981e6c197087ea154df94b5187d682，0x170f7be1baf9234af5966d194a0a6bd6073eed99

受害者： 0x3f3ce11b7809ecf6f571943800c28f585e8b187d

https://app.blocksec.com/explorer/tx/bsc/0x812bc694a8c6732b899e81727f128d06c2b7b6717a2dd67936079928b41621b3

步驟 1 ：用戶簽署鏈下許可請求

與典型的許可請求一樣，詐騙者會誘使用戶簽署許可消息。它會偽裝成批准交易或訪問服務的必要步驟。受害者會認為請求是合法的，然後使用私鑰在鏈下籤署消息。

步驟2 ：與Bundler交互

詐騙者現在將與打包器進行交互，打包器將把許可交易作為一項操作來處理。詐騙者將交易發送給打包器，打包器現在將交易存儲在用戶操作內存池下。存儲在用戶操作內存池中後，它將經過驗證過程並移交給 EntryPoint 合約。

步驟3 ：EntryPoint 合約

EntryPoint 合約從打包器接收到操作流程後，會在執行之前驗證打包器中的用戶操作。如下圖所示。一旦檢查到 gas 費用的可用性和狀態更改的正確性，它就會處理內部操作。

處理 InnerOperations 之前的操作的屏幕截圖

步驟 4 ：處理狀態更改

如下圖所示，本例的內部操作包含兩個 transferFrom 操作。注意兩個地址的轉賬金額相差多少： 212856150000000008192 ， 37562849999999991808 。比例大約是 0.85:0.15，這表明 Drainer 可能提供詐騙服務，並將提取的金額按一定比例分享給 Drainer 和客戶。關於 Drainer 服務的細節將在文章後面討論

BSC-USD 代幣 TransferFrom 的兩個操作，其中 Approval 和 Transfer 位於

批准中價值異常高的通知

資金流與運作流

詐騙者的攻擊方法

加密貨幣耗盡者（以服務提供商身份詐騙）

近期，加密市場中關於服務提供商詐騙的報道越來越多。服務提供商在多鏈上工作，提供服務以提取 ERC-20 代幣，並賺取被盜代幣作為獎勵。本文將介紹加密提取者的一個示例案例。

地獄火吸取器

根據 Scam Sniffer 的數據顯示，Inferno Drainers 在活躍期的 1 年內（2022 年 11 月 - 2023 年 11 月）已竊取了 8000 萬美元或更多。Inferno Drainer 使用社交工程學建立釣魚網站，並與客戶共享該平臺。

本文基於 Group-IB 的 Scam Sniffer

然後，客戶在 Telegram、Facebook、Instagram 或其他社交網絡上發送社交工程網站鏈接來吸引普通用戶。通常不具備加密貨幣和區塊鏈領域知識的受害者會在不知情的情況下向 Inferno Drainer 的客戶授予訪問權限。

地獄火汲取者的一般攻擊流程如下：

地獄之火排水器的運作流程（來源：Group-IB）

如流程圖所示，Inferno Drainer 主要通過構建釣魚社交工程網站盜取受害者資金，而客戶則負責將釣魚網站傳播給受害者。一旦受害者打開網站並簽署交易，客戶將獲得被盜代幣的 80%，Inferno Drainer 將獲得 20%。

Inferno Drainer 通過非常簡單的設置和簡單的 Approve&TransferFrom 方法或 Permit 方法在鏈上竊取了超過 8000 萬美元的資產。

排水方法

Inferno Drainer 主要使用了經典的 Approve & TransferFrom 方法或 permit 方法。我們來看看它們活躍期間的其中一個 Approve&TransferFrom

受害者： 0xe142C1858b8447238F3953e685e62ED6005DcAaA

攻擊者： 0xFC4EAA4ac84D00f1C5854113581F881b42b4A745

代幣：PEPE

損失金額：26,372,295.3（220 美元）

步驟1 ：受害者簽署同意（）

注意批准金額的值

步驟 2 ：攻擊者執行 TransferFrom()

天使吸取器和攻擊方法的改進

在 Inferno Drainer 停止服務後，一種更先進的新型 Drainer 服務問世了。其中一個值得注意的 Drainer 是 Angel Drainer。與 Inferno Drainer 不同，Angel Drainer 利用高級技術來操縱智能合約邏輯和用戶行為。某些方法側重於繞過由行為分析和速率限制觸發的安全警報。本文將介紹 Angel Drainer 用於榨乾資金的兩種主要新型攻擊方法。

Angel Drainer 提供的服務截圖。（來源：CheckPoint）

嵌套智能合約部署機制

和各種利用 Approve&TransferFrom 或 Permit 的釣魚手段一樣，ChainAlysis、BlockAid、Check Point 等區塊鏈安全組織也開發了複雜的監控算法，可以識別鏈上潛在的騙子。尤其是騙子地址上的 Permit 和 Approve&TransferFrom 等交易非常容易識別。因此，Angel Drainer 採取了一種複雜的方法，通過創建執行 Multicall 功能的新智能合約來繞過安全警報。

例子

為了瞭解 Angel Drainer 如何繞過安全警報，我們將研究一個真實的攻擊示例，並調查已使用的智能合約。讓我們探索背後的交易：

0xb60c32fb28aa6160df6f472f494f162b997aa49fb06776dce250aff80602a8a3

步驟 1 ：創建嵌套智能合約

Angel Drainer 首先創建一個具有以下功能的智能合約。

如下圖所示，對於這個特定的交易，Angel Drainer 首先使用0x095838d2() ，然後調用0xf2fde38b() transferOwnership(address)。

為了簡單起見，我們將這個合約稱為主合約。在主合約中，我們需要關注一個函數0x095838d2() 。該函數的邏輯如下：

需要三個參數(secondContractAddress, tokenContractAddress, arrayOf3Elements)
檢查 secondContractAddress 是否為現有合約。它檢查給定地址的代碼大小。如果它大於零，則表示合約存在，否則反之亦然。
如果是，則執行包含（Permit & TransferFrom）的Multicall函數。如果不是，則用該地址部署新合約，然後執行Muticall函數。

對於此交易案例，secondContractAddress 為 Null，導致其首先創建一個新的智能合約。

步驟 2 ：多路調用函數

一旦主合約識別或創建了第二個合約，第二個合約中的 Multicall() 函數就會被執行。這個函數的存在是為了協調合約交互。我們來看看 multicall() 函數的主要功能。

如上圖所示，multicall 接受交易操作作為參數，並通過在 v1[v3] 指定的地址進行外部合約來處理各個參數。multicall 的具體執行過程可參見下圖。

如上圖，muticall 一共處理了 3 筆交易，分別是 Permit 和兩筆 transferFrom。Permit 和 transferFrom 是在代幣合約Lido: stETH上進行的。

注意 transferFrom 中的值差異。比例為 0.85:0.15。這說明了 Customer 和 Angel Drainer 的利潤分配。

步驟3 ：所有權轉移

為了讓騙子完全控制第二份合約。0x095838d2 0x095838d2()的最後一步包括執行從第二份合約到騙子地址的 TransferofOwnership。

我們查看了 Angel Drainer 用來繞過安全警報的操縱方法，即創建新合約並在新合約的多重調用中處理操作。由於新合約不包含任何交易記錄，通過多重調用隱藏交易，並且不是由詐騙者的地址直接部署的，因此它能夠繞過安全警報。然而，由於 Check Point Research 的識別，嵌套智能合約攻擊方法現在可以被識別，並且不會再繞過安全警報。

2. EigenLayer Restake Farming 攻擊

EigenLayer 是一種去中心化協議，旨在通過“重新質押”過程增強區塊鏈網絡的安全性和效率，允許用戶將其代幣鎖定到智能合約中。用戶可以先質押代幣一段時間並獲得獎勵，然後重新質押更多代幣，而不是取消質押並重新質押。通過這樣的過程，它允許用戶與多種服務進行交互並質押更多代幣，最終同時增強了鏈的安全性和實用性。

攻擊向量點

然而，重新質押機制存在一個漏洞。主要是 EigenLayer 協議的queueWithdrawal機制。要理解攻擊是如何進行的，我們需要了解質押和重新質押的過程是如何進行的。

EigenLayer 協議採用一種特殊的方法來處理權益提款。

當用戶質押一定數量的代幣，然後決定提取質押的代幣時，交易不會立即處理。相反，它會被存儲在隊列中。用戶必須等待 7 天的託管期才能取消質押，而在以太坊上，驗證者清掃後每 4-5 天可以提取一次部分質押資金。由於這種批准方法是新的，大多數安全提供商或內部安全工具都沒有驗證這種批准類型並將其標記為良性交易。因此，它為 Angel Drainer 留下了一個可以利用的漏洞點。

例子

鏈：ETH

日期：從 2024 年 1 月 15 日至 2024 年 1 月 29 日

攻擊者： 0x8031A648B169a9fa6f63954C0F0B106E57027696

步驟1 ：CREATE2合約

這是他們能夠繞過安全警報並掩蓋流程的部分。Angel Drainer 使用 CREATE2 準備一個帶有參數(salt, bytecode)的合約。然後 CREATE2 將生成一個特定的新地址。新地址將用於收集獎勵和取消質押代幣，成功繞過安全警報。

步驟2 ：啟動queueWithdrawal

攻擊者首先從 Eigen 層發起取消質押，從而觸發 7 天的託管期。