Default vs. Easily Guessable Credentials
There are several Nessus plugins that test various common username and password combinations. I tend to put these into three different categories:
- Default Credentials - Known usernames and/or passwords associated with a specific device or application. (E.g. Linksys WRT54G username "admin" password "admin")
- Common Credentials - Commonly used username and/or passwords that are valid regardless of the application or device type (e.g. username "root" / password "toor")
- Brute Force Guessing - User supplied list of accounts and passwords fed to Nessus via Hydra
There are 70 plugins beginning with "account_*" that try to login via telnet and/or SSH. These plugins test for generic common credentials or credentials that are known to be associated with a particular device or application.
If you want to specifically target credentials you can use the Nessus GUI to create a custom policy to perform a very specific scan. This is a great policy to schedule on a weekly or daily basis as it is low impact (essentially just uses the login functionality of the targets) and will find critical vulnerabilities.
I created a new policy and called it "Default & Weak Credential Check". I enabled the SYN port scanner, saved a knowledge base (for later use with command line tools if desired). I also increased "Max Checks Per Host" to 10 (from the default value of 5) as I am confident that the plugins I am executing will have a low impact on the targets:
Click for larger image
Next, I configured the policies. I used the “Filter” feature in the policy setup and searched for both "account" and "default". I went through each family in each of the search results and manually enabled the plugins that tested for either weak or known default username/password combinations. Don't worry, I won't make everyone go through the same process and I have made this policy available for download.
Click for larger image
In the "Global variable settings" page there are two options that must be enabled to ensure all of the enabled plugins run against the targets. The "Enable CGI Scanning" option allows any plugin in the “CGI Abuses” and “CGI abuses:XSS” families to execute. "Thorough test (slow)" must also be enabled as some of the credential testing plugins can add time to the scan (how much depends on the account policies applied to the target) and/or lockout accounts.
Several of the plugins I enabled were targeted at printers and Novell NetWare hosts, so I've specifically told Nessus to scan these devices. This is not the default, and may cause negative impact on the targeted devices. However, I'm confident my printers will not blow up or spew reams of paper endlessly as a result of the scan.
Once the scan finishes you will get a report that can be filtered for “High” vulnerabilities to reveal a nice list of devices that have weak or default credentials:
Click for larger image
Note: Not all findings from this scan are listed as “High” severity; some are listed as “Medium” severity , so you may want to generate a report for medium level findings as well, which seems to be mostly SNMP community string default values.
Tip: Using the Command Line
Another great way to use these plugins is to execute them via the command line. You can use the "nasl" command to execute a specific set of plugins as follows:
We use the "nasl" binary with the "-k" flag, which allows you to specify a knowledge base file to use for the settings. The "-t" flag takes one parameter, the IP address or subnet that is the target. The final parameter is the NASL script or list of NASL scripts that are to be executed. I use the "*" wilcard character to execute all scripts that begin with "account_". Each plugin that was successful will print out with the "Success" message you see above.
Scanning for default and weak credentials yields a high rate of return to identify risk. The conditions found on each of the hosts potentially allow anyone with access to the device the ability to configure it how they like. Several of the targets include devices such as routers or wireless access points, which an attacker will leverage to compromise multiple hosts on the network or distribute malicious code. This is also a great example of a scan that can be run on a regular basis, taking advantage of the new scheduling feature within Nessus.
You can download the policy used in this example from the link below: