本周早些时候，研究人员披露了一种利用微软365 Copilot企业版隐藏输入发动的攻击手法，该攻击可迫使AI助手从用户邮箱中窃取密码。如今，另一支团队针对Grok发起了类似攻击。这种新型数据窃取手法利用了一个看似简单的技巧，强迫马斯克旗下的大语言模型窃取用户聊天记录及其他个人信息。截至本文发布时，尽管xAI早在6月便已获知相关情况，该助手仍在持续泄露数据。
这两起事件以及此前无数类似案例揭示出一个共同结论：大语言模型从根本上无法解决提示词注入问题，而这正是它们最易受到攻击的最严重漏洞类型。这使得AI开发者别无选择，只能构建防护机制来引导模型规避有害操作。正如笔者周二的报道所述，这种做法类似于道路交通安全工程师在危险弯道处设置防护栏，而非对弯道本身进行改造。
提示词注入攻击利用的是大语言模型尽可能满足用户请求的训练特性。攻击者可将恶意指令藏入邮件或网页，待助手被要求对其进行摘要时趁机发动攻击。由于大语言模型无法可靠区分来自不可信第三方的邮件内容与用户直接输入的指令，过度顺从的大语言模型便会忠实执行这些指令。迄今为止，Grok及其他大语言模型唯一的应对之策，是建立能识别可疑指令并阻止其执行的防护机制。
安全公司Adversa的研究员Rony Utevsky近期发现了一种完全绕过上述限制的简单方法。攻击者无需以明文形式编写恶意指令，而是对其进行加密。托管密文的网页同时附有解密说明及解密密钥。用户一旦指示Grok对该页面进行摘要，它便会按照上述简单流程执行加密指令——既无任何警告，也无需用户确认。
解密后的指令会引导大语言模型构建一串所谓的"解密密钥"，而其真实内容却是用户的姓名、位置及聊天记录。随后，这些数据作为参数附加到指向攻击者服务器的URL中。一旦Grok访问该链接，数据便会落入攻击者的服务器日志。
Adversa尚无法确定Grok拒绝执行完全相同的明文指令、却遵从加密指令的根本原因。目前主流推测认为，Grok的过滤防护机制负责检查进出模型的文本，却不审查其自身代码执行的输出内容。要求使用PBKDF2和AES-256-GCM处理密文的指令，在过滤器看来只是一次普通请求，因为分类器虽能读取指令文本，却无法解析其背后的真实意图。一旦附加指令完成解密，便会以工具输出的形式直接到达模型，整个过程完全绕开过滤防护机制的检查。
Utevsky在周四撰文指出："静态安全防护机制将输入内容视为纯文本进行分类，而不会执行这些内容。攻击者将密文连同密钥和解密指令一并发送，模型便在自身的代码执行沙盒中完成解密。防护机制的扫描器所需的一切信息都已呈现在页面上，但还原明文意味着需要运行PBKDF2和AES-256-GCM，而任何内容分类器在检查阶段都不会执行这一步骤。"
这位研究员在邮件中进一步解释道：此类防护机制之所以被称为"静态"，"是因为它们只将内容作为文本进行读取，既不运行代码，也不执行解密。这正是我们加以利用的漏洞所在。由于真实指令经过加密，防护机制看到的只是毫无意义的密文，便直接放行。"
Q&A
Q1：Grok遭遇的加密攻击是如何运作的？
A：攻击者将恶意指令加密后放在某个网页上，同时附上解密说明和密钥。当用户让Grok对该页面进行摘要时，Grok会在自身的代码执行环境中完成解密并执行其中的指令。由于Grok的安全过滤机制只检查文本内容，无法执行代码，所以加密的恶意指令得以绕过检测，最终导致用户的姓名、位置和聊天记录被发送至攻击者的服务器。
Q2：为什么Grok的安全防护无法拦截这种加密攻击？
A：Grok的静态安全防护机制在工作时只将内容视为文本进行分析，无法运行代码或执行解密操作。因此当攻击者发送加密指令时，防护机制只看到一串无意义的密文，认为无害便直接放行。解密过程发生在Grok自身的代码执行沙盒内，解密后的恶意指令以"工具输出"的形式到达模型，整个过程从未经过安全过滤层的再次检查。
Q3：xAI是否已修复Grok的这个数据泄露漏洞？
A：根据文章发布时的情况，xAI早在6月便已得知这一漏洞，但截至文章发布，Grok仍在持续泄露用户数据，该漏洞尚未得到修复。
