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的序列化状态对象
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
漏洞分析以及Exp
https://tint0.com/matesctf-2018-wutfaces-cve-2013-2165/
漏洞触发
/richfaces-showcase/rfRes/org.richfaces.resource.MediaOutputResource.jsf?do=
Exp见 https://issues.jboss.org/browse/RF-13977
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等
附一张利用成功的截图
CVE-2015-0279的 补丁 禁增加了 contentProducer
来处理特殊符号 ([^//(]*)
以缓解表达式注入问题。
但是EL表达式支持定义函数映射和变量映射, 可以通过 ELResolver
解决函数 (${prefix:name()})
和变量 (${var.property})
映射到方法和表达式value的实例,richface 4.5.3版本中各种 VariableMapper
已经然如白名单中。所以利用这个特性,只需要在 contentProducer
方法表达式中使用变量,如 $ {dummy.toString}
,并在方法表达式中添对应的 VariableMapper
,最终会映射到具体的 ValueExpression
。
具体利用在RF13977基础上修改下:
漏洞 是在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未能执行命令
EL表达式执行的三个限制:
Class.getMethods()
数组中名字相匹配的第一个方法,其他重载方法不会调用。 最终的payload:
需要对漏洞组件和java的些特性非常熟悉才能找到更多的绕过方式。