近年来,中国在人工智能领域取得了举世瞩目的成就,涌现出一批像 DeepSeek 这样的创新企业。然而,在追求技术突破的同时,安全问题不容忽视。DeepSeek 数据库的泄露事件再次敲响了警钟,提醒我们必须在技术发展与安全保障之间取得平衡,避免重蹈覆辙。
泄露不代表用户数据被恶意使用,此次检测仅揭示安全问题,此漏洞发现后已及时关闭,不要陷入恐慌。PS:其实你的每一条数据都是透明的。而且观察此漏洞,可以合理的猜测用于什么目的,在这生活何必在意隐私呢?
Wiz 研究揭露 DeepSeek 数据库暴露,泄露包括聊天记录在内的敏感信息
一个公开可访问的属于 DeepSeek 的数据库允许完全控制数据库操作,包括访问内部数据的能力。此次暴露包括超过一百万行的日志流,其中包含高度敏感的信息。
Wiz Research 发现了一个公开可访问的属于 DeepSeek 的 ClickHouse 数据库,该数据库允许完全控制数据库操作,包括访问内部数据的能力。此次暴露包括超过一百万行的日志流,其中包含聊天记录、密钥、后端细节和其他高度敏感的信息。Wiz Research 团队立即负责任地向 DeepSeek 披露了该问题,DeepSeek 迅速采取措施保护了暴露的数据。
在这篇博文中,我们将详细介绍我们的发现,并考虑其对整个行业的更广泛影响。
摘要
DeepSeek 是一家中国人工智能初创公司,因其突破性的人工智能模型,特别是 DeepSeek-R1 推理模型,最近受到了媒体的广泛关注。该模型在性能上可以与 OpenAI 的 o1 等领先的人工智能系统相媲美,并且因其成本效益和效率而脱颖而出。
随着 DeepSeek 在人工智能领域掀起波澜,Wiz Research 团队开始评估其外部安全态势并识别任何潜在的漏洞。
几分钟之内,我们发现了一个与 DeepSeek 相关的公开可访问的 ClickHouse 数据库,该数据库完全开放且未经身份验证,暴露了敏感数据。它托管在 oauth2callback.deepseek.com:9000 和 dev.deepseek.com:9000。
该数据库包含大量的聊天记录、后端数据和敏感信息,包括日志流、API 密钥和操作细节。
更重要的是,此次暴露允许完全控制数据库,并可能在 DeepSeek 环境内进行权限提升 ,而无需任何身份验证或针对外部世界的防御机制。
暴露过程
我们的侦察工作始于评估 DeepSeek 的公开可访问的域名。通过使用直接的侦察技术(对子域名进行被动和主动发现)绘制外部攻击面图,我们确定了大约 30 个面向互联网的子域名。大多数子域名看起来是良性的,托管着诸如聊天机器人界面、状态页面和 API 文档等元素——这些元素最初都没有表明存在高风险的暴露。
然而,当我们把搜索范围扩大到标准 HTTP 端口(80/443)之外时,我们检测到与以下主机相关的两个不寻常的开放端口(8123 和 9000):
- http://oauth2callback.deepseek.com:8123
- http://dev.deepseek.com:8123
- http://oauth2callback.deepseek.com:9000
- http://dev.deepseek.com:9000
经过进一步调查,这些端口指向一个公开暴露的 ClickHouse 数据库,该数据库完全无需任何身份验证即可访问——这立即引起了警觉。
ClickHouse 是一个开源的列式数据库管理系统,专为对大型数据集进行快速分析查询而设计。它由 Yandex 开发,广泛用于实时数据处理、日志存储和大数据分析,这表明此类暴露是非常有价值和敏感的发现。
通过利用 ClickHouse 的 HTTP 接口,我们访问了 /play 路径,该路径允许通过浏览器直接执行任意 SQL 查询。运行一个简单的 SHOW TABLES; 查询返回了可访问数据集的完整列表。
ClickHouse Web UI 输出的表格
其中,一个表 log_stream 非常突出,它包含带有高度敏感数据的大量日志。
log_stream 表包含超过 100 万个日志条目,其中包含特别有揭示性的列:
- timestamp – 日志日期从 2025 年 1 月 6 日开始
- span_name – 引用各种内部 DeepSeek API 端点
- string.values – 纯文本日志,包括聊天记录、API 密钥、后端详细信息和操作元数据
- _service – 指示哪个 DeepSeek 服务生成了日志
- _source – 暴露日志请求的来源,包含聊天记录、API 密钥、目录结构和聊天机器人元数据日志
这种级别的访问对 DeepSeek 自身的安全及其最终用户构成了严重风险。攻击者不仅可以检索敏感日志和实际的纯文本聊天消息,还可以使用诸如 SELECT * FROM file('filename') 之类的查询,根据其 ClickHouse 配置,从服务器直接提取纯文本密码和本地文件以及专有信息。
(注意:我们没有执行超出枚举范围的侵入式查询,以保持道德研究实践。)
主要收获
在没有相应安全措施的情况下快速采用人工智能服务本身就存在风险。此次暴露突显了一个事实,即人工智能应用程序的直接安全风险源于支持它们的基础设施和工具。
虽然围绕人工智能安全的大部分注意力都集中在未来威胁上,但真正的危险往往来自基本风险——例如意外的数据库外部暴露。这些风险是安全的基础,应仍然是安全团队的首要任务。
随着各组织竞相采用来自越来越多的初创公司和提供商的人工智能工具和服务,必须记住,通过这样做,我们将敏感数据委托给了这些公司。快速采用的步伐通常会导致忽视安全问题,但保护客户数据必须仍然是首要任务。安全团队必须与人工智能工程师紧密合作,以确保对所使用的架构、工具和模型具有可见性,以便我们可以保护数据并防止暴露。
结论
世界从未见过一项技术以人工智能这样的速度被采用。许多人工智能公司已迅速发展成为关键的基础设施提供商,但没有通常伴随如此广泛采用的安全框架。随着人工智能在全球范围内深入融入企业,该行业必须认识到处理敏感数据的风险,并强制执行与公共云提供商和主要基础设施提供商所要求的安全实践相媲美的安全实践。