Pre-auth RCE in ForgeRock OpenAM (CVE-2021-35464) 分析

  • A+
所属分类:安全文章
在portswigger老外发了一篇文章是关于OpenAm应用的RCE漏洞,这个漏洞是一个反序列化漏洞,这个漏洞是由于攻击者可以通过Version这个控制器传递jato.session数据,jato的处理流程会将这个数据丢给分发器,由分发器交给具体的viewbean展示,至于为什么jato.session数据是一个序列化数据,并且需要传递到version的viewbean,个人猜测是为了会话持久化。


可以比较明显的看到漏洞触发点是在Encoder的反序列化方法

Pre-auth RCE in ForgeRock OpenAM (CVE-2021-35464) 分析


接下来就需要后向查找,可以在Viewbeanbase类针对页面参数的反序列化方法中看到jata.session的值是可控的

Pre-auth RCE in ForgeRock OpenAM (CVE-2021-35464) 分析

这里接着后向查找,如果这里不熟悉jato的处理流程,则会被误导到AMViewBeanBase类的deserializePageAttributes方法

Pre-auth RCE in ForgeRock OpenAM (CVE-2021-35464) 分析

然后继续跟进父类,则最终会被误导ConsoleViewBeanBase的deserializePageAttributes方法,

Pre-auth RCE in ForgeRock OpenAM (CVE-2021-35464) 分析

然后最终会认为反序列化入口点在IOUtils的反序列化方法

Pre-auth RCE in ForgeRock OpenAM (CVE-2021-35464) 分析

但是在jato的实际处理流程中,在分发器预处理数据准备交给Viewbean给用户展示的时候,会调用invokeRequestHandler方法,在invokeRequestHandler方法中会调用deserializePageAttributes方法,这里动态调试可以看到实际上调用的是VersionViewBean这个类的deserializePageAttributes方法,但是这个类并没有实现deserializePageAttributes方法,所以只能找它的父类ViewBeanBase的deserializePageAttributes方法去完成处理。


然后需要寻找哪个地方调用了ViewBean的invokeRequestHandler方法,这里的后向寻找会比较耗精力,最后会发现在ApplicationServletBase类,也就是控制器类的dispatchRequest方法会调用ViewBean的invokeRequestHandler方法,这里也是jato的流程。

用户请求 ->

ApplicationServletBase的doGet负责处理 ->

ApplicationServletBase.processRequest方法 ->

ApplicationServletBase.getViewBeanInstance获取 viewbean ->

ApplicationServletBase.dispatchRequest 方法 ->

ViewBean的invokeRequestHandler方法

Pre-auth RCE in ForgeRock OpenAM (CVE-2021-35464) 分析


这里用click1 生成恶意序列化数据

java -jar ysoserial-0.0.6-SNAPSHOT-all.jar Ck1 "open -a Calculator" | (echo -ne \x00 && cat) | base64 | tr '/+' '_-' | tr -d '='
java -jar ysoserial-0.0.6-SNAPSHOT-all.jar Ck1 "open -a Calculator" | (echo -ne \x00 && cat) | base64 | tr '/+' '_-' | tr -d '=' > click1.ser

 

:由于漏洞管理法的原因,POC暂不公开。

这里补充一下作者是如何解决jato内部数据流转的问题,也就是说他是如何发现这个问题的。

首先筛出所有的servlet,也就是控制器,有33个,随便挑一个在web.xml定义的servlet请求试试

Pre-auth RCE in ForgeRock OpenAM (CVE-2021-35464) 分析


这里拿SCServlet试试

Pre-auth RCE in ForgeRock OpenAM (CVE-2021-35464) 分析


然后会发现它会自己转发流程,不会走jato后续的分发器

Pre-auth RCE in ForgeRock OpenAM (CVE-2021-35464) 分析


发现三个servlet实现了 onBeforeRequest方法,

Pre-auth RCE in ForgeRock OpenAM (CVE-2021-35464) 分析


剔除掉这三个servlet及其子类

Pre-auth RCE in ForgeRock OpenAM (CVE-2021-35464) 分析

也就是说从33个servlet中,删掉这15个,然后删掉之后,再去web.xml中对比,把没有路由的servlet再删掉,就只剩了


Pre-auth RCE in ForgeRock OpenAM (CVE-2021-35464) 分析

然后访问这5个的路由,比如PWResetServlet,


Pre-auth RCE in ForgeRock OpenAM (CVE-2021-35464) 分析

Pre-auth RCE in ForgeRock OpenAM (CVE-2021-35464) 分析


它只能加载这个包名下的viewBean,查看Viewbean接口的所有实现,找到这个包下面的viewbean,带入


比如这里用PWResetQuestionViewBean

Pre-auth RCE in ForgeRock OpenAM (CVE-2021-35464) 分析

可以看到是没有问题的,只要传递参数就行了。


作者这里用了VersionServlet,VersionServlet 只能加载com.sun.web.ui.servlet.version 包下面的viewBean,所以versionServlet只能加载这四个

Pre-auth RCE in ForgeRock OpenAM (CVE-2021-35464) 分析


我们随意换一个viewBean

Pre-auth RCE in ForgeRock OpenAM (CVE-2021-35464) 分析


你会发现也可以执行成功。至此这个反序列化的链路就通了,剩下的就是漏洞利用,作者用他自己开发的工具发现了click1这个gadgets,完成了漏洞利用。


Reference:

https://juejin.cn/post/6844903536174563342

http://www.corej2eepatterns.com/Patterns/ServiceToWorker.htm


本文始发于微信公众号(穿云箭安全实验室):Pre-auth RCE in ForgeRock OpenAM (CVE-2021-35464) 分析

发表评论

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen: