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 输出被注入恶意指令」当作一个需要防御的威胁模型。
内容来源
