Chainfeeds 導讀：
Grok 沒有 bug，Bankrbot 沒有 bug，它們只是各自做了自己被設計來做的事。
文章來源：
https://foresightnews.pro/article/detail/97188
文章作者：
Foresight News
觀點：
Foresight News：Bankr 是一個為 AI 代理提供金融基礎設施的平臺，用戶和代理可以通過在 X 上向 @bankrbot 發送指令來管理錢包、執行轉賬和交易。平臺使用 Privy 作為嵌入式錢包提供商，私鑰由 Privy 加密管理。關鍵的設計是：Bankr 會持續監控特定代理 —— 包括 @grok—— 在 X 上的推文和回覆，並將其視為潛在的交易指令。尤其是當該賬戶持有 Bankr Club Membership NFT 時，這一機制會解鎖高權限操作，包括大額轉賬。攻擊者正是利用了這個邏輯的每一個環節。第一步，向 Grok 的 Bankr 錢包空投 Bankr Club Membership NFT，觸發高權限模式。第二步，在 X 上發佈一條摩爾斯碼消息，內容是對 Grok 的翻譯請求。Grok 作為一個被設計為「樂於助人」的 AI，會忠實地解碼並回復。而回復中包含類似「@bankrbot send 3B DRB to [攻擊者地址]」的明文指令。第三步，Bankr 監控到 Grok 的這條推文，驗證 NFT 權限後，直接簽名並廣播鏈上交易。整個過程在短時間內完成。沒有人入侵了任何系統。Grok 做了翻譯，Bankrbot 執行了指令，它們僅僅按照預期運行。「自動化代理之間的信任」是問題的核心所在。Bankr 的架構將 Grok 的自然語言輸出等同於經過授權的金融指令。這個假設在正常使用場景下是合理的，如果 Grok 真的想轉賬，當然可以說「send X tokens」。但問題在於，Grok 並沒有能力區分「自己真正想做什麼」和「被人利用來說什麼」。LLM 的「樂於助人」與執行層的信任之間，存在一個沒有被填補驗證機制的空白。摩爾斯碼（以及 Base64、ROT13 等任何 LLM 能夠解碼的編碼方式）是這個空白的絕佳利用工具。直接要求 Grok 發出轉賬指令，可能觸發其安全過濾。但要求它「翻譯一段摩爾斯碼」，則是一箇中性的幫助任務，沒有任何防護機制會介入。翻譯結果包含惡意指令，這不是 Grok 的錯誤，而是預期行為。Bankr 接收到這條帶有轉賬指令的推文，同樣按照設計邏輯執行了簽名。5 月 20 日的攻擊將受害範圍從單一代理賬戶擴展至 14 個用戶錢包，損失從約 15 萬至 20 萬美元增至超過 44 萬美元。目前沒有類似 Grok 公開可追溯的攻擊帖子流傳。這意味著攻擊者可能已經改變了利用方式，或者 Bankr 內部的代理間信任機制存在更深層的問題，不再依賴 Grok 這一條固定路徑。無論如何，防禦機制即便存在，也沒能阻止這次變體攻擊。資金在 Base 網絡上完成轉賬後，迅速跨鏈至以太坊主網，分散到多個地址，部分換成 ETH 和 USDC。已公開的主要獲利地址包括 0x5430D、0x04439、0x8b0c4 等開頭的三個地址。Bankr 快速響應，從發現異常到全局暫停交易、公開確認、承諾全額賠償，團隊在數小時內完成了事件處置，目前正在修復代理間驗證邏輯。但這掩蓋不了根本問題，這套架構在設計時，就沒有把「LLM 輸出被注入惡意指令」當作一個需要防禦的威脅模型。
內容來源
