2024年8月，我们遇到了一个LinkedIn 帖子，声称OpenAI正在训练并暴露来自私有GitHub仓库的数据。鉴于这一说法的严重性，我们的研究团队立即着手调查。

‍

快速搜索显示，相关仓库曾经是公开的，因为其页面仍被Bing索引。然而，当我们尝试直接在GitHub上访问这些页面时，遇到了404错误，这证实该仓库后来已被设为私有。

这引发了一个重要问题：ChatGPT如何能够基于不再公开访问的仓库内容返回答案？

‍

‍

‍

为了解决这个问题，我们多次向ChatGPT查询与该仓库相关的数据。每次，它都澄清说它没有直接访问实际数据，而是基于仓库名称生成假设性内容。我们了解到ChatGPT利用Bing作为其搜索引擎，因为它已公开发布。这一机制解释了为什么有人可以检索曾经公开但后来设为私有的仓库信息：数据在其公开阶段被索引，并保留在Bing的缓存中。

但还有两个问题：一旦仓库设为私有，所有实际内容会发生什么？还有哪些其他聊天可能遵循同样的模式？

‍

‍

发现我们自己暴露的仓库

‍

我们决定深入调查，看看我们组织的仓库是否可能已被暴露。在Bing上搜索Lasso组织下的仓库，发现我们自己的一个仓库已被索引。然而，由于该仓库已设为私有，在GitHub上访问它会返回404错误。

内部审查确认，该仓库在短暂的公开期后，已被重新设为私有。

出于好奇，我们测试了ChatGPT，看它是否能从索引页面提取数据。

虽然它有时会确认仓库的存在（多亏了Bing的索引），但并未提供任何实际数据。

‍

‍

‍

‍

然后一个令人担忧的可能性击中了我们：如果Bing已经索引了它，数据可能在某处被缓存，谁可能是访问它的更好人选呢？答案是Microsoft Copilot。毕竟，一切都在同一个家族里。

当Copilot返回仓库公开时的实际数据时，我们的怀疑得到了证实，它似乎检索到了"僵尸数据"的缓存快照 - 用户认为已经私有或删除的数据，但仍然可以访问。

‍

‍

‍

这一发现凸显了一个主要安全问题：

• "僵尸数据"：任何曾经公开的信息，即使只是短时间，都可能仍然可以被Microsoft Copilot访问和分发。
• 私有代码风险：这种漏洞对于那些因敏感数据性质而在被误发布为公开后又被保护起来的仓库特别危险。

‍

‍

‍

Bing缓存机制

‍

深入了解Bing的索引系统，我们发现了cc.bingj.com，一个由Microsoft拥有的域名，用于存储已索引页面的缓存版本。Bing在搜索结果旁边提供一个小箭头，允许用户查看页面的缓存版本，即使它们不再可访问。

‍

‍

‍

‍

‍ ‍

‍

扩大规模

‍

在意识到GitHub上的任何数据，即使只是短暂公开，都可能被像Copilot这样的工具索引和潜在暴露后，我们惊讶于这些信息可以多么容易地被访问。为了理解这个问题的全部范围，我们着手自动化识别"僵尸仓库"（曾经公开现在私有的仓库）并验证我们的发现。

‍

‍ ‍

第1步：收集公共仓库

我们使用Google BigQuery的githubarchive数据集，它记录了所有公共仓库活动。我们提取了2024年任何时候公开的、属于GitHub组织的仓库列表：

‍

‍

第2步：识别缺失的仓库

‍

然后，我们通过尝试在GitHub上访问每个仓库来检查其状态。

• 如果请求返回200 OK，则仓库仍然是公开的。
• 如果返回404，则仓库要么已被删除，要么已设为私有。

‍

第3步：从Bing提取缓存数据

对于每个不再公开的仓库，我们使用以下方式在Bing上搜索：

‍

并提取我们找到的任何缓存页面。

‍

第4步：扫描内容

使用内部工具，我们扫描提取的数据，寻找秘密、令牌、访问密钥和不公开可用的包（潜在的依赖混淆风险）

‍

‍

研究发现

• 研究期间使用Bing的缓存机制提取了20,580个GitHub仓库
• 16,290个组织受到Wayback Copilot的影响，包括Microsoft自己、Google、Intel、xx(国内企业避免麻烦)、Paypal、IBM、xx(国内企业避免麻烦)等
• 发现了100多个可能容易受到依赖混淆攻击的Python和Node.js内部包
• 暴露了300多个私有令牌、密钥和GitHub、Hugging Face、GCP、OpenAI等服务的密钥

‍

‍

‍

‍

‍

‍

报告与修复

‍

我们将发现通知了Microsoft，概述了已删除或私有的GitHub仓库仍可通过Bing的缓存和Copilot访问，以及这一功能通过暴露组织数据构成安全风险。我们还提醒了所有受影响的组织，并建议他们轮换或撤销任何受损的密钥。

Microsoft将此问题分类为低严重性，引用其"低影响"并断言这种缓存行为是可接受的。尽管如此，他们迅速作出响应，在两周内，Bing的缓存链接功能被移除，所有用户对cc.bingj.com域名的访问被禁用。

‍

回到我们开始的地方

尽管Bing的缓存链接功能被禁用，缓存页面仍然出现在搜索结果中。这表明修复只是临时补丁，虽然公共访问被阻止，但底层数据并未完全删除。

当我们重新审视对Microsoft Copilot的调查时，我们的怀疑得到了证实：Copilot仍然可以访问人类用户不再可用的缓存数据。简而言之，这个修复只是部分的，人类用户被阻止检索缓存数据，但Copilot仍然可以访问它。

‍

恶意使用Wayback Copilot

‍

2025年1月14日（在Microsoft修复后），我们偶然发现了另一个测试Wayback Copilot的机会。在Techcrunch的一篇文章中，我们了解到"Microsoft已对一个据称故意开发并使用工具绕过其云AI产品安全防护的团体采取法律行动"。文章提到该工具的仓库已从GitHub上移除。我们对这些仓库的内容感到好奇，决定与我们的老朋友聊天。尽管这些仓库已被移除（著名的GitHub 404），我们仍能够检索到恶意包的内容。

‍

‍

‍

utils.py仓库中的页面无法访问

‍

‍

使用Wayback Copilot从de3u仓库获取utils.py代码

‍

‍

‍

我们研究的关键发现

在当今的数字环境中，数据仍然是一种宝贵的资产，LLMs和生成式AI的爆炸性增长加剧了对独特数据集的竞争。这种压力正推动组织采取更具风险的数据获取策略 - 甚至诉诸黑暗模式 - 以在训练质量和回答准确性方面获得优势。以下是我们的主要见解：

‍

1. 一旦暴露，假定所有数据都已被泄露‍

现代组织必须在这样的假设下运行：任何离开其网络的数据，即使只是短暂公开，也可能被LLM引擎或主要搜索引擎摄取用于未来训练。保护和净化输出数据流比以往任何时候都更加关键。控制离开你参数的每一位数据。

‍‍

2. LLM引擎作为新的威胁载体

‍传统的威胁情报一直专注于扫描网络、论坛或暗网寻找泄露的数据。现在，LLMs和AI助手引入了一个新的风险：只需一个提示，敏感数据就可能暴露给广泛的受众。这代表了数据泄露可能发生方式的重大转变。
‍

3. 权限陷阱和过度热心的系统

‍我们的发现揭示了LLMs和检索增强生成（RAG）系统的两个众所周知的挑战：管理权限和系统固有的乐于助人特性。结合某些设计选择（在我们的案例中是Microsoft），这些问题可能导致过度共享敏感信息。在部署或开发你自己的系统时，确保用户只能访问他们有权查看的数据，并且你完全了解什么被索引和检索。
‍

4. 回归基础：基本数据卫生‍

尽管格局在不断发展，网络安全的基础仍然不变。始终验证你的仓库是私有的，避免在GitHub等平台上发布密钥或令牌，并通过使用官方包仓库（如PyPi、NPM）来缓解依赖混淆等风险。本质上，通过将私有信息和代码保持在组织边界内来保护它们。
‍

原文地址： https://www.lasso.security/blog/lasso-major-vulnerability-in-microsoft-copilot