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

[R1] Hewlett Packard Network Automation RMI Registry Port Java Deserialization Remote Code Execution



HP Network Automation (HP NA) software, available for Windows or Linux, "automates the complete operational lifecycle of network devices from provisioning to policy-based change management, compliance, and security administration." While writing a remote version check for this software, Tenable discovered an exposed RMI service on TCP port 6099. Based on recent Java deserialization vulnerabilities via RMI interfaces, a quick check was done to see if this software was vulnerable as well. Spoiler: it is.

Exposed RMI Registry

When installed, the HP NA administration server opens up a listening socket on TCP port 6099. Cygwin sorcery:

$ netstat -ab

Active Connections

  Proto  Local Address          Foreign Address        State
TCP           WIN-45AKP1004KU:0      LISTENING	 [java.exe]

The listening socket is bound to, which means that it listens on all interfaces. While port 6099 is not the standard RMI registry port, looking into some of the HP NA code you can observe this snippet:

int port = Config.getConfig().get("swim/SWIMServer/port", 6099);
registry = LocateRegistry.getRegistry(port);

The above is a clear indication that an RMI registry is listening on port 6099. To verify, you can use Tenable’s rmiregistry_detect.nasl plugin:

----------[ Executing ./rmiregistry_detect.nasl ]------

Here is a list of objects the remote RMI registry is currently
aware of :


----------[ Finished ./rmiregistry_detect.nasl ]------

HTTP-based deserialization attacks are so last week.

Java Deserialization Vulnerabilities

Java deserialization vulnerabilities are not new, but have been talked about more recently thanks to FoxGlove Security’s infamous article, “What Do WebLogic, WebSphere, JBoss, Jenkins, and Your Application Have in Common? This Vulnerabilitypublished on November 6, 2015. This article discusses getting remote code execution in a variety of products using serialized Java objects. At the time of writing this, the most popular published objects used for deserialization attacks can be found in the GitHub project "yososerial". The most well-known objects leverage common libraries such as Apache Commons Collections, Groovy, and Spring.

The RMI protocol is especially vulnerable to deserialization attacks because the protocol is specifically crafted around remote Java object manipulation. All an unauthenticated attacker needs is to find a vulnerable library that can be used for exploitation. In the case of HP NA’s RMI registry a remote attacker has access to two libraries that will allow them to achieve remote code execution via serialized objects:

  1. Commons-Collections
  2. Commons-BeanUtils

In order to exploit the RMI registry you bind to it using the evil objects that ysoserial generates. These evil objects abuse serializable objects within the libraries along with Java’s proxy and reflection mechanisms in order to execute a command via Runtime.exec().

Proof of Concept

This vulnerability can be easily verified by using ysoserial’s RMIRegistryExploit.java. This is the same technique used by FoxGlove Security against OpenNMS in their article and they have a very simple write up on how to use it. However, the above requires some configuration and Java know-how so Tenable has authored two PoC scripts that were shared with the vendor


The first PoC, commons_collections_mkdir.py, uses ysoserial’s CommonCollections3 (org.apache.commons.collections.functors.InstantiateTransformer) to exploit the remote server and create the directory “C:\Users\Public\commons_collections_exploit”. To use the script, simply pass the server address in the command line like so:

[email protected]:~/hp_na_rmi$ python commons_collections_mkdir.py
[+] Connecting to the RMI registry at
[+] Initiating JRMI handshake
[+] Sending commons collections exploit payload
[+] Success!

The second PoC, commons_beanutils_mkdir.py, uses ysoserial’s CommonBeanutils1 (org.apache.commons.beanutils.BeanComparator) to exploit the remote server and create the directory “C:\Users\Public\commons_beanutils_exploit”. To use the script, simply pass the server address in the command line like so:

[email protected]:~/hp_na_rmi$ python commons_beanutils_mkdir.py
[+] Connecting to the RMI registry at
[+] Initiating JRMI handshake
[+] Sending beanutils exploit payload
[+] Success!

To verify that the exploits worked, we checked the C:\Users\Public path on the HP NA server:

 Volume in drive C is Malacostraca.
 Volume Serial Number is 4199-7460

 Directory of C:\Users\Public

03/29/2016  02:10 PM    <DIR>          .
03/29/2016  02:10 PM    <DIR>          ..
03/29/2016  02:10 PM    <DIR>          commons_beanutils_exploit
03/29/2016  02:04 PM    <DIR>          commons_collections_exploit
07/14/2009  01:08 AM    <DIR>          Documents on Lobsters
07/14/2009  12:54 AM    <DIR>          Downloads
07/14/2009  03:45 AM    <DIR>          Lobster Pictures
07/14/2009  12:54 AM    <DIR>          Music Inspired by Lobsters
07/14/2009  12:54 AM    <DIR>          Videos of Lobsters
               0 File(s)              0 bytes
              10 Dir(s)  42,413,776,896 bytes free

Tenable does not have access to more recently patched versions (10.00.02, 9.22.04,), so we were unable to test those. And no, we aren't sharing our PoC toys.


HPE has made solutions available to resolve the vulnerability for the impacted versions of Network Automation. Please see the associated HP advisory for details.

Disclosure Timeline

2016-03-29 - Issue Discovered
2016-04-04 - Submitted to ZDI for consideration, case bainesjr0004
2016-04-25 - ZDI offers $1000, we humbly accept
2016-09-21 - ZDI publishes ZDI-16-523 (aka CVE-2016-4385)

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]