Oracle人力資源管理系統PeopleSoft未授權遠程代碼執行漏洞解析

幾個月前，我有幸參與幾個Oracle PeopleSoft建設項目的安全審計，審計對象主要為PeopleSoft系列的人力資源管理系統（HRMS）和開發工具包（PeopleTool）。縱觀網上關於PeopleSoft的安全資料，除了幾個無法證實的CVE漏洞參考之外，就只有ERPScan在兩年前HITB會議的一個信息量極大的演講。根據ERPScan的演講PDF我發現，儘管網上鮮有PeopleSoft的安全信息，但它其實漏洞重重。

僅從我隨手的安全測試來看，PeopleSoft應用程序包含很多不經驗證授權的服務端點，可能出於高交互性，這些服務端中大部分都使用了默認密碼。這種脆弱的安全環境明擺著給攻擊者敞開了門窗。在這篇文章中，我將展示如何利用一個XXE漏洞提權以執行系統命令，該問題可能影響當前所有PeopleSoft版本軟體。

XXE漏洞：獲取本地網路訪問許可權

PeopleSoft存在多個XXE漏洞，如早幾年的CVE-2013-3800和CVE-2013-3821，最新的為ERPScan發現的CVE-2017-3548。通常來說，可以利用這些漏洞獲得PeopleSoft和WebLogic控制端的密碼信息，但在該測試環境中這種方法的成功實現需要一定難度。另外，由於CVE-2017-3548為Bind-XXE漏洞，而且我認為目標網路系統可能部署有防火牆，所以，利用XXE漏洞竊取系統信息並不像想像中的那麼簡單。在這裡，我們一起來看看CVE-2013-3821和CVE-2017-3548的PoC利用代碼：

CVE-2013-3821：集成網關HttpListeningConnector XXE

CVE-2017-3548：集成網關PeopleSoftServiceListeningConnector XXE

換個思路考慮一下，我覺得可以利用XXE漏洞來訪問本地伺服器localhost的各種服務，或許這還能繞過防火牆規則或身份驗證檢查。因此，在這裡只需要知道PeopleSoft的服務埠即可。最終，我通過獲取其訪問主頁服務的cookie識別了埠信息：

可以看出，當前PeopleSoft的服務埠為5100，可以通過http://localhost:51500/方式訪問到相應的應用程序。

Apache Axis服務的利用

在PeopleSoft服務架構中，其中一個未經驗證授權的服務為通過http://website.com/pspc/services方式訪問的Apache Axis 1.4。該Apache Axis服務允許我們從Java類中構建SOAP終端，然後利用生成的Web服務描述語言（WSDL）配合輔助代碼實現與這些終端進行交互。我們可以通過http://website.com/pspc/services/AdminService對Apache Axis服務進行管理：

以下為Apache Axis管理員基於java.util.Random類創建SOAP服務端的POST代碼，從該代碼中，我們可以看到一些具體的服務創建方式：

由於java.util.Random類中的每一個公用方法都可以作為一個服務來使用，因此，我們可以通過SOAP來調用Random.nextInt()方法，其請求的POST代碼如下：

之後，會產生以下響應信息，這些信息對應了XML方式的一些設置：

雖然該管理終端對外部IP地址進行了屏蔽，但通過localhost本地訪問時卻不需要輸入任何驗證密碼。因此，這理所當然地成為了我們的一個滲透突破口。但是，由於我們將要利用的是XXE漏洞，需要通過構造GET方式獲取相關信息，因此可以參考以上創建服務和調用方法的POST請求，在後續與伺服器的交互過程中，將我們特定的SOAP Payload攻擊載荷轉換為GET請求發送給主機伺服器，最終嘗試獲得一些有用信息。

Axis: 參考POST請求構造GET形式的SOAP Payload

Axis API允許發送GET請求，它首先會接收給定的URL參數，然後再將這些參數轉換為一個SOAP Payload。通過分析發現，在Axis源代碼中，有一段方法代碼可以把GET參數轉換為有效的XML Payload，該方法代碼如下：

為了更好地理解它的轉換機制 ，我們來看這個示例：

以上GET請求等同於XML形式的設置如下：

然而，當我們嘗試使用這種方法來創建一個新的服務端時卻出現了一個問題：在代碼層面，我們定義的XML標籤必須要設置屬性。因此，當我們像如下方式在GET請求中添加了XML標籤屬性之後：

得到的相應XML設置信息如下：

很顯然，注意查看紅框標記，該文件是個無效的XML文件，其直觀在在瀏覽器中的運行結果是這樣的：

當然，其對伺服器的請求最終也是無效的。但如果我們像下面這樣把整個Payload放到方法參數中：

GET /pspc/services/SomeService

?method=myMethod+attr="x">y

將會得到如下的XML設置信息：

請注意觀察，我們的Payload信息會被兩次進行解析設置，第一次解析的前綴為「

GET /pspc/services/SomeService

?method=!-->y

之後，可以得到正常有效的如下XML設置信息：

在當中，由於我們之前在GET信息中添加了「!–>」前綴，所以首個Payload以XML注釋的起始標記「開始的，這也意味著在和之間的Payload將會被注釋掉，我們預計要執行的在之後的Payload將會成功一次解析執行。

由此，我們就可以將任意的SOAP請求從原先的POST方式轉化為XXE漏洞可以利用的GET方式了，同時也就意味著，我們可以利用XXE漏洞繞過IP檢查機制，將任意類上傳部署為Axis Service使用。

Axis: 源碼分析後的缺陷方法利用

正如預想的那樣，利用這種方法，配合XXE漏洞，我們最終從PeopleSoft中獲得了SYSTEM系統許可權，實現任意命令執行目的。對PeopleSoft來說，這是一個嚴重的未授權驗證遠程系統命令執行漏洞。

EXPLOIT

目前，據我的分析和測試來看，該漏洞可能影響當前所有版本的PeopleSoft。經對以上方法思路的整理，最終總結出了以下可以進行安全測試的EXPLOIT。（代碼具有危險性，請勿用於非法目的）：

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！