icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons_061

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

Critical

Synopsis

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.

Solution

WISE has released version 5.2.1 to address this issue.

Disclosure Timeline

2014-06-07 - Project opens ticket #435 to remove Apache Commons, no mention of security
2014-09-04 - Github #435 modified to milestone v4.10 Major Release
2015-01-14 - Github #435 modified to milestone v5.0 Major Release, v4.10 Major Release
2016-01-21 - Github #435 modified to milestone v5.1 Major Release, v5.0 Major Release
2016-02-01 - Issues discovered to affect WISE
2016-02-18 - Post to 'wise-dev' list asking where to report vulns
2016-02-18 - Reply says to use contact form
2016-03-03 - Attempt to report via contact form, CAPTCHA times out, won't submit
2016-03-03 - Reply to 'wise-dev' thread asking for alternate contact method
2016-03-04 - Submit via contact form finally. Stupid CAPTCHAs
2016-03-04 - Vendor confirms receipt of report via forum.
2016-05-17 - Ping vendor for update via forum.
2016-05-25 - Github #435 modified to milestone v5.2 Major Release, v5.1 Major Release
2016-07-07 - Open ticket (659) on Github asking for status.
2016-07-07 - Vendor replies they plan to remove Commons, tracked as #435
2016-09-14 - Reply to #435 asking for update.
2016-09-15 - Commit fix available, 8af020a. Will be included in 5.2.1 release.
2016-09-28 - Version 5.2.1 not released yet.
2016-10-19 - Version 5.2.1 not released yet.
2016-11-04 - Version 5.2.1 released!

All information within TRA advisories is provided “as is”, without warranty of any kind, including the implied warranties of merchantability and fitness for a particular purpose, and with no guarantee of completeness, accuracy, or timeliness. Individuals and organizations are responsible for assessing the impact of any actual or potential security vulnerability.

Tenable takes product security very seriously. If you believe you have found a vulnerability in one of our products, we ask that you please work with us to quickly resolve it in order to protect customers. Tenable believes in responding quickly to such reports, maintaining communication with researchers, and providing a solution in short order.

For more details on submitting vulnerability information, please see our Vulnerability Reporting Guidelines page.

If you have questions or corrections about this advisory, please email advisories@tenable.com