Grok 应用被指大规模暴露,默认分享引争议
安全公司 Claroc 称发现逾 3.5 万个无需认证即可访问的应用,部分涉及内部或敏感信息,且随机域名可通过被动 DNS 被发现。Grok 对报道中的产品归属提出异议;摘录中的数量与百分比也存在口径不清的问题。
AI 深度解读
Claroc 披露,大量与 Grok 应用构建功能相关的应用,可以在未登录的情况下直接打开,其中部分包含企业内部资料、医疗记录和明文密码。问题的关键是:用户发布应用时,默认选择了「Anyone with the link」,而看似难猜的网址又能被外部服务发现。
Grok 随后反驳报道,称涉及的是 grok.com 的 app-builder feature,而非 Grok Build。产品名称仍有争议,但对开发者更有用的问题是:一个没有主动分享出去的内部工具,为什么仍可能被陌生人打开?
随机网址为什么挡不住外部访问
Claroc 找到了 43,601 个应用地址,并称其中 35,578 个、占 94.7%,无需身份验证就能访问。这里有一处数字需要保留疑问:35,578 与 43,601 并不对应 94.7%,原文没有解释比例的统计分母,不能把这组数字直接当成一致的统计结果。
研究人员发现,地址由四个随机单词组成,设计意图是增加猜测难度。但攻击者不一定需要猜。
被动 DNS 服务会记录并索引 DNS 流量中出现过的域名。研究人员可以借助这些记录找到应用地址。按照 Ars Technica 的报道,除少数情况外,点击发现的链接,就能打开应用及其关联数据。
难猜的网址只能增加发现成本,不能代替身份验证。
发布设置进一步放大了这个问题。Claroc 称,默认分享选项是「Anyone with the link」,另外两个选项是「Invited Users」和「Only You」。在默认设置下,拿到地址的人就能访问,无论创建者是否亲自把链接发给过他。
暴露的不只是演示页面,还有业务数据和密码
Claroc 估计,可访问应用中约十分之一包含内部或敏感信息,约 2% 包含足以评为高危或严重级别的数据。这是研究方的估计,不能推成所有公开应用都泄露了敏感内容。
原文列出的样本,覆盖了多种内部工具:
- 人事与医疗资料包括约 3,565 名医院员工的目录、秘鲁建筑企业的 3,784 份工人体检记录,以及参与美国海军后勤支持合同的 108 人名单。
- 经营资料包括约 583 名潜在购房者的预算和融资备注、约 4,000 笔汽车运输订单的价格与利润,以及马来西亚一家控股公司的 37 个开发项目数据。
- 员工管理资料包括 Tesla 服务中心 22 名技师的生产效率和奖金状态,以及豪华邮轮厨房检查表上的姓名与员工编号。
- 其他内容包括带硬件物料清单的保密 IT 服务方案,以及一家挪威与芬兰航空航天和防务集团旗下美国工厂的爆炸物厂房装载流程。
TechRadar 还报道称,一份暴露的员工工时表附带可下载代码,其中包含 18 个明文账户密码,包括管理员凭据。此时风险已经超出文档被浏览,还可能涉及其他账户的访问权限。
Claroc 称,识别出的组织中有 6 家属于 Fortune 500,26 家拥有超过 1,000 名员工。企业规模并不能自动保证临时应用的发布设置得到检查。
删除自家应用,是否解决了整体问题
原文称,由 SpaceX 与 xAI 合并形成的 SpaceXSI,有 24 个员工创建的应用暴露。内容包括企业销售新人的保密入职计划、覆盖 594 个销售账户的地图、内部销售工具地址和广告提案。Engadget 的报道还列出了广告客户账户看板、活动报告和 X 品牌安全手册。
按照 Claroc 的说法,他们在周日通知了 SpaceXSI,随后在 X 上提及 Elon Musk 和 Grok 负责人 Matt Palmer。Ars Technica 向公司询问后的数小时内,这 24 个应用的链接被移除,访问时返回「app not found」。
Ars 于 11 月 10 日报道此事。11 月 11 日,Grok 称报道「incorrect」,强调涉及 grok.com 的应用构建功能,而非 Grok Build,并表示用户发布前会检查分享设置,也会收到警告。
这些回应需要分开看。产品归属关系影响责任描述是否准确;发布警告则关系到用户是否得到充分提示。它们都不能单独证明访问控制已经修复。Claroc 称,截至其报告发布时,其他用户和组织的应用仍可访问。
我的判断
这件事最有说服力的部分,是具体暴露样本和访问路径:地址可以被发现,应用允许匿名打开,其中部分承载真实业务资料。随机地址与发布警告,都没有改变这条路径。
但报道也有边界。统计比例存在未解释的不一致,敏感内容占比来自 Claroc 的估计,原文没有给出完整抽样方法,也没有提供修复后的全面复测结果。因此,可以据此讨论默认权限的风险,不能替它确认全部影响范围。
对内部应用,我更倾向于默认「Only You」,再按需要开放给「Invited Users」。这会增加协作步骤,却能减少用户漏改设置时的暴露范围。原文没有提供不同默认值的对照数据,这是一项基于权限设计的判断,并非作者已经验证的效果结论。
能拿来做什么
- 发布 AI 生成的内部工具前,用未登录窗口打开最终链接,确认页面和关联数据是否符合预期权限。
- 给应用增加分享功能时,明确区分「拿到链接即可访问」和「受邀用户登录后访问」,让默认选项匹配数据用途。
- 检查可下载代码、导出文件和附件是否包含密码。原文中的 18 个明文密码说明,只检查页面可见内容并不够。
- 处理暴露事件时,除移除已发现的链接,还应检查同类应用的默认设置和访问范围;单个链接返回「app not found」,只能证明该入口已经不可用。