Nessus has several new features for auditing systems via Secure Shell and coincidentally, there was a major vulnerability announced this week regarding OpenSSH servers whose public keys are trivially guessable. This blog entry discusses these new features and SSH audits.
Full "su" and "sudo" Support
All Nessus users now have the ability to perform their credentialed patch and vulnerability auditing with the support of "su" or "sudo". Previously, Nessus users were limited to simply specifying a username for the Unix audit to occur with that had limited support for sudo.
Available as a new scan preference option, Nessus users can now specify credentials to log into a remote system, and then additionally invoke "su" or "sudo" with a separate password.
In addition, if an ssh known_hosts file is available and provided as part of the scan policy, Nessus will only attempt to log into hosts in this file. This can ensure that the same username and password you are using to audit your known SSH servers isn't used to attempt a login to a system that may not be under your control.
Below is a screenshot of the Nessus Client SSH credentials page.
When auditing UNIX systems via su or sudo, please keep the following items in mind:
- If your UNIX system has been tightened down to limit what sort of commands can be executed or files accessed by remote users, this may affect your audit. You should compare non-root audits with a root audit if you suspect the audit is being limited due to excessive security.
- When scanning with known_hosts, the Nessus scan still needs to specify a host to be scanned as well. For example, if you scanned a class C but uploaded a known_hosts file that only contained 20 individual hosts within that class C, Nessus would just scan those hosts in the file.
- Currently, su and sudo support is not available to perform UNIX configuration audits, but this will be available shortly.
Testing for Weak SSH Keys in Linux Distributions
For Debian and Ubuntu Linux distributions, any SSH, SSL or other cryptographic keys generated through OpenSSL since 2006 were not sufficiently randomized. This resulted in all Debian and Ubuntu systems using one of 32768 unique keys. This means that any type of SSH or SSL security which relied on encryption keys is now easily guessable by a remote attacker.
Although most of the coverage of this issue has been dedicated to SSH servers which have been secured with public/private keys, this issue also impacts SSL encrypted web servers, users of the the OpenVPN client and all applications using encryption that generated keys with OpenSSL. Links to the original vendor vulnerabilties are below:
Nessus plugin #32314 "Debian OpenSSH/OpenSSL Package Random Number Generator Weakness", audits Debian and Ubuntu systems without credentials (you can scan without a password) to find systems that have an easily guessable key.
Although the focus of this vulnerability has been on SSH, all cryptographic material on these systems maybe suspect including SSL. This implies secure web servers running on Debian or Ubuntu may also be at risk. Nessus plugin #32321, "Debian OpenSSH/OpenSSL Package Random Number Generator Weakness (SSL check)", performs this check on SSL web servers without requiring credentials.
These two previous new plugins are server focused. To test for client side weak encryption with this same bug, Nessus plugin #32320, "Remote host has weak Debian OpenSSH Keys in ~/.ssh/authorized_keys" is now available as well. This plugin requires credentials (and you can use su/sudo as well now), and analyzes every user's authorized_keys file to ensure that it does not contain any weak SSH key.