Protecting Scanning Credentials from Malicious Insiders

Security breaches can come from those you least suspect. Have you ever wondered what would prevent a malicious insider from obtaining privileged credentials during an IT audit? It would be a simple matter of just setting up a Linux or Windows box with a sniffer or backdoor to grab the domain or root password during the audit. Tenable has written Nessus 3 and Nessus 4 to take advantage of underlying protection mechanisms in SSH and Windows authentication protocols to limit your exposure to this type of attack.

This blog entry describes how you can securely audit your Unix and Windows hosts to limit exposing these credentials to an insider and also how to use Metasploit to test any vulnerability scanner to see if it is vulnerable to this type of attack.

Scanning with Credentials

Credentials such as username and password provide valuable information and resources to an attacker. Collecting this information on the local network can yield escalation of privileges and access to other systems where the username/password pair is being re-used. Unfortunately, we need to use credentials to login in to systems and applications and to perform vulnerability scans that require local access to the system for patch checking and configuration auditing. Credentialed vulnerability scans can be of great assistance in identifying security issues in your environment, as long as a malicious insider doesn’t take advantage of this process. For example, you may have 100 Linux and Windows systems on the network with an account that allows the Nessus vulnerability scanner to authenticate to perform local scanning. This account needs to exist on all systems, but does not typically require root or Administrator/SYSTEM privileges. An attacker would need to have already compromised a system containing these credentials or be a malicious insider who has network access. The attacker simply waits for the Nessus vulnerability scanner to login and steals the credentials, giving them access to every host on the network where these credentials are valid. The following sections describe how the attack would work on the different platforms and offer defensive recommendations.

Linux/UNIX Systems Using SSH

One attack strategy is to install a trojan SSH server. This process would listen on port 22 and interact with the connecting system just as an SSH server would, except the username/password pair would be saved before being passed to another SSH process to complete the login. This is actually a common practice by attackers who compromise a system and want to collect additional usernames and passwords without going through the process of cracking each password hash. To combat this threat, be certain to configure SSH to use public key authentication which removes the password from the login process and makes it extremely difficult to hijack. In addition, consider the scenario where you have configured Nessus to scan a class C network and an attacker has connected a new system within that network range. They can setup a trojan SSH server as described above and collect the Nessus credentials. Nessus can be configured to only scan hosts in the known_hosts file on the Nessus server. In the scan policy this can be set in the "Credentials" tab under "SSH Settings":

The field labeled "SSH known_hosts file" allows you specify this file and restrict Nessus to only scanning the hosts contained within.

Windows Systems

Windows systems treat authentication differently depending on the version of Windows that is running. Changing these settings could break backward compatibility with older versions of the operating system. However, a malicious insider could set up a system that would force the Nessus server (or any other vulnerability scanner) to send credentials in clear-text, or other formats that are easily cracked using readily-available tools. A great article by HD Moore titled, "MS08-068: Metasploit and SMB Relay" covers some of the techniques implemented in this attack (including a module for Metasploit that performs these attacks).

Nessus contains several options for authenticating to Windows:

The setting to “Never send SMB credentials in clear text" is checked by default and prevents applications from tricking Nessus into transmitting credentials in clear-text. Nessus can also be configured to exclusively use NTLMv2 authentication, which uses a stronger key exchange mechanism that is more difficult to successfully attack. An additional defense that you can enable in your network is to ensure that SMB packet signing is enabled. This forces systems who want to talk SMB to each other to first negotiate packet signing before they will talk SMB.

Conclusion

Nessus contains several features that allow you to configure it to use the most secure methods available to login to the remote systems. There is no further risk allowing Nessus to perform authenticated scans than there would be if you allow your management system to patch your systems. It is also important to monitor your systems to ensure that credentials have not been compromised. For example, using Tenable's Security Center you can monitor when an account was used to successfully login to a system, then correlate that event with a vulnerability scan. If the date and time stamps do not match, your credentials may have been compromised. Tenable’s Passive Vulnerability Scanner can also help monitor for malicious insider attacks by identifying new hosts that appear on the network that could indicate malicious insider activity.

Resources

• LM/NTLM Hash Support for SMB Credentials
• OpenSSH Public Key Authentication