Full Report
WSO2 API manage is an API gateway and lifecycle management platform. It's similar to Kong. The API gateway gateway takes in HTTP requests and forwards them to the backend API servers. WSO2 adds authentication, rate limiting and easy deployment. This code is built on top of Apache Synapse, a Java mediation framework with several customization. The 404 not found page was using a templating engine. the page itself was defined in a Synapse 'sequence' file in XML with the text containing the URL path as input. Like any templating engine, there is logic to replace the placeholder with the real value. This logic tried to see if the input is valid XML by creating an XML document with it. If it's not, then the data is escaped. What's the issue here? The input is not escaped in XML! This leads to a classic template injection. What's weird though is that this turns into eXternal XML Entity (XXE) injection. Since the import happens twice (once in verification of the data and once in adding to the sequence file), the second time will always fail. Practically, this means that the exploitation of this must be blind. The exploitable parameter is the path of the URL. So, the author needed to create valid XML that was also a valid URL path. To do this, tabs must be used instead of spaces. Although this should technically be illegal, the server allows it; encoding the spaces with %20 didn't work either because it won't be decoded before it hits the XML parser. Another issue arises: the DTD thinks this is an absolute URL path. So, the path itself needs to include a URL at the beginning of it. The actual URL being used for the XXE is nested inside of this. The exploit is super funky looking: GET /http://whatever/ HTTP/1.1 The payload above will reach out to the web server http://evil.com:8080. So, what does this mean with blind XXE? In Java, you can include a file, such as /etc/passwd and send the contents of the file as FTP commands. This is only possible in older versions of Java; in newer versions, URLs cannot have newlines in them, which prevents this from working. In WSO2 API Manager 2.1.0, the reflection above was fixed via not returning the path in the text because of reflected XSS. Lolz - there was something lurking way deeper! The isXML XXE was not patched until years later. Without the 404, it required adding a custom page to the API gateway that used the payloadFactory type. Most developer docs and Stack Overflow posts were vulnerable to this issue though. In 3.0.0, a service to transform XML requests into JSON was added. It takes a POST request with an XML document and forwards the request to the backend service. Several of the inputs are templated; hence, they are passed to the vulnerable isXML function. This creates a new universal path exploit on the project. In 3.1.0, the XXE bug was fixed but readded back in 4.0.0. Finally, for version 4.3.0, the vulnerability is fixed for good. Overall, a great post! The history of the issue and exploitability on different versions was interesting to read about.
Analysis Summary