Introduction While testing the LAN infrastructure of one of our clients I discovered that one of the applications is handling XML input which led to finding critical vulnerabilities. By allowing the definition of custom entities within XML input better known as XML External Entity (XXE) the application exposed itself to a range of serious threats, including local file disclosure, external network interactions resulting in NTLMv2 hash leakage, and most notably, Remote Code Execution through the use of XSLT templates.
Technical Details The first step was identification of open services for the server using nmap:
Jetty instance on port 8087/tcp shows two deployed applications (including their full path in the system):
The J4LFOPServer - based on information published over the Internet - is an application / component being part of Oracle Application Express / Apex reporter and used to generate PDF files based on XML input and Apache FOP templates. Accessing application from the browser revealed directory listing with two files - Example.html and FOP.html:
The first one - Example.html shows a simple form with XML input:
By clicking Convert to PDF button - a PDF document based on XML input is generated:
One of the abilities of XML is to define entities, which can be external references to files in the filesystem or network resources. To confirm that, auditor created external entity reference to controlled HTTP server:
After converting such input to PDF, it was possible to see HTTP interaction in Burp Collaborator tool: As an alternative payload instead of URL, it was possible to use network share in format: \\10.27.20.41\anything Server under IP 10.27.20.41 was the machine controlled by the auditor and running application Responder - a special tool used to poison LLMNR / NBT / MDNS and DNS answers and try to collect NTLMv2 hashes from the network. Forcing the application through XXE vulnerability to request this network share, resulted in interception of attacked server NTLMv2 hash: Cracking this password allowed the execution of code on this and other servers and was a base for a lot of sensitive information disclosure and privilege escalations. However, there is also a second way to achieve code execution using J4LFOPServer and it is under FOP.html file: There is also a simple form that expects uploading two files - XSL-FO template and XML file. Digging through the Apache FOP documentation, the auditor was able to find FOP file examples that show that it partially uses XML and XSLT structures to give the final PDF a certain style. There are known methods of using XSLT to execute code in different programming languages. Below is an example implementation of FOP file that allows code execution: Now we have a sample valid XML file: Uploading those two on FOP.html and clicking on convert button will show such output: We can also notice DNS interaction which is proof of remote code execution achieved: Final Notes As part of our recommendations, we advised the client to assess whether the vulnerable application, likely installed over a decade ago is still actively in use. If it no longer serves a functional purpose, the safest course of action would be to remove it entirely. Given the lack of an available changelog and uncertainty around whether J4LFOPServer is still maintained, we also recommended considering alternative, well-supported solutions that offer similar functionality but with ongoing security updates and vendor support.