RirchFaces反序列化漏洞

JSF介绍

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

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

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的 补丁 禁增加了 contentProducer 来处理特殊符号 ([^\\(]*) 以缓解表达式注入问题。

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

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

CVE-2018-12532

漏洞 是在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. 限制1 EL总是会调用 Class.getMethods() 数组中名字相匹配的第一个方法,其他重载方法不会调用。
2. 限制2 Jasper’s EL 的实现(tomcat-jasper-el) 7.0.53 to
   8.0.25的一个bug导致不能通过反射调用无参方法。
3. 限制3只有Jasper的EL实现支持将参数列表隐式转换为args。其他的实现（例如jboss-el）args需要一个数组作为参数，所以需要构造一个数组。

最终的payload：

总结

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