代码审计CC2链，tfactory赋值，PriorityQueue新入口，如何？

代码审计 | CC2 链 —— _tfactory 赋值问题 PriorityQueue 新入口 目录 前言 环境 链路分析 Sink：TemplatesImpl 与 _tfactory 赋值问题 InvokerTransformer TransformingComparator（关键节点） PriorityQueue：入口点 EXP 编写 完整调用链追踪 为什么必须用 CC 4.0 小结 前言 CC3 里我们用 TemplatesImpl 实现了字节码加载，触发点是通过 InstantiateTransformer 调用 TrAXFilter 的构造方法，入口依然是 LazyMap 那套。CC2 在这个基础上换了个思路，sink 还是 TemplatesImpl.newTransformer()，但触发链完全换掉了，入口变成了 PriorityQueue，中间靠 TransformingComparator 串起来。 另外有个很重要的区别：CC2 用的是 Commons Collections 4.0，而不是之前的 3.2.1。原因后面分析到 TransformingComparator 的时候会说。 环境 JDK 8u65 Commons Collections 4.0（注意版本） IDEA + 调试器 pom.xml 依赖改成这样： <dependencies> <dependency> <groupId>org.apache.commons</groupId> <artifactId>commons-collections4</artifactId> <version>4.0</version> </dependency> </dependencies> 包名也从 org.apache.commons.collections 变成了 org.apache.commons.collections4，导包的时候注意一下。 链路分析 还是习惯从 sink 反推，找清楚每个节点怎么串起来的，再写 EXP。 Sink：TemplatesImpl 与 _tfactory 赋值问题 这个在 CC3 里分析过了，简单过一下。TemplatesImpl 里面有三个关键字段：_bytecodes（恶意字节码数组）、_name（不能为 null）和 _tfactory。 调用 newTransformer() 会触发 getTransletInstance() → defineTransletClasses() → 加载 _bytecodes 里的字节码并实例化，恶意代码在静态块或构造方法里就会执行。 这里展开说一下 _tfactory 到底要不要赋值的问题，这个之前文章里留了个坑。 半 payload 测试（未走反序列化） 之前的文章判断是说 defineTransletClasses 函数里有 _tfactory.getExternalExtensionsMap() 的调用，所以 _tfactory 必须赋值。