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识别了端口信息：

Set-Cookie: SNP2118-51500-PORTAL-PSJSESSIONID=9JwqZVxKjzGJn1s5DLf1t46pz91FFb3p!-1515514079;

可以看出，当前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"><test>y</test></myMethod

将会得到如下的XML设置信息：

请注意观察，我们的Payload信息会被两次进行解析设置，第一次解析的前缀为“<”，第二次为“</”。为了实现一次解析，我们可以使用以下XML注释方法来解决：

GET /pspc/services/SomeService ?method=!--><myMethod+attr="x"><test>y</test></myMethod

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

在<soapenv:Body>当中，由于我们之前在GET信息中添加了“!–>”前缀，所以首个Payload以XML注释的起始标记“<!–”开头，第二个Payload却是以XML注释结束标记</!–>开始的，这也意味着在<!–>和</!–>之间的Payload将会被注释掉，我们预计要执行的在</!–>之后的Payload将会成功一次解析执行。

由此，我们就可以将任意的SOAP请求从原先的POST方式转化为XXE漏洞可以利用的GET方式了，同时也就意味着，我们可以利用XXE漏洞绕过IP检查机制，将任意类上传部署为Axis Service使用。

Axis: 源码分析后的缺陷方法利用

在服务部署时，Apache Axis不允许我们上传自己设置的Javz类，只能使用系统提供的服务类。在对PeopleSoft中包含Axis实例的pspc.war包文件进行分析之后，我发现org.apache.pluto.portalImpl包中的部署类包含了一些很有意思且可以利用的方法。比如，addToEntityReg(String[]args)方法允许在XML文件结尾添加任意数据，另外，copy(file1, file2)方法还允许我们进行任意复制拷贝。这两个方法缺陷足以让我们向服务器中部署包含JSP Payload的XML文件，并把其拷贝到webroot目录下，从而获取到系统的控制shell。

正如预想的那样，利用这种方法，配合XXE漏洞，我们最终从PeopleSoft中获得了SYSTEM系统权限，实现任意命令执行目的。对PeopleSoft来说，这是一个严重的未授权验证远程系统命令执行漏洞。

EXPLOIT

目前，据我的分析和测试来看，该漏洞可能影响当前所有版本的PeopleSoft。经对以上方法思路的整理，最终总结出了以下可以进行安全测试的EXPLOIT。（代码具有危险性，请勿用于非法目的）：

更多信息，请参考ERPScan《Oracle PeopleSoft applications are under attacks!》