如何通过SemmleQL找到ApacheStruts的远程执行代码.
如何通过Semmle QL找到Apache Struts的远程执行代码.,相信很多没有经验的人对此束手无策,为此本文总结了问题出现的原因和解决方法,通过这篇文章希望你能解决这个问题。
创新互联公司是一家专业提供高县企业网站建设,专注与网站设计、成都做网站、HTML5建站、小程序制作等业务。10年已为高县众多企业、政府机构等服务。创新互联专业网站建设公司优惠进行中。
前言
2018年4月,一个新的Apache Struts远程代码执行漏洞被报告。在Struts特定配置下,访问特制的URL可以触发该漏洞。漏洞编号为CVE-2018-11776(S2-057)。本文将介绍发现漏洞的过程。
映射攻击面
许多漏洞涉及从不受信任的源(例如,用户输入)流向某个特定位置的数据,这种情况下数据会以危险的方式被利用(SQL查询,反序列化以及一些其他解释语言等等)。对于特定项目,开始着手研究此类问题的一种好方法是查看旧版本软件的已知漏洞。这可以让你深入了解所想要查找的各种源及接收点。
在本案例中,作者首先查看了RCE漏洞S2-032(CVE-2016-3081),S2-033(CVE-2016-3687)和S2-037(CVE-2016-4438)。与Struts中的许多其他RCE一样,这些RCE涉及被认为是OGNL表达式的非法输入,允许攻击者在服务器上运行任意代码。这三个漏洞特别有趣,不仅因为它们让我们对Struts的内部工作有了一些了解,而且还因为同样的问题需要三次才能修复!
所有这三个问题都是远程输入通过变量methodName作为参数传递给方法OgnlUtil::getValue()的结果。
String methodName = proxy.getMethod(); //<--- untrusted source, but where from?LOG.debug("Executing action method = {}", methodName);String timerKey = "invokeAction: " + proxy.getActionName();try { UtilTimerStack.push(timerKey); Object methodResult; try { methodResult = ognlUtil.getValue(methodName + "()", getStack().getContext(), action); //<--- RCE
这里的proxy字段是ActionProxy类型,它是一个接口。在查看它的定义时,作者发现除了方法getMethod()(在上面的代码中用于赋值的变量methodName)之外,还有各种其他的方法,如getActionName()和getNamespace()。这些方法貌似会从URL返回信息。所以作者开始假设所有这些方法都可能返回不受信任的输入。
现在可以使用QL开始对这些不受信任的来源进行建模:
class ActionProxyGetMethod extends Method { ActionProxyGetMethod() { getDeclaringType().getASupertype*().hasQualifiedName("com.opensymphony.xwork2", "ActionProxy") and ( hasName("getMethod") or hasName("getNamespace") or hasName("getActionName") ) }}predicate isActionProxySource(DataFlow::Node source) { source.asExpr().(MethodAccess).getMethod() instanceof ActionProxyGetMethod}
识别OGNL接收点
现在已经识别并描述了一些不受信任的来源,下一步是为接收点做同样的事情。如前所述,许多Struts RCE涉及将远程输入解析为OGNL表达式。Struts中有许多函数最终将它们的参数作为OGNL表达式进行评估;对于在本文中开始的三个漏洞,都使用了OgnlUtil::getValue(),但是在漏洞S2-045(CVE-2017-5638)中,使用了TextParseUtil::translateVariables()。我们可以寻找用于执行OGNL表达式的函数,而不是将每一个方法描述为QL中的单独接收点。而OgnlUtil::compileAndExecute()和OgnlUtl::compileAndExecuteMethod()看起来像有希望的接收点。
作者在一个QL predicate中描述了它们,如下所示:
predicate isOgnlSink(DataFlow::Node sink) { exists(MethodAccess ma | ma.getMethod().hasName("compileAndExecute") or ma.getMethod().hasName("compileAndExecuteMethod") | ma.getMethod().getDeclaringType().getName().matches("OgnlUtil") and sink.asExpr() = ma.getArgument(0) )}
第一次尝试污点跟踪
现在已经在QL中定义了源和接收点,所以可以在污点跟踪查询中使用这些定义。 这里作者使用DataFlow库来定义DataFlow配置:
class OgnlTaintTrackingCfg extends DataFlow::Configuration { OgnlTaintTrackingCfg() { this = "mapping" } override predicate isSource(DataFlow::Node source) { isActionProxySource(source) } override predicate isSink(DataFlow::Node sink) { isOgnlSink(sink) } override predicate isAdditionalFlowStep(DataFlow::Node node1, DataFlow::Node node2) { TaintTracking::localTaintStep(node1, node2) or exists(Field f, RefType t | node1.asExpr() = f.getAnAssignedValue() and node2.asExpr() = f.getAnAccess() and node1.asExpr().getEnclosingCallable().getDeclaringType() = t and node2.asExpr().getEnclosingCallable().getDeclaringType() = t ) }}from OgnlTaintTrackingCfg cfg, DataFlow::Node source, DataFlow::Node sinkwhere cfg.hasFlow(source, sink)select source, sink
这里作者使用了之前定义的isActionProxySource和isOgnlSink predicates。
需要注意的是,作者还覆盖了一个名为isAdditionalFlowStep的predicate。这个predicate允许包含可以传播非法数据的额外步骤。例如,这允许将项目特定的信息合并到流配置中。再如,如果有通过某个网络层进行通信的组件,则可以在QL中描述那些各种网络端点的代码,允许DataFlow库跟踪非法数据。
对于此特定查询,作者添加了两个额外的流程步骤供DataFlow库使用。 第一个:
TaintTracking::localTaintStep(node1, node2)
包含标准QL TaintTracking库来跟踪标准Java库调用,字符串操作等。第二个是一个近似值,允许通过字段访问跟踪非法数据:
exists(Field f, RefType t | node1.asExpr() = f.getAnAssignedValue() and node2.asExpr() = f.getAnAccess() and node1.asExpr().getEnclosingCallable().getDeclaringType() = t and node2.asExpr().getEnclosingCallable().getDeclaringType() = t)
这表示如果将字段分配给某个非法值,只要表达式都由相同类型的方法调用,那么对该字段的访问也将被视为非法。查看以下案例:
public void foo(String taint) { this.field = taint;}public void bar() { String x = this.field; //x非法,因为字段被分配给`foo`中的非法值}
如你所见,bar()中this.field的访问可能并不总是非法。例如,如果在bar()之前未调用foo()。那么不会在默认的DataFlow::Configuration中包含此流程步骤,因为我们无法保证数据始终以这种方式流动。但是,对于找到漏洞,将它们包含在DataFlow::Configuration中就很有用。
初始结果和查询细化
在最新版本的源代码上运行查询,并开始检查结果,S2-032,S2-033和S2-037仍然被查询标记。在查看其他结果之前,先调查为什么即使代码已修复,这些特定的结果仍然被标记。
虽然最初通过过滤输入来修复第一个漏洞,但是在S2-037之后,Struts团队决定通过调用OgnlUtil::getMalue()替换对OgnlUtil::getMalue()的调用来修复漏洞。
methodResult = ognlUtil.callMethod(methodName + "()", getStack().getContext(), action);
方法callMethod()封装对compileAndExecuteMethod()的调用:
public Object callMethod(final String name, final Mapcontext, final Object root) throws OgnlException { return compileAndExecuteMethod(name, context, new OgnlTask
并且compileAndExecuteMethod()在执行之前对表达式执行额外检查:
privateObject compileAndExecuteMethod(String expression, Map context, OgnlTask task) throws OgnlException { Object tree; if (enableExpressionCache) { tree = expressions.get(expression); if (tree == null) { tree = Ognl.parseExpression(expression); checkSimpleMethod(tree, context); //额外检查 }
这意味着我们实际上可以从接收点中移除compileAndExecuteMethod()。
在重新运行查询后,高亮的getMethod()作为接收点的调用的结果消失了。但是,仍然有一些结果突出显示了DefaultActionInvocation.java中的代码,这些代码被认为是已经被修复的,例如对getActionName()的调用,并且这里的数据路径并不是很明显。
路径探索和进一步查询细化
为了研究为什么这个结果被标记,就需要看到DataFlow库用来产生这个结果的每个流程步骤。QL允许编写特殊的路径问题查询,这些查询可生成可逐节点探索的可变长度路径,DataFlow库允许编写输出此数据的查询。
LGTM本身没有路径问题查询的路径探索UI,因此需要使用另一个Semmle应用程序:QL for Eclipse。这是一个Eclipse插件,其中包含一个可视化工具,允许完成污点跟踪中的各个步骤。用户可以免费下载并安装此Eclipse插件。它不仅可以在LGTM.com上对开源项目进行离线分析,还可以提供更强大的开发环境。下文的查询可以在semmle-security-java目录下的Semmle/SecurityQueries Git存储库中找到。你可以按照README.md文件中的说明在Eclipse插件中运行它们。
首先,在initial.ql中运行查询。 在QL for Eclipse中,从DefaultActionInvocation.java中选择结果后,你可以在Path Explorer窗口中看到从源到接收点的详细路径。
在上图中,你可以看到,经过几个步骤后,调用getActionName()返回的值会流入对pkg.getActionConfigs()返回的对象的get()调用中的参数:
String chainedTo = actionName + nameSeparator + resultCode
actionName来自某个地方的`getActionName`
ActionConfig chainedToConfig = pkg.getActionConfigs().get(chainedTo)
//chainedTo包含`actionName`并最终出现在`get`方法中
单击下一步,就到了ValueStackShadowMap::get()方法,如下所示:
public Object get(Object key) { Object value = super.get(key); //<--- key gets tainted? if ((value == null) && key instanceof String) { value = valueStack.findValue((String) key); //<--- findValue ended up evaluating `key` } return value;}
事实证明,因为pkg.getActionConfigs()返回一个Map,而ValueStackShadowMap实现了Map接口,所以理论上pkg.getActionConfigs()返回的值可能是ValueStackShadowMap的一个实例。因此,QL DataFlow库显示了从变量chainedTo到类ValueStackShadowMap中的get()实现的潜在流程。实际上,ValueStackShadowMap类属于jasperreports插件,该类的实例仅在几个地方创建,并都不会被pkg.getActionConfigs()返回。在发现ValueStackShadowMap::get()不太可能被命中之后,作者通过在DataFlow::Configuration中添加一个过滤来删除依赖它的结果:
override predicate isBarrier(DataFlow::Node node) { exists(Method m | (m.hasName("get") or m.hasName("containsKey")) and m.getDeclaringType().hasName("ValueStackShadowMap") and node.getEnclosingCallable() = m )}
这个predicate意思是如果非法数据流入ValueStackShadowMap的get()或containsKey()方法,那么就不要继续跟踪它。
新漏洞:CVE-2018-11776
只有10对源和接收点,就很容易通过手工检查发现这些是否真正存在问题。通过一些路径,作者发现有些路径是无效的,因为它们在测试用例中,所以在查询中添加了一些过滤来过滤掉这些路径。这就留下了一些非常有趣的结果。
以ServletActionRedirectResult.java中的源代码为例:
在第一步中,调用getNamespace()的源通过变量namespace流入ActionMapping构造函数的参数:
public void execute(ActionInvocation invocation) throws Exception { actionName = conditionalParse(actionName, invocation); if (namespace == null) { namespace = invocation.getProxy().getNamespace(); //源 } else { namespace = conditionalParse(namespace, invocation); } if (method == null) { method = ""; } else { method = conditionalParse(method, invocation); } String tmpLocation = actionMapper.getUriFromActionMapping(new ActionMapping(actionName, namespace, method, null)); //namespace进入ActionMapping的构造函数 setLocation(tmpLocation);
继续执行这些步骤之后,可以看到getUriFromActionMapping()返回一个URL字符串,该字符串使用构造的ActionMapping中的namespace。然后通过变量tmpLocation流入setLocation()的参数,然后setLocation()在超类StrutsResultSupport中设置字段位置:
public void setLocation(String location) { this.location = location;}
然后代码在ServletActionResult上调用execute():
String tmpLocation = actionMapper.getUriFromActionMapping(new ActionMapping(actionName, namespace, method, null));setLocation(tmpLocation);super.execute(invocation);
它将location字段传递给对conditionalParse()的调用:
public void execute(ActionInvocation invocation) throws Exception { lastFinalLocation = conditionalParse(location, invocation); doExecute(lastFinalLocation, invocation);}
然后conditionalParse()将位置传递给translateVariables():
protected String conditionalParse(String param, ActionInvocation invocation) { if (parse && param != null && invocation != null) { return TextParseUtil.translateVariables( param, invocation.getStack(), new EncodingParsedValueEvaluator()); } else { return param; }}
所以当在ServletActionRedirectResult中没有设置namespace参数时,代码从ActionProxy获取namespace,然后将其作为OGNL表达式进行评估。为了测试这个,作者通过以下方法替换了showcase应用程序中的一个配置文件(例如struts-actionchaining.xml)中的struts标记:
register2
然后在本地运行showcase应用程序,并访问了一个可以触发此漏洞的URL并执行shell命令以在计算机上打开计算器应用程序。
不仅如此,来自ActionChainResult,PostbackResult和ServletUrlRenderer的不可信来源也同样有效!PortletActionRedirectResult中的那个可能也可以,但没有被测试。四个RCE足以证明问题的严重性。
看完上述内容,你们掌握如何通过Semmle QL找到Apache Struts的远程执行代码.的方法了吗?如果还想学到更多技能或想了解更多相关内容,欢迎关注创新互联行业资讯频道,感谢各位的阅读!
网站名称:如何通过SemmleQL找到ApacheStruts的远程执行代码.
网页网址:http://myzitong.com/article/pcschg.html