发表主题 回复主题
  • 867阅读
  • 0回复

[Web安全]使用QL去发现Apache Struts的远程代码执行漏洞(CVE-2017-9805)

使用QL去发现Apache Struts的远程代码执行漏洞(CVE-2017-9805)

在这篇文章中,我将介绍如何自定义一个标准lgtm查询来查找Apache Struts中的远程代码执行漏洞。如果你想了解这个漏洞的更多的公告信息,可以参考这篇博客。这个漏洞已经分配了编号CVE-2017-9805,漏洞的安全公告可以在Struts官网找到以及受影响的Apache Struts2.5.13的漏洞解决详细信息。由于这个漏洞太严重了,所以本文中删除了一些细节(包括exp),这些信息几周后会补充。

我们强烈建议Struts的用户升级到最新版本,以减轻此安全风险。

我发现的这个漏洞是Java在反序列化上处理不安全导致的。继克里斯·弗洛霍夫(Chris Frohoff)和加布里埃尔·劳伦斯(Gabriel Lawrence)在Apache Commons Collections中发现了导致任意代码执行的反序列化的漏洞之后,近年来又出现了许多类似的漏洞,许多Java应用程序受到这种漏洞的影响。如果你想更多地了解这种类型的漏洞,那么lgtm文档页面的这个主题是一个开始的好地方。

检测Struts中的不安全反序列化

lgtm使用专门设计的语言(QL)编写的查询来识别代码中的风险。这些为Java设计的查询之一是检测潜在的不安全的反序列化,这些反序列化通常用于处理用户可控的数据。这种查询识别的场景通常是未被净化的数据却被反序列化成了java对象,用户可控数据来源可能是http请求或者是任何一个socket连接。

除此之外,这种查询还会检查用户控制的数据流向反序列化方法的普通函数。然而,有些项目在接受远程用户输入上所采用的方法稍微有些不同。比如,Apache Struts使用ContentTypeHandler接口。这会将数据转为Java对象。由于这个接口的实现都是将收到的数据反序列化,所以实现这个接口的每个类都值得关注(潜在风险)。用于检测不安全反序列化标准QL查询可以轻松地适应于识别用于处理用户输入的方法。这是通过自定义数据源来完成的。

在这个例子中,我们对来自toObject方法的数据流感兴趣,因为这个方法是在ContentTypeHandler接口定义的:

void toObject(Reader in, Object target);

toObject的第一个参数收到的数据应该被认为是肮脏的:因为该数据是远程用户控制的所以不值得相信任。我们的目标是发现这么一个点,某个反序列化方法未经验证或净化就调用了肮脏的数据。

QL DataFlow函数库提供了这么个功能,它能够在源码中跟踪各个步骤的肮脏数据。这就是著名的污点追踪技术。例如,数据被跟踪是因为调用了不同的方法。

IOUtils.copy(remoteUserInput, output);   // 输出也是安脏的,因为该函数单纯的复制保存了。数据

为了充分利用DataFlow库里的污点追踪功能,我们来定义ContentTypeHandler.toObject(...)的参数作为肮脏源。

首先,我们得定义查询是如何识别ContentTypeHandler接口和toObject方法的。

/** The ContentTypeHandler Java class in Struts **/
class ContentTypeHandler extends Interface {
  ContentTypeHandler() {
    this.hasQualifiedName("org.apache.struts2.rest.handler", "ContentTypeHandler")
  }
}

/** The method `toObject` */
class ToObjectDeserializer extends Method {
  ToObjectDeserializer() {
    this.getDeclaringType().getASupertype*() instanceof ContentTypeHandler and
    this.getSignature = "toObject(java.io.Reader,java.lang.Object)"
  }
}

这里我们使用getASupertype*()去限制匹配了任意将ContentTypeHandler作为超类的类。

接下来我们想将toObject的第一个参数标记为不安全的数据源,并跟踪它在代码之间的流向。为了达到这个目的,我们扩展了QL dataflow库中FlowSource类。

/** Mark the first argument of `toObject` as a dataflow source **/
class ContentTypeHandlerInput extends FlowSource {
  ContentTypeHandlerInput() {
    exists(ToObjectDeserializer des |
      des.getParameter(0).getAnAccess() = this
    )
  }
}

直观的说,上面这个类的定义表示了传递toObject的第一个实参都会被ToObjectDeserializer捕捉,所以这就是数据流动源头。请注意,由于技术原因,流源必须是表达式。因此,我们可以确定那个参数收到的实际值(是表达式)作为源,而不是参数本身。

现在我们知道了数据源在哪,那我们就可以找到是哪个不安全的反序列化方法调用了肮脏的数据。我们不必完整了解这个方法,因为它已经出现在了用户控制数据查询的反序列化过程中(64行:UnsafeDeserializationSink)我们只需要将其定义复制到查询控制台即可。通过这个,我们最终查询变成了:

from ContentTypeHandlerInput source, UnsafeDeserializationSink sink
where source.flowsTo(sink)
select source, sink

在FlowSource中我们使用了.flowTo来预测追踪情况,以便我们识别在ContentTypeHandlerInput执行的不安全反序列化。

当我在Struts上进行自定义查询时,产生了一个精准结果。(现在运行它将不会产生结果,因为已经修复了)。我证明了这是一个真正的远程代码执行漏洞,然后将其报告给Struts安全团队。他们的响应非常快,马上就拿出了解决方案尽快这是一个非常重要的任务,API必须改变。由于发现问题的严重性,现阶段我不会披露更多的细节。相反,我将在几个星期后更新本文,并提供更多的信息。

译文:https://lgtm.com/blog/apache_struts_CVE-2017-9805

关键词: CVE-2017-9805
发表主题 回复主题
« 返回列表上一主题下一主题