Have you set up a Nessus scanner and wondered why in the credentialed scan settings menu, the password form field has ‘unsafe!’ next to it? Well, if you looked below that field, you would find a simple explanation, “This password could be compromised if Nessus connects to a rogue SSH server…”. While Nessus gratefully gives us this heads up, other vulnerability scanning platforms may not, but they still run the risk of being tricked into connecting to a malicious target system. Let’s take a look and see what exploiting this attack vector looks like, and then, what mitigation methods exist. Here is the stage: we are an attacker that is on a target network, looking to dive deeper. During network discovery, we review DNS entries to identify and categorize new targets. Luckily, this network has everything nice and neatly labeled, so when we throw together a little nslookup script using the subnet we are on, we come across a system that appears to host a Nessus vulnerability scanner [Image 1 & 2]. Additional enumeration confirms that there is a Nessus scanner running on port 8834. From here, due to poor password practices and some common password guessing, we are able to authenticate to the scanner’s web interface and proceeded to do some poking around inside.
While we are working through and gathering information inside this compromised scanner, we notice a scheduled (and authenticated) SSH scan. The password is conveniently blocked out, but here we are, all smiles, knowing we will be able to capture SSH credentials. When this scan runs, Nessus will throw these credentials at whatever IP address, IP range or subnet is specified. Knowing this, we will modify the target list for this scan to be directed at our own IP address with the goal of catching those credentials in plaintext. To do this, we will use a tool called Heralding (found here: https://github.com/johnnykv/heralding).
Heralding is a tool that is used to capture credentials for a number of protocols. It functions as a honeypot which will listen for authentication attempts. When an authentication attempt is made, Heralding will store the credentials in a log file [Image 3]. With the scan kicked off and Heralding running, we are able to capture the stored scan credentials in plaintext. Now we have SSH credentials that may be abused throughout the target environment.
This may seem farfetched; an attacker getting inside a vulnerability scanner and being able to scan specific IPs is a best-case scenario for them, and a worst-case scenario for the target. However, this is not the only use case for this vulnerability. Attackers still have an opportunity to capture credentials without touching the inside of the scanner.
Scheduling scans to be conducted every week is not uncommon, and neither is setting the scope to be an entire subnet or IP range. If an attacker, with enough time and patience, gains access to the network that is being scanned and discovers the scanner, they could set up Heralding to listen for credentials. Doing so would allow them to focus on other attack vectors in the network while only checking back periodically for plaintext credentials.
Understanding how this attack works is key to understanding how to mitigate the risk of it being used against your own scanner. When setting up a credentialed scan, Nessus will warn you to upload a ‘known_hosts’ file. This will aim the scanner at hosts that you have deemed safe to scan. However, this does not protect against a compromised host or a malicious insider from stealing those credentials. A better way to mitigate this risk would be to drop password-based authentication entirely for the safer and more secure method of SSH public-key authentication (Setup explained here: https://community.tenable.com/s/article/SSH-Public-Key-Authentication). Using this would eliminate the risk of captured Nessus scan credentials completely.
It should also be noted that credential exposure due to vulnerability scanning is not solely an SSH issue. Windows domain hashes can also be exposed if an attacker is positioned in your network running Responder (https://github.com/lgandx/Responder) [Image 4].
When the scanner attempts to authenticate to the remote host running Responder, the domain hash will be captured [Image 5]. Of course, a Windows machine sharing a hash is nothing out of the ordinary in the security world. However, this is where strong, complex passwords come into play. If the target is utilizing a poor password policy, these hashes can be loaded into a password recovery tool and cracked easily, allowing an attacker to potentially gain domain admin access to a network. [Image 6 & 7]
Vulnerability scanners are an extremely powerful and helpful tool when configured appropriately. It is also worth noting that this technique is not solely a vulnerability scanner issue. Other applications, such as remote management software, which use administrative credentials to authenticate to remote machines, can be exploited the exact same way. When incorrectly configured, these administrative tools can give an attacker a helpful push deeper into a network. Always remembering that security takes time and effort to implement is key to ensuring a safe environment. When corners are cut, or a tool is incorrectly configured, risk may be greatly increased. Taking the appropriate steps to configure vulnerability scanners and remote management tools will help prevent these tools from being used against you during your next penetration test, or worse, in the event of an actual security breach.
