数据泄露浪潮暴露安全漏洞
DeepSeek 和 Ollama 等开源大型语言模型 (LLM) 的迅速采用已成为一把双刃剑。虽然企业正在利用这些强大的工具来提高效率，但推动其增长的开放性也同时导致数据安全风险激增。NSFOCUS Xingyun Lab 最近发布的一份报告描绘了一幅严峻的图景：仅在 2025 年的前两个月，全球就发生了五起与 LLM 直接相关的重大数据泄露事件。这些事件导致大量敏感信息泄露，包括机密聊天记录、API 密钥和关键用户凭据。这些事件敲响了警钟，突显了隐藏在尖端人工智能技术表面之下的、经常被忽视的安全漏洞。本文将深入剖析这五起事件，分析攻击方法，将其映射到已建立的 MITRE ATT&CK 框架，并揭示企业必须紧急解决的安全盲点。
事件一：DeepSeek 数据库配置错误——私人对话的窗口
时间线： 2025 年 1 月 29 日
泄露规模： 数百万行日志数据，包括敏感聊天记录和访问密钥。
事件经过：
Wiz 的安全研究团队首先发现了这一问题。他们发现了一个暴露在公共互联网上的 ClickHouse 服务。进一步调查证实，该服务属于中国人工智能初创公司 DeepSeek。ClickHouse 旨在有效处理分析处理中的大型数据集，但不幸的是，它成为了 DeepSeek 内部数据的入口。研究人员访问了大约一百万行 DeepSeek 的日志流，发现了一个包含敏感信息的宝库，包括历史聊天记录和关键访问密钥。
Wiz 立即向 DeepSeek 通报了该漏洞，DeepSeek 立即采取行动并安全地处理了暴露的 ClickHouse 服务。
攻击分析：
核心问题在于 ClickHouse 容易受到未经授权的访问。ClickHouse 是一种开源的列式数据库管理系统，擅长实时查询和分析海量数据集，通常用于日志和用户行为分析。但是，如果在没有适当访问控制的情况下部署，其暴露的 API 接口允许任何人执行类似 SQL 的命令。
Wiz 安全团队的方法包括对 DeepSeek 面向互联网的子域进行系统扫描。最初专注于标准端口 80 和 443，他们发现了典型的 Web 资源，如聊天机器人界面和 API 文档。为了扩大搜索范围，他们扩展到不太常用的端口，如 8123 和 9000，最终发现了多个子域上暴露的服务。
泄露的日志数据可以追溯到 2025 年 1 月 6 日，其中包含大量敏感信息：通话记录、DeepSeek 内部 API 端点的文本日志、详细的聊天记录、API 密钥、后端系统详细信息和操作元数据。
VERIZON 事件分类： 杂项错误 (Miscellaneous Errors)
MITRE ATT&CK 框架映射：
- T1590.002 (收集受害者网络信息 - 域名解析): 攻击者可能使用主域名进行子域名枚举。
- T1046 (Web 服务发现): 攻击者识别了与目标域关联的开放端口和服务。
- T1106 (本机接口): 攻击者利用 ClickHouse API 与数据库交互。
- T1567 (通过 Web 服务进行数据泄露): 攻击者使用 ClickHouse API 窃取数据。
事件二：DeepSeek 供应链攻击——代码中的特洛伊木马
时间线： 2025 年 2 月 3 日
泄露规模： 用户凭据和环境变量。
事件经过：
攻击始于 2025 年 1 月 19 日，当时一个名为 ‘bvk’ 的恶意用户向流行的 PyPI (Python Package Index) 存储库上传了两个名为 ‘deepseek’ 和 ‘deepseekai’ 的恶意 Python 包。
Positive Technologies Expert Security Center (PT ESC) 的威胁情报团队在同一天检测到了这一可疑活动。他们的分析证实了这些软件包的恶意性质，并立即通知了 PyPI 管理员。
PyPI 管理员迅速删除了恶意软件包并通知了 PT ESC。尽管响应迅速，但统计数据显示，该恶意软件已通过各种渠道在 17 个国家/地区被下载了 200 多次。随后，恶意软件包被隔离。
攻击分析：
‘bvk’ 上传的恶意软件包主要集中在两个目标：信息收集和窃取环境变量。被盗数据包括敏感信息，如数据库凭据、API 密钥和 S3 对象存储的访问凭据。每当用户从命令行执行 DeepSeek 或 Deepseekai 时，就会触发恶意负载。
攻击者利用 PipeDream 作为命令和控制服务器来接收被盗数据。该事件突出了几个促成因素：
- 依赖混淆攻击： 攻击者利用了组织私有软件包和同名公共软件包之间的优先级差异。
- 软件包名称冒充： 恶意软件包模仿了知名人工智能公司 DeepSeek 的品牌名称，以欺骗用户。
- PyPI 注册弱点： PyPI 注册过程缺乏对开发者身份和软件包名称合法性的有效验证。
- 开发者安全意识： 开发者可能错误地安装了名称相似的恶意软件包。
VERIZON 事件分类： 社会工程学 (Social Engineering)
MITRE ATT&CK 框架映射：
- T1593.003 (搜索开放网站/域 - 搜索公开可用的依赖存储库): 攻击者在 PyPI 上搜索了信息。
- T1195.002 (供应链妥协 - 妥协软件供应链): 攻击者使用伪装成 Python 依赖项的恶意软件并将其上传到 PyPI。
- T1059.006 (命令和脚本解释器 - Python): 攻击者在软件包中植入了恶意代码，该代码在执行时会泄露敏感数据。
- T1041 (通过 C2 通道进行数据泄露): 攻击者通过 PipeDream C2 通道泄露了敏感信息。
事件三：LLM 劫持——DeepSeek 成为资源盗窃目标
时间线： 2025 年 2 月 7 日
泄露规模： 非法使用了大约 20 亿个模型 token。
事件经过：
Sysdig 威胁研究团队最初于 2024 年 5 月发现了一种针对 LLM 的新型攻击，称为 ‘LLM jacking’ 或 ‘LLM hijacking’。
到 2024 年 9 月，Sysdig 报告称，这些攻击的频率和普遍性不断增加，DeepSeek 越来越多地成为攻击目标。
2024 年 12 月 26 日，DeepSeek 发布了一个高级模型 DeepSeek-V3。不久之后，Sysdig 团队发现 DeepSeek-V3 已在 Hugging Face 上托管的 OpenAI 反向代理 (ORP) 项目中实现。
2025 年 1 月 20 日，DeepSeek 发布了一个名为 DeepSeek-R1 的推理模型。就在第二天，出现了一个支持 DeepSeek-R1 的 ORP 项目，攻击者开始利用它，用 DeepSeek API 密钥填充多个 ORP。
Sysdig 的研究表明，通过 ORP 非法使用的大型模型 token 总数已超过 20 亿。
攻击分析：
LLM 劫持涉及攻击者利用窃取的云凭据来攻击云托管的 LLM 服务。攻击者利用 OAI (OpenAI) 反向代理和窃取的凭据，本质上是出售对受害者订阅的 LLM 服务的访问权限。这会导致受害者产生巨大的云服务成本。
OAI 反向代理充当访问多个 LLM 帐户的中央管理点，掩盖了底层凭据和资源池。攻击者可以在不付费的情况下使用像 DeepSeek 这样的昂贵 LLM，通过反向代理引导请求，消耗资源，并绕过合法服务费用。代理机制隐藏了攻击者的身份，允许他们在不被发现的情况下滥用云资源。
虽然 OAI 反向代理是 LLM 劫持的必要组成部分，但关键要素是窃取各种 LLM 服务的凭据和密钥。攻击者通常利用传统的 Web 服务漏洞和配置错误（如 Laravel 框架中的 CVE-2021-3129 漏洞）来窃取这些凭据。获得这些凭据后，就可以访问基于云的 LLM 服务，如 Amazon Bedrock、Google Cloud Vertex AI 等。
Sysdig 的研究表明，攻击者可以在数小时内迅速将受害者的消费成本膨胀到数万美元，在某些情况下，每天高达 10 万美元。攻击者的动机不仅仅是获取数据；他们还通过出售访问权限获利。
VERIZON 事件分类： 基本 Web 应用程序攻击 (Basic Web Application Attacks)
MITRE ATT&CK 框架映射：
- T1593 (搜索开放网站/域): 攻击者使用 OSINT (开源情报) 方法收集有关暴露服务的信息。
- T1133 (外部远程服务): 攻击者识别了暴露服务中的漏洞。
- T1586.003 (妥协帐户 - 云帐户): 攻击者利用漏洞窃取 LLM 服务或云服务凭据。
- T1588.002 (获取能力 - 工具): 攻击者部署了一个开源的 OAI 反向代理工具。
- T1090.002 (代理 - 外部代理): 攻击者使用 OAI 反向代理软件来管理对多个 LLM 帐户的访问。
- T1496 (资源劫持): 攻击者发起 LLM 注入攻击以劫持 LLM 资源。
事件四：OmniGPT 数据泄露——用户数据在暗网上出售
时间线： 2025 年 2 月 12 日
泄露规模： 超过 30,000 名用户的个人信息，包括电子邮件、电话号码、API 密钥、加密密钥、凭据和账单信息。
事件经过：
2025 年 2 月 12 日，一个名为 ‘SyntheticEmotions’ 的用户在 BreachForums 上发帖，声称已从 OmniGPT 平台窃取了敏感数据并将其出售。据报道，泄露的数据包括超过 30,000 名 OmniGPT 用户的电子邮件、电话号码、API 密钥、加密密钥、凭据和账单信息，以及他们与聊天机器人进行的超过 3400 万行对话。此外，上传到平台的文件链接也遭到泄露，其中一些包含敏感信息，如优惠券和账单数据。
攻击分析：
虽然确切的攻击媒介尚未披露，但泄露数据的类型和范围表明了几种可能性：SQL 注入、API 滥用或社会工程学攻击可能使攻击者能够访问后端数据库。OmniGPT 平台也可能存在配置错误或漏洞，允许攻击者绕过身份验证并直接访问包含用户信息的数据库。
涉及二次泄露的 ‘Messages.txt’ 文件包含 API 密钥、数据库凭据和支付卡信息，可能导致进一步入侵其他系统或篡改数据。平台用户上传的一些文档包含敏感的商业机密和项目数据，如果被滥用，可能会对业务运营构成风险。这一事件清楚地提醒人们，人工智能和大数据领域需要加强数据安全和隐私保护。用户在使用这些平台时应格外谨慎，组织必须建立严格的数据使用策略，实施加密、数据最小化和匿名化等措施来保护敏感数据。否则，可能会导致严重的法律、声誉和经济后果。
VERIZON 事件分类： 杂项错误 (Miscellaneous Errors)
MITRE ATT&CK 框架映射：
- T1071.001 (应用层协议 - Web 协议): 攻击者可能通过 OmniGPT 的 Web 界面访问泄露的用户信息和敏感数据。
- T1071.002 (应用层协议 - 应用程序编程接口): 泄露的 API 密钥和数据库凭据可能允许攻击者通过平台的 API 访问系统并执行未经授权的操作。
- T1071.002 (应用层协议 - 服务执行): 攻击者可能滥用系统服务或守护进程来执行命令或程序。
- T1020.003 (自动数据泄露 - 文件传输): 泄露的文件链接和用户上传的敏感文件可能成为攻击者下载的目标，从而获取更多敏感数据以进行后续攻击。
- T1083 (文件和目录发现): 攻击者可以利用泄露的信息进一步获取关键的业务信息。
事件五：DeepSeek 凭据在 Common Crawl 中泄露——硬编码的危害
时间线： 2025 年 2 月 28 日
泄露规模： 大约 11,908 个有效的 DeepSeek API 密钥、凭据和身份验证 token。
事件经过：
Truffle 安全团队利用开源工具 TruffleHog 扫描了 Common Crawl 2024 年 12 月的 400 TB 数据，Common Crawl 是一个包含来自 4750 万个主机的 26.7 亿个网页的爬虫数据库。扫描结果令人震惊：大约 11,908 个有效的 DeepSeek API 密钥、凭据和身份验证 token 被直接硬编码到许多网页中。
该研究还强调了 Mailchimp API 密钥的泄露，大约有 1,500 个密钥被硬编码在 JavaScript 代码中。Mailchimp API 密钥经常被用于网络钓鱼和数据盗窃攻击。
攻击分析：
Common Crawl 是一个非营利性的网络爬虫数据库，定期捕获和发布来自互联网页面的数据。它将这些数据存储在 WARC (Web ARChive) 文件中，保留原始的 HTML、JavaScript 代码和服务器响应。这些数据集经常被用于训练人工智能模型。Truffle 的研究揭示了一个关键问题：在包含安全漏洞的语料库上训练模型会导致模型继承这些漏洞。即使像 DeepSeek 这样的 LLM 在训练和部署过程中采用了额外的安全措施，训练数据中广泛存在的硬编码漏洞也会使模型将此类 ‘不安全’ 做法正常化。
硬编码是一种常见但不安全的编码做法，是一个普遍存在的问题。虽然根本原因很简单，但风险却很严重：数据泄露、服务中断、供应链攻击，以及随着 LLM 的兴起，一种新的威胁——LLM 劫持。如前所述，LLM 劫持涉及攻击者使用窃取的凭据来利用云托管的 LLM 服务，从而给受害者造成巨大的经济损失。
VERIZON 事件分类： 杂项错误 (Miscellaneous Errors)
MITRE ATT&CK 框架映射：
- T1596.005 (搜索开放技术数据库 - 扫描数据库): 攻击者从公共爬虫数据库中收集信息。
- T1588.002 (获取能力 - 工具): 攻击者部署了一个敏感信息发现工具。
- T1586.003 (妥协帐户 - 云帐户): 攻击者使用敏感信息发现工具在公共数据库中查找敏感凭据。
- T1090.002 (代理 - 外部代理): 攻击者使用 OAI 反向代理软件来管理对多个 LLM 帐户的访问。
- T1496 (资源劫持): 攻击者发起 LLM 注入攻击以劫持 LLM 资源。
预防 LLM 数据泄露：多管齐下的方法
所分析的事件突出了对强大安全措施的迫切需求，以防止与 LLM 相关的数据泄露。以下是预防策略的细分，按相关事件分类：
加强供应链：
适用于事件二（恶意依赖包攻击）和事件五（公共数据泄露）：
依赖包的可信验证：
- 使用 PyPI/Sonatype Nexus Firewall 等工具拦截未签名或来源可疑的依赖包。
- 禁止在开发环境中直接从公共存储库获取依赖项。强制使用企业私有存储库代理（例如 Artifactory）。
供应链威胁监控：
- 集成 Dependabot/Snyk 等工具，自动扫描依赖项漏洞并阻止引入高风险组件。
- 验证开源软件包的代码签名，以确保哈希值与官方哈希值匹配。
数据源清理：
- 在训练数据收集期间，使用正则表达式和基于 AI 的编辑工具从公共数据集（如 Common Crawl）中过滤敏感信息，以进行双重验证。
实施最小权限和访问控制：
适用于事件一（数据库配置错误）和事件四（第三方工具数据泄露）：
- 默认情况下为数据库（如 ClickHouse）启用双向 TLS 身份验证，并防止在公共网络上暴露管理端口。
- 利用 Vault/Boundary 等解决方案动态分发临时凭据，避免长期保留静态密钥。
- 遵循最小权限原则，通过 RBAC (基于角色的访问控制) 将用户访问权限限制为仅必要的资源。
- 对第三方工具（如 OmniGPT）的 API 调用实施 IP 白名单和速率限制。
确保敏感数据的全生命周期保护：
适用于事件三（LLM 劫持）：
- 数据脱敏和加密： 对用户输入和输出数据强制执行字段级加密（例如 AES-GCM）。屏蔽日志中的敏感字段。
- 对 LLM 的交互内容启用实时编辑（例如，用占位符替换信用卡号和电话号码）。
这些预防措施，加上持续的安全监控和事件响应计划，对于降低与 LLM 使用日益增长相关的风险至关重要。LLM 安全的 ‘隐形战场’ 需要持续保持警惕，并采取积极主动的方法来保护这一快速发展的技术领域中的敏感数据。