Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

OpenNMS RMI Exploit

DZone's Guide to

OpenNMS RMI Exploit

A recent article showed a potential remote code exploit in several apps, including OpenNMS. Here's an exploration of the exploit, and how to ensure you're secure.

· Performance Zone ·
Free Resource

SignalFx is the only real-time cloud monitoring platform for infrastructure, microservices, and applications. The platform collects metrics and traces across every component in your cloud environment, replacing traditional point tools with a single integrated solution that works across the stack.

Recently, my RSS feed on OpenNMS stories turned up an article listing a possible remote code execution exploit in a number of applications, including OpenNMS.

In it, the researcher shows that it is possible to execute code on the OpenNMS server remotely due to a bug in the Apache commons library, which OpenNMS uses.

We’re a little unhappy that they published this without letting us know first (note that the e-mail address “security at opennms dot org” exists for reporting such things), but it is pretty easy to make sure that your instance of OpenNMS is safe. Simply configure the server’s firewall to disable remote access to port 1099 (it will need to remain for localhost).

was happy to notice that the example he uses seems to be related to OpenNMS running on Windows. It can be a bit tricky to get OpenNMS to work on Windows, and perhaps the Windows default firewall doesn’t block port 1099 so that it why they noticed it.

It is a good idea to run something like iptables on your OpenNMS server and limit remote access to a minimal set of ports. Technically, the only port you really need access to is 8980, which is the default port for the webUI. I would assume that you would want port 22 for ssh access (unless you want to use the console for all configuration). In addition, port 162 should be open for SNMP trap reception.

That should be it. Now the application needs access to other ports (such as 5817 for events) so those need to remain accessible from localhost (127.0.0.1 or ::1) but that limits all exposure to only people who have shell access to the server, which we assume you limit to those people you trust. Remember to include IPv6 firewall rules if you use it.

An easy test to see if that port is remotely accessible would be to run:

telnet [IP or hostname of OpenNMS server] 1099

from a remote system to see if you can access the port. No connection should be made.

Sorry about this, but as I mentioned this wasn’t revealed to us until after the exploit was public. We are looking in to how we can better protect against this issue from a code change standpoint, but until then simply blocking access to the port will prevent most problems. We do plan to have a code fix in place soon.

SignalFx is built on a massively scalable streaming architecture that applies advanced predictive analytics for real-time problem detection. With its NoSample™ distributed tracing capabilities, SignalFx reliably monitors all transactions across microservices, accurately identifying all anomalies. And through data-science-powered directed troubleshooting SignalFx guides the operator to find the root cause of issues in seconds.

Topics:
performance ,security ,rss ,rmi ,exploits ,opennms

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}