Security researchers demonstrated an attack chain against Nagios, a popular open-source IT management and monitoring solution, that combined multiple vulnerabilities to achieve remote code execution. The report highlights the privileged position that infrastructure monitoring software has inside networks and their potentially large attack surface since they need to talk to and collect information from many endpoints.
“The idea of vulnerabilities within monitoring software or other management or information aggregation services has been popularized by the recent attacks on SolarWinds, and it is important to assess such software and consider the possibility of compromise,” researchers from security firm GRIMM wrote in a detailed write-up of the Nagios attack they devised. “Any large network should be investing in both network monitoring and endpoint protection, but security should be considered in the deployment of these solutions.”
Last year’s software supply-chain attack against SolarWinds Orion, a commercial infrastructure monitoring and management solution, has shown that such products can be an attractive target for hackers due to the access they have and the data they collect on network assets. Their functionality and privileged position make them great launchpads for lateral movement activities.
Small vulnerabilities can add up to big risk
Nagios has a free open-source version called Nagios Core and a commercial edition called Nagios XI that is built around Nagios Core, but has a redesigned web interface, database, and various plug-ins installed by default. GRIMM’s security review focused on Nagios XI, which is likely to be used by enterprise customers, but some vulnerabilities found apply to both editions. The official website says the framework is used by over 9,000 customers worldwide including well-known brands such as Cisco, Verizon, Airbnb and Paypal.
After the SolarWinds incident, security companies turned their attention to products like SolarWinds Orion such as Nagios, and since the beginning of the year there have been at least three Nagios security updates patching serious vulnerabilities uncovered by researchers. One remote command injection flaw was even exploited in the wild to install cryptomining malware on servers.
“Given the importance of such a target, one naturally would expect that the monitoring server would be housed internally within a network and inbound network access would be tightly controlled, but that doesn’t mean there’s no way in,” the GRIMM researchers said. “Take Nagios as an example. Nagios’s primary user interface is a web application that is designed to execute administration tasks. As a result, there are many places where it handles commands that run with elevated privilege. This means that there are many ways that a small issue can snowball into a big problem for a network, and the amount of flexibility and features means there’s a lot of room for things to go wrong.”
The GRIMM researchers found several vulnerabilities in the Nagios web interface including cross-site scripting (XSS) issues that can be used to add new administrative accounts or execute arbitrary native code, improper access controls on web directories that allow the upload of web shells and arbitrary PHP execution, and a server-side request forgery (SSRF) that allows scanning request redirection.
Taken separately, these issues would not be very serious since they execute in the context of the Nagios web application or the user accessing the Nagios web interface, but the researchers also found flaws that can escalate the privileges to root. For example, one functionality allows the migration of configurations from a Nagios server to another. In the process, a migration script gets executed as root, so if they control the web application the attackers can trigger the process and use a maliciously crafted configuration archive to trigger the execution of malicious scripts or commands as root.
How attackers can exploit the Nagios vulnerabilities
Separately, the www-data/apache user under which the Nagios web application runs can execute a shell script called manage_services.sh via sudo (super user do) without a password. On certain servers this allows execution of arbitrary commands as root.
“On systems with newer versions of systemctl, executing the vulnerable script with ‘sudo /usr/local/nagiosxi/scripts/manage_services.sh status nagios’ results in a call to ‘systemctl status nagios’, which invokes ‘less’ as the pager for the output,” the researchers explained. “Once ‘less’ has been spawned, shell commands can be run by prepending them with an exclamation point.”
So, the XSS and other web interface issues can be used to reach other flaws that can lead to full control over the underlying server. But how would an attacker reach the Nagios web interface in the first place?
As with most reflected XSS issues, the straightforward way for attackers to attack them is to craft a malicious link and trick a Nagios administrator to click on it. If their session in the Nagios web interface is active, the payload will execute immediately. If not, it will execute after they log in. The GRIMM researchers created a proof of concept for this attack along with a video demonstration. However, it’s not the only way.
The Nagios server communicates with agents deployed on the monitored endpoints or servers to collect information or receive status updates. This communication can be initiated by the agents or by the Nagios server and there are three agent APIs supported called NCPA, NRPE and NSCA.
NSCA (Nagios Service Check Acceptor) is implemented as a plug-in that comes installed by default with Nagios XI. The researchers found that data sent back by NSCA agents is not being sanitized, so it can be abused to inject attacker-controlled data that then can be displayed in the web interface, triggering the XSS attacks when viewed by an administrator in their browser. In a separate proof-of-concept attack, the researchers exploit this NSCA weakness to trigger an alert that a host is offline and when the administrator logs in to view the alert, a JavaScript payload would execute triggering the server migration functionality that will take advantage of the privilege escalation vulnerability to gain root access on the server.
So, the full attack chains can be launched either through social engineering that requires some user interaction and also by compromising an endpoint system that has an NSCA agent deployed and then attacking the Nagios server through it.
Since NSCA is maintained as a separate code base, the vulnerability has been fixed in version 2.10.1 of the NSCA plug-in and the XSS and privilege escalation ones in Nagios XI version 5.8.7.
Gaining root access on a Nagios server is beneficial to attackers for multiple reasons. Such servers contain a lot of information about the network configuration and the services running on it, which can be very useful for attackers to identify additional interesting targets on the network. Also, by controlling the Nagios server, attackers can manipulate the information that is displayed to administrators in the web interface to conceal potential malicious attacks against monitored endpoints. If attacks are launched against those endpoints from the system hosting the Nagios server itself, the network activity might not be flagged as suspicious because the Nagios server is cleared to talk to those systems.
Nagios servers can also have credentials or SSH keys saved that are being used to remotely deploy monitoring agents on other systems. If those credentials are stolen, they can give attackers easy access to those systems.
Mitigating risk from Nagios vulnerabilities
“The threat of attackers swimming upstream from endpoints to servers is real, but there are still strategies to reduce risk,” the researchers said. “Network segmentation and blocking traffic between expected hosts reduces the attack surface of these key servers, as does reducing the amount of shared credentials across systems.”
More generally organizations should try to minimize the number of software products, user accounts, and systems that have elevated permissions on their networks. This will not prevent all attacks but could force attackers to rely on noisier techniques that are easier to detect than the abuse of legitimate credentials or privileges.
Copyright © 2021 IDG Communications, Inc.
