DeepSeek 数据库……裸奔……百万敏感数据任人取……

qweasjd 6小时前 阅读数 3 #热点

  来源:云头条 作者:Wiz Research

  一个属于 DeepSeek 的可公开访问的数据库允许访客全面控制数据库操作,包括能够访问内部数据。

  Wiz Research发现了一个属于DeepSeek 的可公开访问的 ClickHouse 数据库,允许访客全面控制数据库操作,包括能够访问内部数据。

DeepSeek 数据库……裸奔……百万敏感数据任人取……
图片来源网络,侵删)

  泄露的信息包括 100 多万行日志流,其中包含聊天记录、密钥、后端详细信息及其他高度敏感的信息。

  Wiz Research 团队立即负责任地向 DeepSeek 披露了这个问题,后者迅速采取了安全措施。

  摘要

DeepSeek 数据库……裸奔……百万敏感数据任人取……
(图片来源网络,侵删)

  最近 DeepSeek 因其开创性的 AI 模型(尤其是 DeepSeek-R1 推理模型)而获得媒体的广泛关注。这款模型在性能方面比肩OpenAI 的o1 等领先的 AI 系统成本效益和效率方面脱颖而出。

  随着 DeepSeek 在 AI 领域掀起波澜,Wiz Research 团队开始评估其外部安全状况,以发现任何潜在的漏洞。

  Wiz Research 发现了一个与 DeepSeek 相连的可公开访问的 ClickHouse 数据库,完全敞开,未采取身份验证机制,暴露了敏感数据。

DeepSeek 数据库……裸奔……百万敏感数据任人取……
(图片来源网络,侵删)

  它被托管在 oauth2callback.deepseek.com:9000 和 dev.deepseek.com:9000。

  该数据库包含大量的聊天历史记录、后端数据和敏感信息,包括日志流、API 秘密信息和操作细节。

  更为关键的是,暴露的信息允许访客全面控制数据库,并在 DeepSeek 环境中进行潜在的特权升级,对外界没有任何身份验证或防御机制。

  我们的侦察从评估DeepSeek的可公共访问的域开始。

  通过利用简单的侦察技术(被动/主动发现子域)分析外部攻击面,Wiz Research 发现了约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文件(’文件名’)之类的查询,直接从服务器泄露明文密码、本地文件以及专有信息,具体取决于 ClickHouse 配置情况

  (注:为了确保安全研究遵循职业操守,我们没有执行枚举之外的侵入性查询。)

  几点感想

  在没有相应安全保障的情况下,迅速采用 AI 服务本身存在风险。这次泄露事件强调了这个事实:AI 应用的安全风险直接源于支持它们的基础设施和工具。

  虽然围绕 AI 安全的注意力大都集中在未来的威胁上,但真正的危险常常来自基本的风险,比如数据库意外暴露。防范这些风险应该是安全团队的当务之急。

  随着企业组织竞相采用越来越多的初创公司和供应商提供的 AI 工具和服务,有必要记住:如果这么做,我们无异于把敏感数据托付给了这些公司。迅速采用 AI 常常导致忽视安全,但保护客户数据必须仍然是首要任务。安全团队与 AI 工程师密切合作,确保深入了解所使用的架构、工具和模型,这一点至关重要,这样我们才可以保护数据、防止泄露。

  结语

  全球还没有哪一项技术像 AI 这样被迅速采用。

  许多 AI 公司已迅速成长为关键基础设施提供商,但缺少通常伴随这种广泛采用而来的安全框架。随着 AI 深度融入到全球企业中,业界必须认识到处理敏感数据的风险,并落实向公共云提供商和主要基础设施提供商要求的安全措施看齐的安全措施。

热门