Securing Network Management Systems: Nagios XI

Executive Summary

• Claroty Team82's latest research focuses on network management systems, starting with Nagios, one of the most popular in the world used by thousands of organizations.

• Team82 privately disclosed 11 vulnerabilities in key Nagios components, all of which were fixed in updates released in August.

• Team82 was able to chain vulnerabilities to gain remote code execution with root privileges, as well as privilege escalation, credential theft, and more.

• Network management systems are attractive targets because of their oversight of core servers and critical network components.

Table of Contents

1. Nagios-XI-Vulnerabilities

2. Nagios Network Management System

3. Chaining Vulnerabilities to Get Remote Code Execution

4. Recommendations

The SolarWinds and Kaseya attacks were well-documented and devastating intrusions at the heart of IT and network management supply chains. In each case, alleged state actors were able to infiltrate the mechanisms used by the vendors to ship software updates to customers, and infect those updates with malware, including ransomware. In both cases, tens of thousands of customers installed compromised updates, and the trust both vendors built with customers was damaged.

SolarWinds and Kaseya were likely targeted not only because of their large and influential customer bases, but also because of their respective technologies' access to enterprise networks, whether it was managing IT, operational technology (OT), or internet of things (IoT) devices. Network management systems have oversight of core servers, devices, and other critical components in the enterprise network; moreover, given that these systems are used to monitor servers, they often contain many network secrets such as credentials or API tokens that would be attractive to attackers.

Claroty's Team82 researchers could not ignore this ongoing threat to network management systems and began their work by mapping popular monitoring software in various IT, IoT, and OT networks, including Nagios, or Nagios Core to be more specific.

What is Nagios XI?

Nagios Core is a popular open-source tool for monitoring IT infrastructure for performance issues, event scheduling and processing, alerting, and more functionality related to network health. Nagios XI is a proprietary web-based platform using Nagios Core. XI expands Core's capabilities by adding additional features to enhance IT operations. Network operations center (NOC) staff and system administrators use the platform to view the current state of managed servers and workstations. Nagios says that thousands of organizations worldwide use its software to monitor networks; Comcast, Shell, DHL, L'Oreal, Texas Instruments, Toshiba, and dozens of other companies are listed on its website as users.

Team82's research led to the discovery of 11 exploitable vulnerabilities in Nagios XI that can lead to remote code execution with the same privileges as an Apache user (Nagios XI commonly runs on an Apache web server), credential theft, phishing attacks, local privilege escalation to user permissions, and local privilege escalation to root. By chaining some of these vulnerabilities, an attacker can achieve post-authentication remote code execution with high privileges (root).

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.

Nagios XI Vulnerabilities

• CVE-2021-37353: Nagios XI Docker Wizard before version 1.1.3 is vulnerable to server-side request forgery (SSRF) due to improper sanitization in table_population.php

• CVE-2021-37352: An open redirect vulnerability exists in Nagios XI before version 5.8.5 that could lead to spoofing. To exploit the vulnerability, an attacker could send a link that has a specially crafted URL, and convince the user to click the link.

• CVE-2021-37351: Nagios XI before version 5.8.5 is vulnerable to insecure permissions and allows unauthenticated users to access guarded pages through a crafted HTTP request to the server.

• CVE-2021-37350: Nagios XI before version 5.8.5 is vulnerable to SQL injection vulnerability in the Bulk Modifications Tool due to improper input sanitization.

• CVE-2021-37349: Nagios XI before version 5.8.5 is vulnerable to local privilege escalation because cleaner.php does not sanitize input read from the database.

• CVE-2021-37348: Nagios XI before version 5.8.5 is vulnerable to local file inclusion through improper limitation of a pathname in index.php.

• CVE-2021-37347: Nagios XI before version 5.8.5 is vulnerable to local privilege escalation because getprofile.sh does not validate the directory name it receives as an argument.

• CVE-2021-37346: Nagios XI WatchGuard Wizard before version 1.4.8 is vulnerable to remote code execution through Improper neutralization of special elements used in an OS command (OS Command injection).

• CVE-2021-37345: Nagios XI before version 5.8.5 is vulnerable to local privilege escalation because xi-sys.cfg is being imported from the /var directory for some scripts with elevated permissions.

• CVE-2021-37344: Nagios XI Switch Wizard before version 2.5.7 is vulnerable to remote code execution through improper neutralization of special elements used in an OS command (OS Command injection).

• CVE-2021-37343: A path traversal vulnerability exists in Nagios XI below version 5.8.5 AutoDiscovery component and could lead to post-authenticated RCE under the security context of the user running Nagios.

Nagios XI Network Management System

Nagios XI 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 do so, 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. In order to be able to use those protocols, the IT administrator that configures the devices must supply their credentials to Nagios XI in order to connect to those devices. Those credentials are saved inside the Nagios database for further use. 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.

Nagios XI is a web application written in PHP. However, in order to make it difficult to use the product without a proper license, Nagios guards its source code using SourceGuardian, a service that encrypts PHP source code. SourceGuardian does so by compiling the source code to a bytecode, and then it encrypts the bytecode. A loader function is then used to decrypt the payload and interpret the bytecode. As a result, SourceGuardian-protected scripts cannot be easily reversed, and instead provide only an encrypted blob of data.

Another feature of Nagios XI that vastly expands the platform's attack surface is its auto login 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. 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.

With that in mind, our research on the Nagios XI platform led us to find a few vulnerabilities that, when chained, offer an attacker root access to the Nagios system, the highest possible privileges.

Chaining Vulnerabilities to Get Remote Code Execution

CVE-2021-37343: Post-Auth Remote Code Execution Through Path Traversal

From Web User to Executing Code as an Apache User

Nagios XI's Auto-Discovery tool allows system administrators to scan a network segment in order 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 order 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.

In order 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. 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 in order to supply the server with path-traversal characters (../), thus allowing the user to create the crontab in any directory they choose (only in directories the Apache user is allowed to write in). By abusing this lack of checks, an attacker could write a file inside a directory of the web server, which is an effective way to drop a webshell or execute PHP scripts.

Furthermore, some user-given parameters are reflected into the crontab, thus allowing a malicious user to control a few parts of the crontab file content. This could allow an attacker to write PHP code inside the crontab, thus achieving code execution in the 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.

CVE-2021-37347: Local Privilege Escalation Through Incorrect Permission Assignment for Critical Resource

From Apache User to Executing Code as Root User

Another vulnerability identified involves 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. 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. 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.

Looking deeper into the script, we notice 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. 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.

An attacker could combine those two primitives in order to achieve arbitrary command execution in context of the root user. 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.

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. 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.

This achieves a write-what-where primitive: writing content to any file in the system the attacker chooses. This primitive could allow for code execution, as we showed in our example earlier with the sudoers file.

Nagios XI Proof of Concept

As a demonstration of our findings, we created a proof-of-concept exploit using a few vulnerabilities, which results in a reverse shell (remote bash shell) from our Nagios XI server with root privileges. In light of the auto login capability, it could be used as a complete pre-auth RCE.

In order to achieve this, our PoC implements the following vulnerabilities:

1. CVE-2021-37343: Post-Auth Remote Code Execution. We use this vulnerability in order to execute code on the server in the context of the Apache user.

2. CVE-2021-37347: Local Privilege Escalation. We use this vulnerability to escalate our privileges from Apache user to root user, and then execute shell commands with root privileges.

Recommendations

In August, Nagios addressed the vulnerabilities privately disclosed by Team82 through updates to Nagios XI, Nagios XI Docker Wizard, Nagios XI WatchGuard Wizard, and Nagios XI Switch Wizard.

In addition to promptly updating those affected systems, users should follow some basic rules about keeping network management systems secure.

• Trust:

  These systems require extensive trust and access to network components in order to properly monitor network behaviors and performance for failures and poor efficiency. They may also extend outside your network through the firewall to attend to remote servers and connections. Therefore, these centralized systems can be a tasty target for attackers who can leverage this type of network hub, and attempt to compromise it in order to access, manipulate, and disrupt other systems.

• Monitor:

  Access to the network management system should be closely monitored and limited to privileged insiders. All connections and activity should be monitored and alerted upon.

This report is the first in a series of research into the security of network management systems where Team82 examines what it means for OT, IT, and IoT domains.