Oracle MySQL Enterprise Monitor is vulnerable to several Java object deserialization attacks that result in remote code execution. While Oracle has addressed one of these vectors (Apache Commons Collections InvokerTransformer Class) in WebLogic Server (CVE-2015-4852), no advisory or CPU has mentioned MySQL Enterprise Monitor being affected. In addition to the InvokerTransformer vector, the same type of attack can be conducted via the readObject() call in the implementation of Apache Commons FileUpload as well as their implementation of SpringFramework. This is the first product we've seen to actually be vulnerable to the SpringFramework vector (published by Chris Frohoff in ysoserial on 2015-01-28, no CVE), so that was fun! All testing was performed against an installation on Windows 7, but exploitation can be trivially modified to work against Linux as well.
Exploit Vector
Oracle MySQL Enterprise Monitor offers an authenticated REST API. One of the URLs for this API is https://[target]:18443/v3/dataflow/0/0. This URL accepts HTTP POST requests with a content type of “application/octet-stream”. POSTing to this URL invokes the DataflowRouter.class post() function (part of the com.mysql.etools.springboard.rest package in mysql-etools-springboard-3.1.1.7806.jar). The post() function eventually leads to loading the payload of the HTTP POST request into an ObjectInputStream and calling readObject().
Apache Commons FileUpload Exploitation
Apache Commons FileUpload contains an object called DiskFileItem, which is normally harmless. However, the object can be modified after it is serialized to behave in ways that were not intended. Specifically we can modify DiskFileItem to:
- Create a new file anywhere the Java process has permission.
- Write anything we would like to that new file.
- We can also move (copy and delete) any file on the remote system that we have permission to.
There are two limitations though:
- We don’t control the filename. This is generated by
DiskFileItem class as “upload_$uuid_$counter.tmp".
- Files are created using the
File.createTempFile() interface. That means the lifetime of the file is totally dependent on the usage of deleteOnExit(), how long the JVM runs, and if it is moved after creation (If the move is done by the exploit then it will still be deleted. However, if the move is done by the InvokerTransformer exploit then it will not be deleted). It is our observation that files appear to last ~30 seconds when creating them via the DataFlowRouter interface, which is more than enough time for most nefarious purposes.
Apache Commons Collections Exploitation
There has been plenty said about using various Commons Collections Objects to invoke cmd.exe. We will not rehash it here, but simply point to the FoxGlove Security article for background. To verify this vulnerability, we created a serialized object that invokes the shell and creates the directory "cheese" in C:\Users\Public. Due to CVE abstraction for the Apache Commons Collections issue being tracked on a per-vendor basis, this vector will fall under CVE-2015-4852, and is somehow only the second Oracle product to be found vulnerable. Despite that, Oracle issued a new CVE for this specific product being affected.
SpringFramework Exploitation
Although Chris Frohoff released proof of gaining shell access via SpringFramework Object deserialization back in early 2015, this technique has not gained the infamy that the Commons Collections techniques have. This is largely due to the fact that fairly new versions of spring-core and spring-beans are required (4.1.4.RELEASE), which many products don't use. Unfortunately, MySQL Enterprise Monitor has these libraries on its classpath.
Oracle has classified this as a High access complexity for exploitation, likely due to it relying on varying factors related to which library is present. However, a rather vanilla install of the product allows for trivial exploitation and just requires credentials. As such, we are classifying the access complexity as low.
Apache vs Vendors, Attributing Blame
We brought the FileUpload issue to Apache's attention and they do not see it as a vulnerability. In their response to us, they stated:
"Having reviewed your report we have concluded that it does not represent a valid vulnerability in Apache Commons File Upload. If an application deserializes data from an untrusted source without filtering and/or validation that is an application vulnerability not a vulnerability in the library a potential attacker might leverage."
Tenable argued that if an application intends to deserialize DiskFileItems then they are still vulnerable to the altered object and they could have files written anywhere on their server, which seems to cross the privilege boundaries intended by the library based on the code.
Based on our research, there is no warning about distrusting this object included in their library, or mentioning the potential for problems. It seems like there could be a few lines of code to prevent the unintended aspect of this (files written to arbitrary locations), while still maintaining the functionality of the library. In doing that, it would add a layer of protection for companies that implement the library (which many do, and we are finding vulnerable).
After another Apache person mentioned that "java.io.File is serializable, too .. And, I assume that an intruder who manages to have a DiskFileItem created and getInputStream() invoked on it, can just as well create a File (or a String), and invoke new File(Input|Output)Stream?" We reminded them that the act of deserializing a DiskFileItem can cause arbitrary files to be written to disk. The attacker does not need to invoke a new outputstream because DiskFileItem's readObject() function has already done that for him. This is not expected behavior as best we can tell. This is also not at all like deserializing a Java.io.File. That said, we respect Apache's stance on this and are contacting vendors that implement the Commons FileUpload library in a way that makes their software vulnerable.