[R1] WISE Server Commons Collection / FileUpload Java Deserialization Remote Command Execution

The WISE server hosts a page that allows both unauthenticated file creation/deletion and remote code execution. Specifically, a user can send Java Objects to port 8080 over HTTP to /wise/authorize.html and leverage Java serialization vulnerabilities. In this case, the first half of the 'credentials' parameter is eventually passed into an ObjectOutputStream and readObject() is called.

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:

1. Create a new file anywhere the Java process has permission.
2. Write anything we would like to that new file.
3. We can also move (copy and delete) any file on the remote system that we have permission to.

There are two limitations though:

1. We don’t control the filename. This is generated by DiskFileItem class as upload_$uuid_$counter.tmp.
2. 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 server runs, and if it is moved after creation.

Apache Commons Collections Exploit

Much has been written about abusing Commons Collections in order to gain remote code execution, which was really brought to light and well summarized by Foxglove Security. WISE is also vulnerable due to their implementation of Commons Collections, allowing for the execution of arbitrary commands.

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.