Have you configured Nessus to betray you?
Introduction
There is a terrible, yet surprisingly common, Nessus authenticated scanning configuration that could be the bane of your network during a compromise. If used, it is the equivalent of saying, “Welcome to the network! Oh, and here’s the admin password for all our assets!” to every host that appears on your network.
Nessus is the vulnerability scanner of choice by administrators and security professionals alike, but adding a security appliance to your network doesn’t necessarily make you more secure. Security is a complex goal and requires in-depth knowledge of the inner workings of your systems and how they interact with each other. In this blog post, we will be covering a misconfiguration common in Nessus installations across organizations and detailing how this misconfiguration can have lethal consequences for your network’s security posture. We will then show you how to leverage this weakness yourself as a proof-of-concept and show you how to remediate this vulnerability so that you are no longer affected.
Authenticated vs. Unauthenticated Scanning
Nessus can perform a variety of scans. In this post, we will be discussing authenticated scans such as the Credentialed Patch Audit offered by Nessus. This is opposed to the basic, blackbox network-based unauthenticated scan that entails launching several network-based vulnerability tests against a set of hosts. These blackbox tests are launched against the various services running on a target, and depending on the way that service responds, Nessus reports its judgment on whether that service is affected by the tested vulnerability. Since this method of testing may rely on actually exploiting the service in question, this method of testing carries a degree of risk associated with it, as well as a high number of false positives and false negatives.
Credentialed Patch Audits differ from this by instead logging into the target hosts with configured credentials and checking to see if those hosts are patched against known vulnerabilities. Many administrators who opt to perform a Credentialed Patch Audit will either create a local administrator account on all hosts to be scanned or will use an existing administrator account for this purpose. In this case, the administrator will configure Nessus to perform the Credentialed Patch Audit scan on all subnets the said administrator is responsible for. Herein lies the problem that we will be discussing.
The Problem
If Secure Shell (SSH) via password authentication is used as Nessus’s means of authentication for hosts to be tested (as it commonly is for Linux systems), then these administrative credentials are being given to every host with an IP address on your network. Because password authentication is symmetric in nature, it is important to understand that Nessus will be sending the configured credentials to every SSH service on the tested networks. This becomes a serious problem if an attacker gains access to your network. An attacker could gain an IP address on your network in various ways, including compromising an existing host (via phishing or some technical exploit), or plugging a new host into a network jack or some other way of accessing your network. If an attacker successfully acquires an IP address that is subject to credentialed Nessus scanning, they simply need to listen for the incoming credential pair that Nessus will attempt against them. Because these credentials are usually administrative credentials, the impact of this misconfiguration is usually the total compromise of almost every device on your network (every host that accepts those credentials for access).
Proof of Concept (Heralding Tutorial)
There are multiple honeypots that can emulate the protocols of a variety of services, such as SSHesame (https://github.com/jaksi/sshesame) and Heralding (https://github.com/johnnykv/Heralding), and log all attempted credentials. We will be covering Heralding in this blog post.
Installation instructions for Heralding can be found in Heralding’s github repository (same as linked earlier).
Alternatively, follow our installation instructions (tested on Kali Linux):
To install Heralding, first install the necessary requirements:
sudo apt-get install -y python-dev build-essential libssl-dev libffi-dev python3-pip
Then use pip to install Heralding:
pip3 install heralding
Heralding can be started by simply running “heralding” at this point.
Next, create a credentialed patch audit scan in Nessus:
We will configure it to authenticate with password authentication. Nessus warns us about this in their GUI.
Then, we start Heralding and run the scan in Nessus. We can see in Heralding’s output the SSH connections being made to the honeypot instance.
Attempted credentials are stored in the file “log_auth.csv”.
Remediation
Next we will discuss two ways to remediate this issue and securely configure Nessus credentialed scanning.
Method 1:
Upload an SSH known_hosts file to Nessus while configuring the scan. A screenshot emphasizing this option is shown below.
This will prevent Nessus from connecting to any hosts that fail the known_hosts file check and hence will mitigate the threat of rogue hosts listening on your network. However, if one of your “known hosts” is compromised, an attacker could leverage that compromised host to get the credentials Nessus is using.
Method 2:
Use SSH public-key authentication instead of a password. You can read more about public-key authentication here. A screenshot of this part of the configuration process is shown below.
In this option, a known_hosts file is not necessary. Additionally, this option prevents an attacker from being able to capture credentials even if one of your legitimate hosts is compromised. This is because public-key authentication doesn’t use a password, but instead a cryptographic challenge-response that cannot be replayed. Shorebreak recommends this method of remediation over the lone usage of a known_hosts file.
Conclusion
In conclusion, remember that security is a complex goal and requires in-depth knowledge of the inner workings of your systems and how they interact with each other. There is no substitution for due diligence. Even the implementation of security products that have the single goal of aiding your security program can have disastrous consequences to your network if their implementations are not carefully considered and reviewed for issues.
Our staff at Shorebreak Security have years of experience conducting penetration tests and identifying security issues like the one just discussed. If you are interested in having us test your network, reach out to us at info@shorebreaksecurity.com.
Credits
Author: Erik Ronstrom – Security Engineer, Shorebreak Security Inc
Peer Reviewed by: Cory Cardio – Principal Security Engineer, Shorebreak Security Inc