ElasticSearch(CVE-2015-5531)漏洞复现 — 附玄机靶场Flag获取思路-迪斯科星球

⚠️ 免责声明本文仅用于网络安全学习与研究目的。请勿将文中技术用于非法用途，未经授权对他人系统进行测试属于违法行为。读者应遵守《中华人民共和国网络安全法》及相关法律法规。如因不当使用本文技术导致的任何法律责任，由使用者自行承担。

漏洞概述
环境搭建
漏洞原理分析
漏洞复现全流程
确认目标信息
创建快照仓库
创建第二个仓库（绕过前缀限制）
路径穿越读取文件
探索文件系统并查找 Flag
问题：snapshot-前缀干扰
结果解码与 Flag 提取
完整 Payload 速查表
修复建议

1. 漏洞概述

项目	内容
CVE 编号	CVE-2015-5531
漏洞名称	ElasticSearch 目录穿越漏洞
CVE 评分	CVSS 3.1: 5.0（中危）
影响版本	ElasticSearch 1.6.0及更早版本
漏洞类型	目录穿越/任意文件读取（Path Traversal）
漏洞特点	无需认证即可直接利用
CWE 分类	CWE-22: 路径遍历（Path Traversal）

漏洞描述

ElasticSearch 是一个分布式的 RESTful 搜索和分析引擎，广泛应用于日志分析、全文搜索等场景。ElasticSearch 提供了快照（Snapshot）和恢复（Restore）功能，允许用户将数据备份到指定的文件系统目录。

CVE-2015-5531 是 ElasticSearch 快照功能中的一个目录穿越漏洞。在受影响版本中，ElasticSearch 在处理快照 API 请求时，未对用户传入的快照名称进行充分的路径校验。攻击者可以通过在快照名称中插入 "../" 等路径穿越字符，突破 ElasticSearch 的目录限制，实现读取服务器上任意文件的目的。

在 ElasticSearch 1.5.1 及更早版本中，无需任何额外配置即可触发该漏洞；在 1.6.0 版本中，需要在 elasticsearch.yml 配置文件中设置 path.repo 参数后才能利用。

漏洞发现者：Benjamin Smith

参考链接：https://www.exploit-db.com/exploits/38383/

2. 环境搭建

本次复现使用 Vulhub 漏洞环境搭建的 ElasticSearch 1.4.4 服务器。

目标信息：

• 目标地址：http://69.230.242.247:9200

• ElasticSearch 版本：1.4.4

• 集群名称：elasticsearch

• 节点名称：Lucifer

环境搭建方式（Docker）：

3. 漏洞原理分析

3.1 快照功能简介

ElasticSearch 的快照（Snapshot）功能允许用户将集群中的数据备份到指定的文件系统目录中。其核心 API 调用流程如下：

1. 创建快照仓库（Repository）：指定仓库类型（如 fs 文件系统）和存储路径

2. 创建快照（Snapshot）：在指定仓库中创建一个快照

3. 恢复快照（Restore）：从快照中恢复数据

3.2 漏洞成因

漏洞出现在快照名称的处理过程中。当用户请求快照恢复时，ElasticSearch 会构造以下文件路径：

关键问题在于：{快照名称} 参数直接来自用户输入的 URL，ElasticSearch 未对其进行充分的路径校验。攻击者可以将快照名称设置为包含 "../" 路径穿越序列的字符串，从而突破仓库目录的限制，读取系统上的任意文件。

影响范围：

• ElasticSearch 1.0.x ~ 1.4.x：全部受影响，无需任何配置

• ElasticSearch 1.5.x：1.5.0 ~ 1.5.1 受影响，需要配置 path.repo

• ElasticSearch 1.6.0：受影响，需要配置 path.repo

• ElasticSearch 1.6.1 及以上：已修复

4. 漏洞复现全流程

5. 探索文件系统并查找 Flag

5.1 问题：snapshot-前缀干扰

在复现过程中，最容易遇到的问题就是 "snapshot-" 前缀与路径穿越字符的连接问题。

问题描述：

如果直接使用类似 "backdata/../../../../../flag" 的快照名称，ElasticSearch 构造的路径为 "snapshot-backdata/../../../../../flag"。由于 "snapshot-backdata" 不是实际的目录（只是文件名的前缀），操作系统无法正确解析路径，会报 "No such file or directory" 错误。

解决方案：

使用两个仓库的技巧：第一个仓库创建基础目录，第二个仓库创建 "snapshot-ev1l" 子目录作为路径匹配点，使 "snapshot-" 前缀能正确落在目录上，从而正常执行路径穿越。

5.1.1为什么会出现这个错误？

当 ES 构造文件路径时，路径为：/tmp/test/snapshot-backdata/../../../flag。

问题在于 "snapshot-backdata/" 这个路径组件：

ES 将快照名称 "backdata/../../../flag" 前缀添加 "snapshot-"
得到 "snapshot-backdata/../../../flag"
系统尝试访问 /tmp/test/snapshot-backdata/
但该文件（或目录）并不存在
由于中间路径不存在，后续的 ../ 无法执行
最终报 FileNotFoundException

5.1.2 两个仓库技巧的详细解析

两个仓库技巧实际上是在目录结构上制造了一个与 "snapshot-{name}" 格式完全匹配的目录。

5.1.3 为什么需要两个仓库才能绕过去？

简单来说：第一个仓库创建了基础目录（dsr/），第二个仓库通过在基础目录下创建一个名为 "snapshot-ev1l" 的子目录，使得后续的路径穿越可以直接从这个子目录出发。

5.1.4 结果解码与 Flag 提取

第 4.4 步返回的错误信息中包含了一个字节数组（以逗号分隔的十进制整数列表）。每个数字代表读取到的文件内容的 ASCII 码。需要将这些数字转换为可读的文本。

5.2 扩展知识：CVE-2014-3120 RCE

CVE-2014-3120 是 ElasticSearch 的另一个经典漏洞，允许通过动态脚本执行任意系统命令。该漏洞影响 ElasticSearch 1.2.0 及更早版本（部分 1.4.x 配置下仍可触发）。

漏洞原理：

ElasticSearch 的 MVEL 和 Groovy 脚本引擎允许用户在搜索请求中执行脚本。由于沙箱机制不完善，攻击者可以通过脚本调用 Java 的 Runtime.exec() 执行系统命令。

Payload 示例：

⚠️ 本次复现目标（ES 1.4.4）中，Groovy 动态脚本已被禁用，因此 CVE-2014-3120 无法直接利用。但在部分未正确配置的环境中仍可尝试。

5.3 结果解码与 Flag 提取

漏洞利用返回的错误信息中包含一个字节数组（整数列表），每个数字代表文件内容的 ASCII 码。需要使用 Python 等工具将其解码为可读文本。也可使用ai去自动解码。

解码后的 /etc/passwd 文件内容：✅ 最终得到 flag: {xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}

6. 完整 Payload 速查表

操作	命令/Payload
确认目标信息	curl http://target:9200/
创建仓库 pwn	curl -XPUT "http://target:9200/_snapshot/pwn" -H "Content-Type: application/json" -d '{"type":"fs","settings":{"location":"dsr"}}'
创建仓库 pwnie	curl -XPUT "http://target:9200/_snapshot/pwnie" -H "Content-Type: application/json" -d '{"type":"fs","settings":{"location":"dsr/snapshot-ev1l"}}'
路径穿越读取文件	curl "http://target:9200/_snapshot/pwn/ev1l%2f..%2f..%2f..%2f..%2f..%2f..%2fetc%2fpasswd"
字节数组解码	python3 -c "data=[...]; print(bytes(data).decode())"