审核呆子有话说:
从系统全局配置文件入手以便精准锁定框架入口和审计对象,对框架运行流程的分析足以体现作者深厚的代码审计功底。
大型的Java系统都会使用Commons Collections这个组件,当开发者在不慎使用readObject()时,便会产生严重的后果。功夫不负有心人,全静态审计并找出反序列化的触发点,导致远程命令执行。
(本篇分析源自2017年7月精品漏洞第三名,360众测第一人,jkg006)。
Section1:绪论
当你面对一个几个G的大型框架代码时候,怎么能够剥茧抽丝,把一个个小点放大到到处都是漏洞,这个就需要我们队javaweb框架进行整理的分析评估,因为拿到你手上的并不能调试,你只能根据代码功底,一个个的分析,找出来影响输入输出的点.
分析对象为某软件公司的大型财务软件。
Section2:漏洞分析
从一个javaweb的入口文件开始,我们分析web.xml
这个里面跟进去看看
如果以/~开始我们可以假设/~uap/UploadServlet 那么最后moduleName就是uap serviceName就是UploadServlet。
通过这里的getServiceobject来获取对应的路由规则,最后执行各个目标的service函数。
这里适用crl+t可以看出所以实现这个类的子类关系,里面的实例都有可能被调用,只要他满足上面两个条件,并且有service接口。当然,这个不是我们要解决的问题,我们要弄明白整体的框架调用关系,才能一本万利抓取更多的漏洞。
主要看看这个接口:
从这里分析,无非来自三处
1. moduleName 为空的时候,来自NCLocator
2. 不为空的时候来自serviceObjMap,当然了这个应该是个启动缓存,其实真正来源于BusinessAppServer,这个第一次初始化回存储到serviceObjMap里面,第二次调用就不会再反复去计算了。
跟进getContainer看:
这里的nameModulesMap是这个类初始化创建的,看它的init方法。
然后我们分析以下initEnv,初始化上下文。
这里初始化了所有的模块调用的上下文,不多继续深入了,我们举例子说明。刚才假设的是/~uap/UploadServlet,我们就去modules里面去找uap模块。
里面在meta-INF所有已upm结尾的就是它的配置文件,
modules\uap\meta-INF\S_uapbase63.upm 看看这里的结构
里面又属性为accessProtected ,这个为false就是不需要验证的,并且可以对外调用的,为true就是内部调用的接口。这里整个module以及全局配置文件的解析过程都在:
总体上来看就是解析.module文件,并且这个配置文件accessProtected="false"才可以被外部调用。搜索一下有多少个这样的:
这个将近有461处,放大这么多接口,肯定有很多漏洞。知道了所有的整体流程,那么才开始我们的漏洞检查。
这里直接进行了反序列化操作。构造payload