Claroty Team82’s finds chain vulnerabilities in Nagios Core software used in IT, IoT, OT environments
New research has identified chain vulnerabilities on network management systems used in various IT, IoT, and OT networks, such as Nagios Core monitoring software. Claroty Team82’s team detected among other things remote code execution with root privileges, privilege escalation, and credential theft security loopholes, and privately disclosed 11 vulnerabilities in Nagios components, all of which were fixed in updates released in August.
Team82’s research led to the discovery of the vulnerabilities in Nagios XI that can lead to remote code execution with the same privileges as an Apache user, as Nagios XI commonly runs on an Apache web server, besides other vulnerabilities, according to a Claroty blog post. By chaining some of these vulnerabilities, an attacker can achieve post-authentication remote code execution with high privileges (root).
Nagios Core is an open-source industry standard used for monitoring and alerting. It watches hosts and services that users specify, alerting when things go bad and when they get better. Nagios Core was originally designed to run under Linux. Some of the features of Nagios Core include monitoring of network services, simple plugin design that allows users to easily develop their service checks, and the ability to define network host hierarchy using ‘parent’ hosts, allowing detection of and the distinction between hosts that are down and those that are unreachable.
Nagios has provided a fix for each vulnerability in Nagios XI 5.8.5 or above, Nagios XI Switch Wizard 2.5.7 or above, Nagios XI Docker Wizard 1.13 or above, and Nagios XI WatchGuard 1.4.8 or above, the post added. Nagios said that thousands of organizations worldwide use its software to monitor networks with Comcast, Shell, DHL, L’Oreal, Texas Instruments, Toshiba, and dozens of other companies listed on its website as users.
Nagios XI is a proprietary web-based platform that uses Nagios Core. XI expands Core’s capabilities by adding additional features to enhance IT operations and offers an easy-to-use graphical experience for monitoring the health and condition of mission-critical servers, network devices, and machines connected to the network. To provide this capability, Nagios XI uses many scripts and executables and supports protocols such as SNMP, SSH, and Windows Management Instrumentation (WMI) to invoke commands and derive statistics from its monitored devices, Claroty said.
To be able to use those protocols, the administrator that configures the devices must supply their credentials to Nagios XI to connect to those devices. Those credentials are saved inside the Nagios database for further use, Claroty said. Nagios also allows for plugins to be installed, expanding the capabilities of Nagios XI. The downside is that this also expands the attack surface available to threat actors, and increases the number of vulnerabilities that may be present.
Another feature of Nagios XI that vastly expands the platform’s attack surface is its autologin feature. “This feature was built with NOC admins in mind, and allows a Nagios administrator to set up a read-only user account that any user can connect to without the need for credentials,” Noam Moshe, a Claroty researcher wrote in the post. “While this feature might be useful for NOC purposes, allowing users to easily connect to the platform and view information without the need for credentials also allows attackers to gain access to a user account in the platform, thus rendering any post-auth vulnerability exploitable without authentication.”
The Nagios XI’s Auto-Discovery tool allows system administrators to scan a network segment to automatically discover new machines or devices. Auto-Discovery uses a PHP script that scans the network segment, identifies a new server, and pinpoints exactly what machine it is. In a bid to make the whole operation seamless, Nagios XI allows for running those scans automatically after a certain amount of time. This is done by creating a job in the system, which behind the scenes sets up a crontab file (a file inside the Linux subsystem that allows the execution of commands at time intervals) that executes the Auto-Discovery script with the user-given arguments.
To create the crontab, the server takes the job ID and creates a directory containing the crontab, the output and input of the scripts, and a few XML files that manage script configuration, the researcher said. However, during this creation, the job ID is given by the user and is not checked by the server as to whether it is a legitimate ID.
A malicious user could abuse this lack of checks to supply the server with path-traversal characters (../), allowing the user to create the crontab in any directory they choose (only in directories the Apache user is allowed to write in), he added. By abusing this lack of checks, an attacker could write a file inside a directory of the webserver, which is an effective way to drop a webshell or execute PHP scripts.
Furthermore, some user-given parameters are reflected in the crontab, thus allowing a malicious user to control a few parts of the crontab file content, the post added. This could allow an attacker to write PHP code inside the crontab, thus achieving code execution in Apache’s user context. Using those two primitives (path traversal and wrong permissions) together, an attacker could create a PHP webshell in the web server’s directories, thus achieving remote code execution.
Another vulnerability identified by Claroty’s Team82 team involved a vulnerable ‘sudo’ script that allows users to elevate their privileges to root using the getprofile.sh script. This script is meant to be used by either the Apache or Nagios user, and it creates a backup directory with the system’s profile and settings, according to Moshe. Behind the scenes, this bash script creates a directory specified by a given argument, collects data about the system’s state and configurations, saves the data in the created directory, and creates an archive of the profile.
“However, we discovered the script does not validate the directory name it receives as an argument (the directory name where the files will be saved), but just appends it to its pre-configured directory path,” Moshe wrote. This lack of checks could allow a malicious user to execute this script with an argument containing path traversal characters (../), thus allowing them to save the system profile in any directory they choose beyond the preconfigured directory prefix, he added.
On further analysis into the script, Claroty’s Team82 team noticed that it reads some configuration files dictating where they are saved in the system. Specifically, “we see that it reads a file named ‘nagios.cfg’ that configures a log file, which in turn the script will write inside the directory specified by the user. When we looked at the file, we were surprised to note that this file’s owner is the Apache user, and they have permission to write to this file,” Moshe said. Therefore, the Apache user could change the configuration file and point the log file to one under the attacker’s control, and whenever the sudo script runs, the attacker-controlled file will be copied to the directory specified by the user, the researcher added.
An attacker could combine those two primitives to achieve arbitrary command execution in the context of the root user, Claroty said. An attacker would just need to create a directory in any writable directory. In it, an attacker would create the nagios.txt file that the sudo script writes the log file to, and assign it as a symbolic link to a root-owned file. In our example, we’ve chosen the sudoers files, dictating what commands users could execute with the sudo command, the research team added.
Then, an attacker would create an edited sudoers file allowing the Apache user to execute any sudo commands, and save them. The attacker would also edit the nagios.cfg file and make the log file point to the edited sudoers file, Moshe said. An attacker could then execute the sudo script, pointing the directory to the previously created directory. Whenever the script tries to copy the log file, it will be copied to the symbolic link, thus editing the real file, he added.
Related
