当AI不是薄弱环节时：McHire 申请人数据泄露事件

发生了什么

2025年6月，安全研究员伊恩·卡罗尔（Ian Carroll）和山姆·库里（Sam Curry）披露了McHire（麦当劳的招聘平台，由Paradox.ai构建，并被绝大多数麦当劳特许经营店使用）中的一个漏洞链。Wired和BleepingComputer的公开报道称，暴露的数据集大约包含6400万份求职申请人的姓名、电子邮件地址、电话号码和聊天记录，任何采取与研究人员相同路径的人都可以访问这些信息。

传播最快的新闻标题将此事件描述为对聊天机器人“Olivia”的提示注入攻击。这种说法是错误的。研究人员表示，他们确实首先尝试了提示注入，但失败了：该机器人被严格限制在预设的回复中，并且从未拥有可以被诱骗泄露的后端数据。这次泄露与语言模型无关。

实际的入口点是McHire上一个可从公共互联网访问的Paradox.ai管理登录页面。研究人员在一个测试账户上尝试了凭据“123456”/“123456”，据公开报道，该账户自2019年以来一直处于活动状态。他们成功登录了。

一旦进入，申请人API上的一个经典的“不安全直接对象引用”（IDOR）漏洞允许他们递增数字ID并获取任何申请人的记录。没有利用模型，没有新颖的技术，也没有零日漏洞。只是默认凭据加上未经身份验证的对象引用。

为什么这种模式会反复出现

这里有趣的失败不是技术性的，而是组织性的。聊天机器人是可见的“AI”组件，因此它吸引了安全注意力。它背后无聊的Web管理界面才是实际的爆炸半径，几乎没有人以这种方式看待它。

当买家将AI供应商视为AI产品，而不是一个碰巧包含模型的SaaS应用程序时，就会发生这种情况。模型会进行红队审查。而管理控制台、申请人API、存储桶、审计日志、凭据轮换策略——这些具有数十年已知故障模式的东西——却被视为管道。

供应商的激励结构强化了这一点。AI供应商快速发布产品，通常在他们拥有成熟的安全程序之前，而客户的采购团队关注的是模型行为，而不是围绕它的应用程序。一个从2019年开始使用“123456”作为密码的测试账户之所以能存活多年，是因为没有人将审查范围设定为发现它。

未来两年最昂贵的AI泄露事件不会是模型漏洞。它们将是围绕模型的应用程序中存在的1990年代的Web漏洞。

攻击者的逐步攻略

披露的序列很短，这才是令人不安的部分。一个熟练的攻击者不需要一系列新颖的原始攻击手段。

步骤1：枚举AI供应商界面

识别可见聊天机器人背后的第三方供应商。在这种情况下，机器人自称由Paradox.ai构建，这指向了一个单独的管理界面——同一个McHire域上的登录页面。

步骤2：尝试显而易见的凭据

默认和弱凭据仍然是针对供应商管理面板的最高收益攻击。报告表明，一个使用“123456”/“123456”的测试账户就足够了。

步骤3：从管理员权限转向数据

管理员角色暴露了一个内部申请人API。该API使用顺序数字标识符，并且没有检查调用账户是否被授权读取每个特定的申请人。迭代ID会返回任意记录。

步骤4：确认范围并披露

研究人员在影响证明阶段停止，验证了数据集的大小，并向Paradox.ai和麦当劳报告。Paradox.ai禁用了测试账户，并据报道在披露后的几小时内修复了IDOR漏洞。

防御者错过了什么

三件事，按严重程度递减排列。

首先，供应商管理界面上没有凭据卫生。一个早于生产部署的测试账户，使用六位数字密码，在创建五年后仍可从公共互联网访问。任何定期的凭据审计都会发现它。

其次，申请人API上没有授权检查。IDOR是OWASP目录中最古老、记录最完善的Web漏洞之一。经过身份验证的管理员调用返回任意申请人记录的事实意味着API强制执行了身份验证，但没有强制执行授权。

第三，对无聊的界面没有进行安全审查。聊天机器人之所以受到关注，是因为它是AI。而管理登录、API网关以及6400万个人身份信息记录的存储却没有得到同样的审查——无论是在麦当劳、Paradox.ai，还是部署McHire的特许经营商那里。

实用的防御清单

修复措施并不光鲜。但它们正是可以防止此次事件发生的措施。

• 清点您使用的任何AI供应商暴露的所有身份验证界面，包括管理面板、测试环境和客户支持工具。将它们视为核心Web应用程序，而不是模型的管道。
• 要求供应商书面证明生产环境中不存在默认或共享凭据，并且在上线时删除在入职期间创建的测试账户。
• 对供应商暴露的每个API运行经过身份验证的IDOR/BOLA测试，特别是返回每个用户记录的API。OWASP API安全十大漏洞将此列为第一位是有充分理由的。
• 强制对每个供应商管理界面使用您的身份提供商进行SSO，这样凭据就不会独立漂移，并且当员工离职时，旧账户也会失效。
• 限制管理员会话权限，以便单个受损的管理员账户无法枚举整个申请人或客户数据集。
• 要求供应商记录并警报针对敏感API的大量读取模式。拉取数千万份申请人记录不应该看起来像一个正常的日子。

现代攻击测试如何能发现这一点

针对McHire供应商界面（而不是聊天机器人）进行有范围、经过授权的攻击性测试，会在第一个下午就发现这个问题。相关的检查是众所周知的：对管理员登录进行凭据喷射，对每个参数化API进行经过身份验证的横向访问控制，以及审查测试账户和重置工作流程。

在这个故事中，模型本身不需要红队。模型的行为是正确的。聊天机器人的防护措施也起作用了。教训是，对包装产品进行彻底的应用程序安全审查，会在攻击链上线之前就发现其中的每一个步骤。

接下来关注什么

预计会有更多此类事件发生。AI供应商正在吸收更多敏感的工作流程——招聘、索赔、客户服务、日程安排——而围绕这些工作流程的后端管理控制台现在集中了以前存储在难以触及的系统中的受监管个人数据。

在您自己的项目中要注意两件事：哪些AI供应商代表您持有最高浓度的受监管个人数据，以及您测试其管理界面的合同权利是什么样的。如果您无法对供应商的面板进行经过身份验证的应用程序安全审查，那么您就是在相信下一个测试账户已被删除，下一个API强制执行授权，以及下一个默认密码已被轮换。McHire的披露表明，当这种信任被错置时会发生什么。