RichFaces反序列化漏洞

jsf介绍

JavaServer Faces（JSF）是一个为网络应用程序构建基于组件的用户界面的Java规范[1]，并已通过JCP格式化为Java EE的一部分。

它也是一个MVC Web应用框架，通过在页面中使用可重用的UI组件简化了基于服务器的应用程序的用户界面（UI）。[8]

JSF implementations: Mojarra/Myfaces(javax.faces-api/ jsf-impl+jsf-api / myfaces-impl+myfaces-api)

EL interfaces (javax.el-api /tomcat-jasper-el)

EL implementations: Jasper/Jboss (tomcat-jasper-el/ jasper-el / jboss-el)

Richfaces的安全历史安全问题都出现在资源处理程序处理请求方式上，执行流程如下:

-> 获取处理过程相关的类，比如从URI中获取X，并且从参数do获取X的序列化状态对象

-(1)-> 反序列化状态对象

--(2)-> 创建X的一个实例并恢复其状态

---(3)-> 处理X并产生匹配的响应（图像、视频、表格等）

RichFaces 3

3.1.0 ≤ 3.3.3: CVE-2013-2165

3.1.0 ≤ 3.3.4: RF-14310

RichFaces 4

4.0.0 ≤ 4.3.2: CVE-2013-2165

4.0.0 ≤ 4.5.4: CVE-2015-0279

4.5.3 ≤ 4.5.17: RF-14309

CVE-2013-2165: Arbitrary Java Deserializationin RichFaces 3.x ≤ 3.3.3 and 4.x ≤ 4.3.2

漏洞分析以及Exp

https://tint0.com/matesctf-2018-wutfaces-cve-2013-2165/

CVE-2015-0279: Arbitrary EL Evaluation inRichFaces 4.x ≤ 4.5.3 (RF-13977)

漏洞触发

/richfaces-showcase/rfRes/org.richfaces.resource.MediaOutputResource.jsf?do=

Exp见https://issues.jboss.org/browse/RF-13977

RF-14310: Arbitrary EL Evaluation inRichFaces 3.x ≤ 3.3.4

漏洞触发

org.richfaces.renderkit.html.Paint2DResource/DATA/

跟漏洞CVE-2015-0279/RF-13799类似,问题出现在org.richfaces.renderkit.html.Paint2DResource 

这个类,当一个资源请求被调用,会调用他的send(ResourceContext)方法

,传递的参数是org.richfaces.renderkit.html.Paint2DResource$ImageData对象,如图:

TagMethodExpression类的orig属性中包含el表达式,我们在构造poc的时候需要将恶意的的el表到时set进去。

漏洞利用的思路就是需要构造一个恶意ImageData对象里面包含我们自动定义的el表达式,el表达式可以是远程加载一个jar,也可以也写文件、反弹shell等

附一张利用成功的截图

RF-14309: Arbitrary EL Evaluation inRichFaces 4.5.3 ≤ 4.5.17  NO CVE  By pass CVE-2015-0279

CVE-2015-0279的补丁[5]禁增加了contentProducer来处理特殊符号([^\(]*)以缓解表达式注入问题。

但是EL表达式支持定义函数映射和变量映射, 可以通过ELResolver解决函数(${prefix:name()})和变量（${var.property}）映射到方法和表达式value的实例，richface 4.5.3版本中各种VariableMapper已经然如白名单中。所以利用这个特性，只需要在contentProducer方法表达式中使用变量，如$ {dummy.toString}，并在方法表达式中添对应的VariableMapper，最终会映射到具体的ValueExpression。

具体利用在RF13977基础上修改下:

CVE-2018-12532[2] 

漏洞是在RF-14309基础上变形的payload稳定性更好。

Gadget的结构

Ljava.lang.Object[5]
 [0] = (java.lang.Boolean) false
 [3] = (javax.faces.component.StateHolderSaver)
   savedState = (org.apache.el.MethodExpressionImpl)
     expr = (java.lang.String) "foo.toString"
     varMapper =(org.apache.el.lang.VariableMapperImpl)
       vars = (Ljava.util.HashMap)
        {(java.lang.String)"foo":(java.lang.String)[EL_TO_INJECT]}

利用如下payload未能执行命令

https://blog.mindedsecurity.com/2015/11/reliable-os-shell-with-el-expression.html

https://srcincite.io/blog/2017/05/22/from-serialized-to-shell-auditing-google-web-toolkit-with-el-injection.html

EL表达式执行的三个限制

限制1 EL总是会调用Class.getMethods()数组中名字相匹配的第一个方法,其他重载方法不会调用。

限制2 Jasper’s EL 的实现(tomcat-jasper-el) 7.0.53 to 8.0.25的一个bug导致不能通过反射调用无参方法。

限制3只有Jasper的EL实现支持将参数列表隐式转换为args。其他的实现（例如jboss-el）args需要一个数组作为参数，所以需要构造一个数组。

最终的payload:

总结:

需要对漏洞组件和java的些特性非常熟悉才能找到更多的绕过方式。

[1]https://codewhitesec.blogspot.com/2018/05/poor-richfaces.html

[2]https://tint0.com/when-el-injection-meets-java-deserialization/#footnote1

[3]https://tint0.com/matesctf-2018-wutfaces-cve-2013-2165/

[4]https://docs.oracle.com/javaee/7/api/javax/el/ELResolver.html

[5]https://bugzilla.redhat.com/attachment.cgi?id=1005892

[6]https://examples.javacodegeeks.com/enterprise-java/jsf/jsf-elresolver-example/

[7]https://docs.oracle.com/javaee/7/api/javax/el/ValueExpression.html

[8] https://zh.wikipedia.org/wiki/JavaServer_Faces

[9] https://github.com/apache/tomcat/commit/b7ce5679b9e6a073dadbc31e6ecde12ad1e0ede8

本文作者：0c0c0f

本文为安全脉搏专栏作者发布，转载请注明：https://www.secpulse.com/archives/75882.html