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 0.0.0.0:6099 WIN-45AKP1004KU:0 LISTENING [java.exe]
The listening socket is bound to 0.0.0.0, 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);
LocateRegistry.createRegistry(port);
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 :
rmi://192.168.1.11:49216/SWIMServer
----------[ 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 Vulnerability” published 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:
- Commons-Collections
- 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:
lobster@nephropidae:~/hp_na_rmi$ python commons_collections_mkdir.py 192.168.1.11
[+] Connecting to the RMI registry at 192.168.1.11:6099
[+] 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:
lobster@decapoda:~/hp_na_rmi$ python commons_beanutils_mkdir.py 192.168.1.11
[+] Connecting to the RMI registry at 192.168.1.11:6099
[+] 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:
C:\Users\Public>dir
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.