Oracle: Deserialize All The Things!
Oracle WebLogic Server was one of the products that FoxGlove Security featured in their now-infamous article outlining deserialization attacks via Apache Commons Collections. Oracle has since released a patch that blacklists all of the Objects used in Chris Frohoff’s ysosoerial tool. However, Oracle has not protected WebLogic Server from yet unpublished deserialization vulnerabilities. Something something blacklists aren't always effective.
Apache Commons FileUpload DiskFileItem
Apache Commons FileUpload’s DiskFileItem 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.
Tenable has created two proof-of-concept scripts to reproduce this vulnerability on a Windows installation of WebLogic server. The scripts are based off of FoxGlove Security’s weblogic.py and do not require authentication. However, the scripts have been altered to execute a known DiskFileItem deserialization. Sorry, we're selfish and won't be sharing them.
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.
Note: This requires WebLogic-specific code to exploit, so the new CVE assignment is appropriate.