复现Ghidra Log4shell漏洞时POC无HTTP重定向问题咨询

已知现象梳理 #

• 测试环境：Ubuntu虚拟机，同时安装Java 1.8（POC运行依赖）、JDK 11（Ghidra v10.0.4运行要求），已为Ghidra配置对应JDK路径，程序可正常启动
• 首次测试表现：使用公开POC生成payload注入触发点后，LDAP监听器可收到请求，提示将转发至HTTP服务，但后续流程中断，无反弹连接
• 二次测试表现：手动搭建可正常访问的HTTP服务存放恶意Exploit.class文件，使用Marshalsec启动LDAP服务，将payload注入Ghidra帮助/搜索模块后，LDAP监听器收到2条请求，HTTP服务无任何访问日志，Ghidra直接弹出搜索无结果弹窗，反弹监听端口无连接

核心根因 #

复现失败的核心原因是JDK 11默认禁用LDAP远程类加载能力。
从JDK 8u191、JDK 11.0.1及所有更高版本JDK开始，Java默认将安全配置项com.sun.jndi.ldap.object.trustURLCodebase设为false，直接拦截JNDI LDAP场景下的远程类加载请求：目标收到LDAP服务返回的恶意类地址后，不会再发起HTTP请求下载恶意类，直接终止利用流程，这也是LDAP有请求但HTTP无访问的直接原因。
LDAP收到2条请求属于正常现象：Ghidra的搜索模块会对输入内容做两次Log4j日志打印（一次是输入实时变更记录、一次是搜索提交动作记录），因此会触发两次JNDI lookup，并非LDAP服务异常。
你参考的公开POC均基于Java 8早期无安全限制的版本编写，完全未适配高版本JDK的默认安全策略，在JDK11环境下无法直接跑通原始远程类加载利用链。

排查与调整步骤 #

• 临时放开JDK远程类加载限制
  修改Ghidra启动配置，在ghidraRun启动脚本或对应*.vmoptions配置文件中添加JVM参数-Dcom.sun.jndi.ldap.object.trustURLCodebase=true，重启Ghidra后按原有流程测试，这一步可以直接验证是否为JDK默认拦截导致的流程中断。
• 校验触发点有效性
  不要仅在搜索输入框测试payload：Ghidra中Log4j的有效触发点覆盖所有会被写入日志的字段，包括导入的二进制文件名、项目名、函数/符号重命名输入框、远程服务配置项等。搜索框输入如果仅走前端本地搜索逻辑、未被Log4j打印，会直接弹出无结果弹窗，根本不会触发JNDI lookup。
• 适配高版本JDK利用链
  如果放开参数后仍复现失败，放弃远程类加载思路，改用本地Gadget构造LDAP响应：不需要目标发起HTTP请求下载恶意类，直接在LDAP返回报文中携带基于目标本地依赖构造的执行Payload（比如基于BeanFactory的EL表达式执行、或Ghidra自带依赖中存在的反序列化Gadget），绕过远程类加载限制。
• 开启调试日志定位卡点
  启动Ghidra时添加JVM参数-Dlog4j2.debug=true，开启Log4j全量调试日志，可以直接看到lookup触发、LDAP请求发起、安全拦截的完整流程，快速定位卡断位置。

内容的提问来源于stack exchange，提问作者Ablia