藏青's BLOG

前言

1

最近审计遇到了一个环境存在反序列化漏洞但是没有利用链，于是尝试挖了下利用链，虽然最后没挖到，但是也对利用链挖掘的思路有了一些了解，在我挖掘的过程中也找了下文章，这方面的文章确实比较少，因此打算写篇文章介绍如何挖掘反序列化利用链，希望能对后来者提供一些帮助。

确定sink

​ 因为我也是第一次接触利用链的挖掘，刚上手也是感觉到无所适从，最好的方法当然是分析已有的利用链,下面是我总结了常见利用链的sink。

前言

1
2

本来是没想把这个洞单独写篇文章的，因为也看到其他师傅已经发表了相应的文章。主要的绕过原理也比较简单。即使用正则表达式匹配路径时.*不会匹配\r或\n，因此当url中包含换行符则springsecurity使用RegexRequestMatcher(".*",null)正则表达式去匹配就会匹配不到从而导致了权限绕过。
当我复现这个漏洞时却发现虽然绕过了springsecurity的拦截，但是却访问不到对应的Controller。为了解决这个问题才有了这篇文章。

1

最近在复习反序列化利用链的知识，尽管之前分析过spring1的利用链，再回头看还是发现其构造过程非常的精彩，再加上分析Spring利用链的文章比较少，因此决定写下Spring1反序列化利用链的分析过程。

分析过程

​ 漏洞的sink在MethodInvokeTypeProvider#readObject中这里通过反射完成方法调用，按照我们之前分析利用链的经验，遇到任意调用的反射肯定是想往Templates#newTransformer上构造，因为只有TemplatesImpl才能触发类加载并执行任意代码而不仅仅是简单的命令执行。

1

最近审计一个项目遇到了存在反序列化点但是没有利用链的情况，想尝试挖掘下利用链。目前挖掘利用链的工具主要是GadgetInspector和Tabby，原生的GadgetInspector跑了下效果并不理想而tabby可以根据自己的需要定制查询语法相对来说也比较灵活。本文主要是利用Tabby来分析下已知的利用链，一方面是熟悉tabby的使用和测试效果，另一方面是熟悉前辈们挖掘反序列化链的思路。

URLDNS

​ 在java.net.url类的equals方法中，判断url是否相等的条件有两个。

• 引用相同
• 请求的URL的协议、端口、文件名、IP相同

​ 最近学习了浅蓝师傅寻找的一些JNDI漏洞的利用链受益匪浅，自己也尝试关于JNDI漏洞利用做一些挖掘，目前JNDI在利用过程我想到了两个问题。

• 测试每一个JNDI Bypass 利用链都需要手动更改URL很不方便，能否我去请求一个地址，让目标将我所有的链跑一遍？
• JNDI利用过程中可以通过反序列化利用，能否自动化探测反序列化利用链？

​ 最近Log4j的漏洞引起了很多师傅对JNDI注入漏洞利用的研究，浅蓝师傅的文章探索高版本 JDK 下 JNDI 漏洞的利用方法提出了很多关于绕过JNDI高版本限制的方法，本文主要是对文章中的部分方法进行分析并加上一些我个人的思考。

前言

​ 最近想要针对Shiro的利用工具扩展利用链，但自己完全写一个工具即麻烦也没有必要，因此想要通过SummerSec师傅开源的工具**ShiroAttack2**扩展来实现，既然要扩展首先就得了解项目的源码实现。本片文章中我不会通篇的对这个项目代码进行分析，只抽出几个我认为的要点进行分析。

前言

​ 分析漏洞的本质是为了能让我们从中学习漏洞挖掘者的思路以及挖掘到新的漏洞，而CodeQL就是一款可以将我们对漏洞的理解快速转化为可实现的规则并挖掘漏洞的利器。根据网上的传言Log4j2的RCE漏洞就是作者通过CodeQL挖掘出的。虽然如何挖掘的我们不得而知，但我们现在站在事后的角度再去想想，可以推测一下作者如何通过CodeQL挖掘到漏洞的,并尝试基于作者的思路挖掘新漏洞。

前言

​ 这个漏洞爆发已经有好几天了，从影响来看这个漏洞影响范围确实很广，算是JAVA开发框架中一个比较基础的组件，之前和同事的前辈也讨论过，未来的发展可能会越来越依赖于集成框架，如果框架本身没有问题就没事，有问题就会导致毁灭性的灾难，这次漏洞也验证了我们之前的讨论。

前言

​ 在挖了一段时间的漏洞后，逐渐感觉挖洞变成了一个体力活，虽然也使用正则匹配的方式减少了部分工作量，但这种方式还是有很大的缺陷，准确率比较低，因此希望找到一种新的方式来辅助挖洞，最近CodeQL比较火，很多师傅也写了相应的文章，相对来说学习成本已经算比较低了。尽管看了很多师傅的文章，但感觉上自己对原理或者语法的学习还是比较迟钝，因此打算去分析师傅们已经写好的一些query语法，帮助自己理解。