如何通過Semmle QL找到Apache Struts的遠程執行代碼.

如何通過Semmle QL找到Apache Struts的遠程執行代碼.，相信很多沒有經驗的人對此束手無策，為此本文總結了問題出現的原因和解決方法，通過這篇文章希望你能解決這個問題。

前言

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<String, Object> context, final Object root) throws OgnlException {  return compileAndExecuteMethod(name, context, new OgnlTask<Object>() {    public Object execute(Object tree) throws OgnlException {      return Ognl.getValue(tree, context, root);    }  });}

并且compileAndExecuteMethod()在執行之前對表達式執行額外檢查：

private <T> Object compileAndExecuteMethod(String expression, Map<String, Object> context, OgnlTask<T> 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標記：

<struts>    <package name="actionchaining" extends="struts-default">        <action name="actionChain1" class="org.apache.struts2.showcase.actionchaining.ActionChain1">           <result type="redirectAction">             <param name = "actionName">register2</param>           </result>        </action>    </package></struts>

然后在本地運行showcase應用程序，并訪問了一個可以觸發此漏洞的URL并執行shell命令以在計算機上打開計算器應用程序。

不僅如此，來自ActionChainResult，PostbackResult和ServletUrlRenderer的不可信來源也同樣有效！PortletActionRedirectResult中的那個可能也可以，但沒有被測試。四個RCE足以證明問題的嚴重性。

看完上述內容，你們掌握如何通過Semmle QL找到Apache Struts的遠程執行代碼.的方法了嗎？如果還想學到更多技能或想了解更多相關內容，歡迎關注億速云行業資訊頻道，感謝各位的閱讀！