如何通过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 Map context, final Object root) throws OgnlException {  return compileAndExecuteMethod(name, context, new OgnlTask