Deserialization of arbitrary data leads to RCE in librenms/librenms
Reported on
Oct 8th 2022
Description
LibreNMS includes support for monitoring applications, one of which is memcached. When polling for memcached, the data returned by the agent to the LibreNMS server is not verified before it is deserialized.
Because LibreNMS has quite a few dependencies, it is easy to find a working gadget chain to exploit this arbitrary deserialization vulnerability. The code in the POC uses Laravel/Rce9 from the PHPGGC project.
This vulnerability enables a monitored device to gain remote code execution on the monitoring server.
Proof of Concept
The first steps are performed on an attacker controlled device.
First we generate a payload with PHPGGC, in this case we will just make it drop a file in the /tmp folder, but this could be anything.
./phpggc laravel/rce9 shell_exec 'echo deserialization_is_awesome > /tmp/this_is_a_bad_vuln' > /tmp/exploit_payload
Next we install snmpd on the attacker server, and add this line to /etc/snmp/snmpd.conf to make it return the payload when queried by the monitoring server for memcached:
extend memcached /usr/bin/cat /tmp/exploit_payload
Now, moving to the the victim monitoring server, we add the attacker's device to be monitored (if configured for auto-discovery, this step would not be required, this configuration setting determines whether or not user interaction is required for exploitation). After adding and polling the device for the first time, the file /tmp/this_is_a_bad_vuln should have been added, indicating we executed code on the monitoring server.
Impact
This vulnerability allows a user with access to a monitored device to take control of the monitoring server.
Occurrences
memcached.inc.php L13
This is the line where the vulnerability is introduced. The $data variable is set using attacker-controlled content, and it's type is not verified (it expects to be unserialized to an array but this is not enforced).