---

TECHNICAL DETAILS & DESCRIPTION :

XML External Entities weakness resides in the application’s XML input parsing capabilities. This attack occurs when XML input containing a reference to an external entity is processed by a weakly configured XML parser. It leads to the disclosure of confidential data, denial of service, server-side request forgery, port scanning from the perspective of the machine where the parser is located, and other system impacts. PayPal official web application (PayPal Inc – PayPal Multi-Order Shipping Application [Core]) suffered from this critical security vulnerability.

BACKGROUND:

PayPal Multi-Order Shipping is a tool that allows to print up to 50 domestic U.S. Postal Service shipping labels at a time, right from PayPal account. Including multiple services:

• Import transactions from eBay and/or PayPal
• Manually create one or more ad-hoc labels
• Get orders ready to print labels
• Edit shipping details for an order
• Add insurance and signature confirmation to an order
• Combine multiple orders into one shipment
• Revert a combined order
• Add or remove columns in the Orders to Ship tab
• Application settings and time-saving tools
• Printing labels and supporting documentation Carrier Pickup™ and post-shipment management

Identification Phase :

The application is XML based, the requests exchanged with the server are structured data in XML format. While testing the application’s features through intercepting requests within the environment the following requests caught my attention :

In the first attempt, we need to confirm that entities are interpreted in the most basic form. We replace VALUE with an inline entity to analyse the server behavior:

The response returned is invalid input error so the server has a reflection point to displays the injected payload and since the XML requests are user-supplied I tested for basic XML Injection to check the application’s XML processing methods by trying to extract files with the injected entity (remote file) back to the client. The idea of this attack is to declare an external general entity and reference an internal file on a network resource or locally:

We noticed that the application only check at position: strings, numeric, CDATA values. The values referenced from the metadata or entities inside the document aren’t used. Therefore, it is not possible to get a direct response after submitting our request.

XXE OUT-OF-BAND CHANNELS EXPLOITATION:

Overview of XXE Processing:

XML parsers typically support external references by default, external entities can reference files on the parser’s file-system. External entities can often also reference network resources via the HTTP protocol handler. The ability to send requests to other systems can allow the vulnerable server to be used as an attack proxy. By submitting suitable payloads, an attacker can cause the application server to attack other systems that it can interact with. This may include public third-party systems, internal systems within the same organization, or services available on the local loopback adapter of the application server itself. Depending on the network architecture, this may expose highly vulnerable internal services that are not otherwise accessible to external attackers.

ATTACK VECTORS :

1. BYPASS XXE DIRECT-FEEDBACK CHANNEL PARSING RESTRICTION :

   After multiple tests, I confirmed that there is no direct feedback channel from which we can force the server to display the result in the response, So I used a technique in which we inject an XML payload using External Entity in “DOCTYPE” instead of general entities, the DOCTYPE declaration with the SYSTEM keyword causes an XML parser to read data from a URI and permits it to be proceeded into the document :

   

   The application server response was an Internal Server Error message, right after I sent the request, my server received a connection from a PayPal’s internal server:

   

   Now we confirm that External Entities are activated, this means that connections are allowed to remote systems from the vulnerable server and it’s possible to use an external DTD to extract local files via web requests. This technique will allow us to load any network resources from a host we control. The resources can be hosted on an HTTP server, FTP server, …etc.

2. XXE OOB DATA RETRIEVAL VIA PARAMETER ENTITIES:

In order to overcome parsing restrictions such as (limited use of external Entities, referencing General/Parameter entities in the main XML document), I thought about:

• Using Parameter entities within a DTD definition.
• Making the server interacts with my external domain and make a resolution of XXE payload instead of performing attack directly inside the XML document.

This attack can be executed by referencing the hosted DTD resource only. The request does not even have to contain any XML body, for as long as the server processes XML requests.

A. XXE Data Retrieval through Protocol Handlers :

Parameter entities help us to access external resources transferring to them file content from the server, where the parser is located, via external entities using the technique described above. It allows attacking parsers, on which result direct output is not supported.

Now the objective is to gain access to server’s internal local files / resources (file disclosure) exploiting protocol handlers (wrappers) used in many platforms/parsers which support a variety of URL schemes/protocols :

When performing data extraction from the target application and initiating a connection back to my server in order to fetch a DTD then send the file contents. Assuming a strict firewall restrictions is in place, I tested different protocol handlers and common ports (21, 23, 80, 443, 8080, …) then I realized that the target server block outgoing connections to some TCP ports such as: 21 (FTP), 8080, 8000, 1337, 2222…etc.

However, we still have an option to fetch arbitrary file via HTTP/HTTPS requests back to a controlled domain. Following the extraction of “/etc/passwd” file, after couple of tries, few seconds an incoming connection is opened and the file content is received:

As noticed the length of data sent within the URL is almost certainly limited, depending on some particular implementation, that’s why only a single line of /etc/passwd can be read using this method. The URL must generally consist of properly formed Unicode data and must also conform to the particular XML library’s restrictions on characters permitted in the URL. Sometimes a parser does not check the length of a created URI, and a lot of parsers convert line feeds automatically (Xerces replaces them with spaces, and System.XML processes with URL encode).

B.Bypass URI length & Server Firewall restriction :

Consider the following:

• Control of data chunks length that will be checked on the side of our controlled server.
• Connections are established to remote systems from the vulnerable server, it’s possible to use of an external DTD to exfiltrate data.
• Control of TCP communication protocol with PayPal remote Server.
• Emulate Custom Server listening on ports including (HTTPS, HTTP).

So, to overcome this limitation instead of setting an HTTP Server, I used a technique to trick the target server to initiate a connection to a custom FTP Server on port 443 (https), each line from multiline URI will be requested as separate command. Once the XML interpreter parses the external DTD file, the contents of the file to read are sent to the custom FTP server and retrieve all data in only one request.

Thus, our final payload:

POC source code :

Custom FTP Server

HTTP Server

After testing and fuzzing more capabilities I could exploit XXE Out-Of-band to disclose some files and much more attacks were possible.

This weakness gives a remote attacker (with no privileges nor user interaction) access to PayPal servers and its internal systems.

 

 

Remote Code Execution Scenario:

The consequences were highly dangerous, gives an attacker the ability to effectively bypass strict firewalls, authorization schemes, sensitive data disclosure and PayPal internal networks access. In our case I successfully exfiltrate any kind of data to my external server after running XXE recon which provided me with visibility into the target system and identifying installed applications, gaining a toehold for RCE endpoints. I figured a way to read configuration files, server log files, users history and internal hosts information, …etc. From the connections, we received after executing our XXE exploit on the target application. Due to the sensitivity of the PayPal information exposed I am not allowed to share the RCE exploitation part, but I am going to demonstrate a working scenario consists of attacking Apache Tomcat installation in PayPal’s internal server following these steps:

1. Gain Access to Web Administration Portals via History Logs:
2. Check for contents of history logs (e.g.: ~/.bash_history), look up for deployed services.
3. Perform a Local System File Scan.
4. Identify an Apache Tomcat application.
5. Send Apache Tomcat Configuration files, Authentication Credentials and Server to probe via XXE with a request back to our Server.
6. Web Browser to Access the Web Administration Console once we found the URL in the configs.
7. Confirmed RCE, grant access.

VIDEO POC :

About

Follow me on twitter : https://twitter.com/r007hunt