成千上万套未加验证保护的数据库暴露于互联网

当今，数据库可以说是网络空间中每一项技术的实现基石。随着世界各地越来越多边缘智能设备接入互联网，敏感数据暴露的风险也在随之提升。过去几年，大规模数据泄露事件越来越司空见惯，百万甚至千万条记录的大规模泄露事件层出不穷。泄露的原因之一，就是直接接入互联网的数据库存在安全性差 / 未经验证保护的问题。

最近，RedHunt 实验室对网上公开的数据库状况进行了研究，结果令人震惊：

• 21387 个未经验证保护 / 公开的 MongoDB 数据库
• 20098 个暴露的 elasticsearch 实例
• 20528 个非安全 Redis 数据库
• 25575 个暴露在外的 Memcached 服务器
• 1977 个非安全 CouchDB 实例
• 3340 个 Cassandra 数据库暴露在互联网上
• 570 个暴露在互联网上的 RethinkDB 数据库
• 1846 个非安全 HBase 实例

通过对攻击面管理（ASM）门户“NVADR”的统计数据进行研究，RedHunt 实验室发现约 40% 的暴露问题涉及未受验证保护内容的意外公开。除了其中常见的源代码 repo、内部文档、查询系统 / 门户以及仪表板之外，最受关注也是最具安全影响的当然是未经验证保护的数据库。这些暴露在外的数据库不仅常被发现，而且往往会极大影响并增加相关组织的攻击面。

为了解互联网上公开的数据库安全现状，RedHunt 实验室选择了 8 种数据库作为研究对象，具体包括：

• MongoDB
• ElasticSearch
• Redis
• Memcached
• Apache CouchDB
• Apache Cassandra
• RethinkDB
• HBase

同时，他们还创建了一款扫描工具，力求以理想的速度与准确性覆盖整个互联网，同时避免触碰到排除清单中的对象。RedHunt 实验室决定在整个 IPv4 空间内使用统一的单个数据包扫描保持这一非侵入性要求。该工具的基本架构如下所示：

现在，看看他们的具体发现。

MongoDB

MongoDB 是一款跨平台且面向文档的开源数据库，也是目前使用类 JSON 存储对象的高人气 NoSQL 数据库方案之一。虽然最新的 MongoDB 版本已经采取了严格的 ACL 策略，但其 2.6.0 之前的版本仍默认监听所有接口上的连接。换句话说，默认安装下的 MongoDB 会直接向未经身份验证的互联网连接开放。

RedHunt 实验室共发现了 21387 个未经验证保护 / 公开的数据库。

幸运的是，最新版本的 MongoDB 现在只默认监听本地连接。但研究表明，这种暴露背后代表的不只是默认设置中的隐患，因为所发现的大部分非安全 MongoDB 其版本都要高于 2.6.0。下面来看关于非安全数据库版本的基本情况：

尽管 MongoDB 团队已经努力提出相关安全最佳实践，但大部分数据库仍然未受身份验证保护，而且对互联网直接开放。

Elasticsearch

Elasticsearch 是一款面向文档的 NoSQL 数据库，主要强调高性能搜索、分析与可视化。从本质上讲，Elasticsearch 为不同的软件版本实施了不同的 ACL 策略，具体策略因许可证而异。在 elasticsearch 说明文档中可以看到，如果“您使用免费 / 基本许可证，则默认情况下禁用 Elasticsearch 安全功能。”但对于其他企业许可证，则直接启用身份验证。

在研究中，RedHunt 实验室共确定了 20098 个暴露的 elasticsearch 实例。这些易受攻击的 IP 分布在 104 个国家共 982 座城市。

有趣的是，作为一个相当陈旧的版本，1.4.1 版居然在 elasticsearch 使用量中排名第二，共有 577 个相关实例。下图为各个版本的实际使用数量：

作为一项安全措施，最新版本的 ElasticSearch 会在默认安装中显示警告标头，提示“未使用内置的安全功能”。

Redis

Redis 是一套内存数据结构存储系统，可作为键值对数据库、缓存或消息代理使用。Redis 专为受信环境下的受信客户端所设计，因此本身并不具备强大的安全保护功能。尽管说明文档明确提到“除网络中的受信客户端外，其他各方均不应有权访问 Redis 端口”，但我们仍在互联网上发现了大量 Redis 数据库。

在研究中，RedHunt 实验室共发现了 20528 个非安全的 Redis 数据库。

由于 Redis 实例的部署量已经相当惊人，为了亡羊补牢，开发人员决定自 3.2.0 版本起引入“保护模式”——Redis 会仅回复来自环回接口的查询。通过其他地址进行接入的客户端会收到一条错误提示，说明应如何正确配置 Redis。尽管采取这项安全修复措施，但研究中发现的大部分公开 Redis 实例使用的正是 3.2 以上版本。

Memcached

与 Redis 类似，Memcached 是另一套通用型分布式内存缓存系统，通常用于数据库加速功能。在安全性方面，Memcached 同样不具备任何身份验证机制，而且默认监听所有接口。结合过往的拒绝服务放大攻击来看，这样的设置无疑具有巨大的安全风险。

令人震惊的是，RedHunt 实验室在研究中共发现 25575 个暴露在外的 Memcached 服务器。

Memcached 各版本的使用量如下图所示：

Apache CouchDB

CouchDB 是一款极具人气的 NoSQL 数据库，与 MongoDB 颇有相通之处。自诞生以来，CouchDB 一直遵循“默认开放”原则，这也导致默认安装配置极易受到攻击影响。

RedHunt 实验室共在互联网上发现 1977 个非安全的 CouchDB 实例。

值得庆幸的是，随着 3.0 版本的发布，CouchDB 开发人员终于决定用“默认安全”替代作死性质的“默认开放”方法。其要求我们在初始化数据库之前设置管理账户，因此能够大大降低风险水平——结合实际观察，网上公开暴露的大部分 CouchDB 数据库使用的版本也确实为 3.0 以下。

Apache Cassandra

Apache Cassandra 是一套开源 NoSQL 分布式数据库，强调可扩展性、高可用性与性能。但从安全角度来看，其默认安装配置很可能面临安全威胁。援引 Cassandra 说明文档中的解释：

在默认情况下，这些（安全）功能会被禁用，Cassandra 可被集群内其他成员轻松发现。换句话说，Cassandra 开箱即用的特性会给恶意攻击者提供巨大的攻击面。

在研究中，RedHunt 实验室共发现 3340 个 Cassandra 数据库以未经任何验证保护的形式暴露在互联网上。

下图所示，为易受威胁影响的各 Cassandra 版本。有趣的是，其中 v2.0.15 几乎占所有暴露数据库中的 70%。

RethinkDB

RethinkDB 也是一套开源数据库，利用带有动态模式的 JSON 文档进行实时数据处理。默认情况下，RethinkDB 提供一个具有全局范围内所有权限、但却未经密码保护的 admin 内置账户。有意思的来了：Web 管理界面将始终以 admin 权限接入，无需任何身份验证。更要命的是，用户根本无法在 Web 管理 UI 上启用身份验证功能。对这套数据库施加保护的唯一方法，就是变更集群监听连接的接口。

在研究中，RedHunt 实验室共发现 570 个暴露在互联网上的 RethinkDB 数据库。

令人意外的是，在暴露在外的数据库中出现了一个相当陈旧的版本——1.16.2-1（发布于 2015 年）。下图为各暴露 RethinkDB 的相关版本数量：

HBase

HBase 也被称为 Hadoop 数据库，是一种分布式大数据存储系统。Hadoop 生态系统相当复杂，涵盖 HDFS、YARN 以及 Zookeeper 等多个依赖项。很明显，其验证过程也相当复杂。HBase 需要通过严格遵循 SASL 的 Kerberos 在 RPC 层级上实现授权。同样的，HBase 的默认安装配置中没有任何身份验证要求 (hbase-default.xml)：

在研究中，RedHunt 实验室总计发现 1846 个非安全 HBase 实例。

Hadoop 还附带一套 WebUI 管理界面，允许外来者轻松访问甚至对文件系统（HDFS）进行全面的读取 / 写入操作。我们注意到，这些易受攻击的数据库还提供一个未经验证保护的 HTTP WebUI，直接通过端口 50070 暴露在互联网上。该 WebUI 的存在能够显著简化攻击者的入侵流程，因此进一步扩大了攻击面。

RedHunt 实验室还发现，大部分非安全数据库也同时开启了端口 2181（Zookeeper），相当于给攻击者留了另外一扇门。Hadoop 生态系统中各个组件的“协同参与”，显著增加了这套数据库的整体攻击面。

下图所示，为前十大易受攻击的 Hadoop 版本：

要点总结

聊聊可能导致暴露问题的各项因素：

默认设置不安全

在研究中，RedHunt 实验室发现这些数据库之间最惊人的相似之处，就是默认不带安全配置。有些朋友会认为这是为了实现可用性与安全性间的平衡，但必须承认这是个需要关注的大问题。

不可能指望用户在安装完成后主动添加各类安全保障方案。好消息是，部分数据库开发者已经开始采取“默认安全”策略来解决这个问题。

缺乏安全意识

在发现这么多暴露在互联网上的数据库后，RedHunt 实验室觉得开发人员的安全意识可能仍然比较淡薄。从以上统计数据可以清晰看出，尽管某些数据库也提供安全安装选项，但出于某种原因，最终结果仍然是直接暴露在网上。

在构建面向互联网的产品时，理解安全上下文非常重要。因此本文呼吁各位开发人员在设置任何基础设施之前，请务必认真阅读官方说明文档（特别是安全性配置部分）。

存在大量未跟踪资产，包括影子 IT 与高价值信息

如果未能及时发现，影子 IT（即未得到正确跟踪的已部署基础设施）可能导致关键数据意外泄露。作为“皇冠上的明珠”，高价值信息资产一旦受到损害，可能给组织造成重大业务影响。此类高价值资产需要在整个开发生命周期中得到持续的跟踪与管理，确保在暴露事件发生之前即得到关注与保护。

实际影响

数据库暴露很可能带来毁灭性的后果，包括现有数据外流、信息滥用、权限提升以及入侵等等。这类典型违规事件很可能给组织声誉造成破坏性影响，并严重冲击消费者对组织的评价与信心。

写在最后

如今，我们已经正式迎来万物互连的新时代。从以上统计数据可以看出，互联网上相当一部分数据库仍然极易受到攻击影响。这也让我们再次深切意识到，已经无数被强调的正确资产管理理念并没有得到实际推行。在本文的最后，要再给您提个醒——请马上检查一下，您的组织内有没有不该公开发布的数据库被暴露在外。