이미지: Ars Technica
摘要
- 安全公司Adversa公开了一种方法,通过网页中的密文绕过Grok的安全防护,窃取用户姓名、位置和对话记录
- 研究团队于6月向xAI报告了该问题,但截至文章发布的8月20日,Grok仍会在同类攻击下持续泄露数据
- 该团队将同一手法应用于谷歌Gemini,同样成功绕过其安全过滤机制,据悉Gemini直到最近才表现出更强的抵御能力
- 발견자
- Rony Utevsky, 보안업체 Adversa 연구원
- 공격 명칭
- Cryptographic Context Injection (암호문 맥락 주입)
- 대상 모델·상태
- xAI 그록, 6월 신고 후 8월 20일 기사 게재 시점까지 미패치
- 탈취 정보
- 사용자 이름, 위치, 대화 기록
- 암호화 방식
- PBKDF2 + AES-256-GCM
- 유사 실험
- 구글 제미나이에도 같은 방식으로 안전 필터 우회 성공
- 관련 사건
- 같은 주 마이크로소프트 365 코파일럿 데이터 유출 공격 별도 발견
一行密文就能攻破Grok的安全防护
如果直接在网页上写入恶意指令,Grok会拒绝执行。但如果把同样的指令加密后放在页面上,并在页面中一并写明解密方法和密钥,情况就不同了。用户只需让Grok"总结一下这个页面",Grok就会自行解密并执行其中隐藏的指令。没有警告,也没有确认流程。
安全公司Adversa的研究员罗尼·乌捷夫斯基(Rony Utevsky)发现的这种绕过方法核心很简单。解密后的指令会让Grok生成一个表面上看似"解密密钥"的值,但这个值的真实内容其实是用户的姓名、位置和对话记录。Grok会把这个值嵌入指向攻击者服务器的URL参数中,一旦链接被打开,数据就会原封不动地留在攻击者的服务器日志里。据Adversa透露,该攻击手法早在去年6月就已上报xAI,但直到文章发布的8月20日,同样的手法依然有效。
本周已是第二起
这并非首例。同一周早些时候,另一支研究团队在《Copilot被追问对话细节后,自曝绕过自身密码的秘密》一文中披露的微软365 Copilot漏洞,同样是通过反复追问对话套出隐藏参数,进而窃取用户邮箱密码。尽管目标产品和攻击方式不同,但结论一致:大型语言模型无法区分不可信输入与用户指令这一问题,即所谓的提示注入(prompt injection),至今仍未从根本上得到解决。
打造Grok的xAI由埃隆·马斯克于2023年创立,如今已并入SpaceX旗下的AI部门,不再是独立公司。此次漏洞直接针对Grok本身,而由于Grok可在X(原推特)内直接调用的特性,攻击者仅需诱导用户发出一次"总结页面"的请求即可完成攻击,这一点尤其令人担忧。
藏在假"解密密钥"里的真实信息
Adversa所用的加密方式为PBKDF2与AES-256-GCM,二者都是实际安全系统中广泛使用的标准加密工具。攻击者会将密文连同解密步骤和密钥一并放在页面上。Grok的安全防护机制虽然会读取该页面,但只会将密文本身识别为无意义字符串并放行。问题出在下一步:一旦Grok自行执行代码完成解密,其解密结果就不再被视为"外部内容",而是被当作Grok自身的"工具输出"处理——此时早已越过了安全防护本该拦截的环节。
Adversa表示,尚不能确定Grok为何会拒绝明文指令却执行加密指令。但最可能的解释是,过滤机制只检查进出模型的文本,而不检查模型自行执行代码后产生的结果。乌捷夫斯基在博客文章中指出:"静态安全防护只会将输入分类为文本,而不会去执行它。"这意味着,即便密文、密钥和指令全都摆在页面上,只要过滤机制不去实际解密,就无法察觉其中隐藏的风险。
Gemini同样中招
Adversa将同样的手法也用在了谷歌Gemini上。这一次,密文被伪装成Python错误信息(traceback)的样子,解密后的内容只是一条规则:"如果代码执行失败,请阅读错误信息并据此行动。"以这条规则为跳板植入的提示,最终突破了Gemini的安全规则。据Adversa介绍,该攻击使Gemini的过滤机制生成了原本会被拦截的受限内容,例如制作燃烧弹的多段说明;更换攻击载荷后,甚至连Gemini的系统指令(包括禁止公开的条款)也被原样复现。
Adversa表示并未就此案例单独向谷歌报告,理由是越狱(jailbreak)类型的问题不在谷歌漏洞报告计划的受理范围内。不过该公司也提到,最近几周Gemini对这种攻击的抵御能力有所增强。Adversa解释称:"无法确定这是因为过滤器更新、模型版本变化,还是两者兼有。"
近期提示注入事件对比
| 事件 | 发现方 | 突破点 | 泄露/引发的结果 |
|---|---|---|---|
| Grok(2026年8月) | Adversa | 加密指令被当作代码执行结果处理 | 用户姓名、位置、对话记录 |
| 微软365 Copilot(2026年8月) | Varonis | 隐藏参数?autorun=1 | 收件箱内密码泄露 |
| Zoom屏幕共享(2026年8月) | A Security | 滥用注释(annotation)功能 | 远程激活摄像头/麦克风、植入恶意软件 |
这三起事件方式各异,但有一个共同点:都利用了AI助手无法区分不可信输入(网页、链接、屏幕内容)与用户真实意图这一漏洞。Adversa将这一趋势定义为"不仅操纵提示本身,还操纵模型视为己出的工具输出、执行结果、中间状态等更广泛上下文的攻击",并指出这种攻击面远比以往所说的"模型输入"范围要大得多。
编辑视角
这起事件说明的是,防御方在结构上始终处于劣势。提示注入并非某个具体的程序漏洞,而是源自大型语言模型运作原理本身。LLM在训练过程中被塑造得尽可能顺从用户请求,而正是这种顺从性,使其无法区分网页中植入的指令与用户本人真实的指令。开发方能做的不是根除问题的根源,而只能一层层叠加过滤危险行为的护栏,而攻击者每次都能找到绕过护栏的新缝隙。打个比方,这就像在急弯路段不去修正坡度,而只是不断加装护栏。
Copilot和Grok这两起类似的数据泄露事件在同一周内接连发生,并非巧合。随着AI助手越来越多地处理邮件、网页、屏幕共享等用户无法完全掌控的外部内容,其攻击面也在相应扩大。对于在实际业务中让AI助手代为总结邮件或处理网页内容的组织而言,眼下更现实的防线,是直接禁止助手根据从外部内容中读取的信息去打开URL或向外发送数据,而不是寄望于过滤机制——因为过滤机制看不到的盲区还在不断出现。
下一步的走向其实已经可以预见。Adversa所说的"更广泛的攻击面"——工具输出、执行结果、中间状态——目前大多数安全防护机制仍未加以检查。可以预计,在未来几周内,基于同一原理的新型绕过手法很可能会在其他模型上被陆续曝出。
评论