Facebook Google Plus Twitter LinkedIn YouTube RSS Menu Search Resource - BlogResource - WebinarResource - ReportResource - Eventicons_066 icons_067icons_068icons_069icons_070

[R1] Novell NetIQ Sentinel Commons DiskFileItem RMI Java Deserialization Remote File Creation / Manipulation

Critical

Synopsis

On March 4, 2016, Novell released a patch for NetIQ Sentinel 7.4 SP1 (Sentinel 7.4.1.0) Build 2512 that fixed “Java Deserialization” [1]. The “fix” however, appears to have simply upgraded Apache Commons Collections to 3.2 where dangerous objects are not deserializable by default. This means that NetIQ is still open to other deserialization attacks.

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 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 live for ~2 minutes when created by NetIQ Sentinel.

Proof of Concept

NetIQ Sentinel exposes RMI through TCP port 1099. Using this interface a remote unauthenticated attacker can deserialize a DiskFileItem. This allows an attacker to perform a variety of actions. The most obvious is that the attacker now has control of all files owned by novell:novell. There are a lot of files within the /var/opt/novell/sentinel directory structure that are interesting. Specifically, /var/opt/novell/sentinel/3rdparty/mongodb/ and /var/opt/novell/sentinel/3rdparty/postgresql/ contain a large amount of data important to Sentinel. An attacker even has the power to delete the table containing authentication information which then denies access to everyone. Another interesting attack is deleting the "events" (think like Snort warnings) database to hide malicious activity on the network.

Tenable has created a proof-of-concept NASL script that connects to the RMI port and sends the DiskFileItem object. We also had to create a Python version of the exploit for the haters. The result of the attack is a new file in /tmp/ with the contents “hello”. The new file has the permissions of user “novell”.

Solution

Novell has released Sentinel Server 7.4.3 that hopefully mitigates this issues.

Disclosure Timeline

2016-03-15 - Issue discovered
2016-03-21 - Draft advisory written
2016-03-28 - Submitted to ZDI for consideration, case bainesjr0003
2016-04-26 - ZDI requests a non-NASL PoC, asks for clarification on the version tested
2016-04-27 - Tenable retests with the ISO ZDI used, confirms vulnerability
2016-04-27 - Tenable provides ZDI with a Python version of the PoC
2016-06-14 - ZDI makes $1k offer. We accept.
2016-09-26 - Vendor doesn't know what to do with the CVE, doesn't understand DWF, asks ZDI for help. ZDI confirms with us the assignment, we send over public refs in DWF GitHub / Tenable site.
2016-10-17 - ZDI publishes ZDI-16-570

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 [email protected]