Apache Axis Vulnerability Introduction
Apache Axis™ is a Simple Object Access Protocol (SOAP) engine. During a recent red team engagement we came across an install of an old version of Apache Axis, version 1.4. There are now newer versions such as Apache Axis2, Apache CXF, and Metro. Although outdated, Apache Axis is still being used in many situations, such as when a project that was built using Axis is too difficult to rewrite or when a project has legacy services that use SOAP encoding.
Since we found this instance of the outdated version being used, we figured it might be worth looking for any exploitable vulnerabilities. We ended up finding a way of exploiting an RCE vulnerability due to an expired hard coded domain that was used in a default example service as part of the default install. Apache assigned CVE-2019-0227 to this vulnerability. We have since purchased this domain (www.xmltoday.com) to prevent anyone from using this exploit maliciously. However, as demonstrated in this post, this vulnerability is still exploitable on a local network without owning this domain.
The Root Problem in Axis
In Apache Axis, if you manage to find Server Side Request Forgery (SSRF) on the server that Axis is hosted, you likely will be able to execute code on that server as well. The method of doing that is explained well in this blog post by Ambionics Security. I will not go into too many details about that in this post since it has already been covered, but the TL;DR is: Axis treats requests coming from localhost with administrative privileges, which allows you to launch a malicious service by making an HTTP GET request which appears to be coming from localhost through an SSRF vulnerability.
Discovery
With the knowledge of the previous Axis research, I figured a good place to start would be to see if there was a way to find and exploit an SSRF issue in any of the default or core code of Axis. In the default installation of Axis, there is a default example web service named “StockQuoteService.jws” which is publicly accessible. The purpose of this service is to give an example of what you can do with a Java Web Service. This particular example was designed to retrieve the price of a stock symbol from an external service residing on an external URL. Taking a look at the code for this service, I noticed it was making an HTTP request to www.xmltoday.com to retrieve some XML and display the price of a stock symbol parsed out of the response. In the screenshot below, you can see the code that performs the HTTP request to the external service, www.xmltoday.com.
“XMLUtils.newDocument” attempts to retrieve an XML document from the domain to be parsed. Since the user controls the “symbol” parameter being sent to www.xmltoday.com my first thought was to see what kind of data was being returned, and if I could control or manipulate it in some way. I went to www.xmltoday.com and was surprised to see that the domain was no longer owned and available for anyone to purchase.
Since www.xmltoday.com was for sale, that meant we could purchase this domain and set it up to redirect any requests to a specially crafted localhost URL. Combining this with the SSRF to RCE trick, we could then gain remote code execution on any Axis server. To verify this, we looked into how the “XMLUtils.newDocument” function handles redirects. The following image shows the properties for the “HttpURLConnection” used by “XMLUtils.newDocument”.
Looking at XMLutils in the Axis source, you can see the “setInstanceFollowRedirects” property is set to “true”. This confirmed that “XMLUtils.newDocument” would, in fact, follow redirects.
With that validation, we purchased www.xmltoday.com and obtained the ability to execute code on any Apache Axis installation. This also prevented anyone with malicious intent from purchasing the domain and achieving the same results.
Other Methods of Exploitation
Owning this domain is not the only way to abuse the “StockQuoteService.jws” or any other HTTP request coming from an Axis server. Since the request is being made over HTTP, this means if you were on the same network as an Axis server you could perform a man-in-the-middle attack targeting that server and then using the “StockQuoteService.jws” trigger or wait for an HTTP request and again, redirect this request to localhost to exploit the SSRF trick.
The steps to exploit this are as follows:
- ARP poison the targeted Axis server.
- Redirect any HTTP traffic to your own web server.
- Redirect to the specially crafted localhost URL which launches a service in Axis.
- Trigger the HTTP request to redirect with a request to “StockQuoteService.jws”
Demonstration of the Exploit
In the following gif, we exploit Axis 1.4 installed on Apache Tomcat 8.5 using the “StockQuoteService.jws” default service to trigger the bug.
Proof of Concept
A proof of concept to demonstrate the man-in-the-middle method of exploiting this vulnerability can be found at our github.
Conclusion
If you are still using Axis, make sure to delete the StockQuoteService.jws from the Axis root directory. Ensure that any libraries or services you are running in Axis do not perform HTTP requests or allow users to initiate an HTTP request. Instead, use HTTPS and verify SSL certificates. Rhino Security Labs now controls the www.xmltoday.com domain to prevent this from being exploited over the internet, but Axis servers are still vulnerable on an internal network. The latest build of Apache Axis1 that includes the patches for this issue can be found here.
Disclosure Timeline
01/15/2019 – Issue reported to Apache
01/27/2019 – Apache acknowledges report and accepts it
03/12/2019 – Apache applied SSRF patch
04/02/2019 – Apache assigned CVE-2019-0227
