Facebook Google Plus Twitter LinkedIn YouTube RSS Menu Search Resource - BlogResource - WebinarResource - ReportResource - Eventicons_066 icons_067icons_068icons_069icons_070

Scanning Vulnerable Linux Distributions With Nessus

A challenge for many penetration testers is to find a vulnerable system they can use to test their penetration testing skills and tools before they use them against paying clients. I recently found a distribution called "Hackerdemia", a Slax-based Linux distribution containing several vulnerabilities, including un-patched software, mis-configured services, default passwords and a few other surprises. My goal was to bring up the distribution in a virtual machine, assign it an IP address using host-only mode and scan it using Nessus.

This will provide:

  • A standard platform to test that my Nessus installation is functioning properly

  • A place to test different Nessus plug-ins and configurations

  • An environment to experiment with and develop Nessus .audit files
  • Hackerdemia has proven to be a great platform for this purpose, and provides some very interesting results:

    Open Port Re-Check

    One plug-in that I always pay close attention to is Plug-in ID 10919 "Open Port Re-check", which flags ports that were open, but then stopped responding while being tested by Nessus. This is important information because if we crashed a service and caused a DoS condition the service may not have been fully tested by Nessus. In addition, I have found services crashing during a Nessus scan to contain vulnerabilities (some known, some not known prior to the scan), that were the root cause of the crashing. The following is a list of ports that were open, but closed during testing:

    Nessus-OpenPortRecheck.png

    Wow, quite the list! In my experience there is little chance that all of these services crashed. A more likely explanation is that the machine crashed. In my case, the DHCP client on the Hackerdemia distribution was pulling two different IP addresses and then flipping in between them. Lesson learned: Always use a static IP address when setting up test machines for this purpose.

    Fun with ident

    If ident is running on the host, you can specify open ports and the Nessus plugin will tell you what uid the process is running as.Knowing the privileges with which the process runs allows an attacker to also know the privileges that arbitrary commands or code would be executed with. This is a really neat feature of Nessus and shows how the scanner will make use of any available service/information to benefit other tests. You can run this from the command line (if you know TCP port 113 is open and running ident):

    # /Library/Nessus/run/bin/nessuscmd -V -p21 -i 14674 192.168.1.241
    Starting nessuscmd 3.2.1
    Scanning '192.168.1.241'...
    

    + Results found on 192.168.1.241 :
    - Port ftp (21/tcp) is open
    [i] Plugin ID 14674
    | identd reveals that this service is running as user/uid 0

    The above command will run nessuscmd with the "-V" flag that shows the full output of the plugin, the "-p21" flag to point it at TCP port 21, the "-i 14674" that specifies the plugin to run, in this case the ident scan plugin, and then specifies the target IP address. Our results reveal that the service, likely FTP, is running as uid 0 (or root). Nessus provided this information for each service that was enumerated during the scan.

    Service Alerts Are Important

    When I first started using Nessus, I would tend to only pay attention to alerts marked as High or Critical (the ones that show up as red in the Nessus client). However, as we have seen with the examples above, there is great information in all Nessus alerts. For example, an alert was generated for TCP port 1337:

    Nessus-1337backdoor.png

    The first thing you may notice is that the port is somewhat suspicious. Why would a host be listening on port 1337? (i.e., "leet" in "leetspeak"). The description provided by Nessus plug-in 22964 ("Service Detection") indicates that it is a possible shell server or backdoor running on this port. We can test this theory by connecting to the port with netcat and issuing shell commands:

    $ nc 192.168.1.21 1337
    id
    uid=0(root) gid=0(root)
    uname -a
    Linux slax 2.6.16 #95 Wed May 17 10:16:21 GMT 2006 i686 pentium3 i386 GNU/Linux

    The above represents a netcat listener left on the system by running nc -l -p 1337 -e /bin/sh. While Nessus does a fantastic job of finding known software vulnerabilities, it can also identify services that provide illicit access to the system. I have been on more than one assessment where a machine was found to be compromised before our testing started, and this is a good example of the kind of thing you may find listening and left behind by an attacker. Another interesting port is 31337/TCP, which in this case represents a standard netcat listener (nc -l -p 31337). The interesting thing about these listeners is that when Nessus tested them, the results showed up on the console:

    Hackerdemia-Console.png

    Scanning with Credentials

    Scanning the system with credentials and taking advantage of Nessus .audit files is extremely useful, and can test your system in many ways that a remote scan cannot. It also allows you to test the system against some of the industry standard benchmarks. The CIS benchmarks are very comprehensive and produce a template for Apache servers. The audit file is available to Nessus Professional Feed customers. In my test example I wanted to see how poorly my vulnerable system would fair against the CIS benchmarks. I added my credentials:

    Nessus-SSHcredentials.png

    In the above screenshot you can see that I am using the username "root" and only a 4 character password. This is obviously not recommended for production systems, but for the purposes of our testing we can use the root account with the default password (in this case it happens to be "toor"). I had to modify the .audit file, per the instructions:

    "If you have customized your configuration, or, are unable to create your custom Apache configuration in this location, use a global replace utility to modify "/usr/local/apache2/" to your actual Apache location."

    Hackerdemia puts the Apache configuration file in "/etc/apache/", so you will need to do the global search and replace as described above. Next, you can choose the audit file in the Nessus configuration and initiate the scan (For more information see Ron's previous post, "Auditing PHP Settings to OWASP Recommendations with Nessus"). The following shows some of the alerts that were generated:

    Nessus-CISApachePolicy.png

    Looks like we need to upgrade Apache and install Mod_Security, but wouldn't that spoil all our fun if we started patching the system?

    Conclusion

    Hackerdemia provides a great environment to test out Nessus features. It works well as a test platform for penetration testers who want to get a feel for how Nessus runs, experiment with different settings and research alerts that may prove to be interesting. Those who are using Nessus in an enterprise environment as part of a vulnerability management program will find the extra practice with Nessus extremely useful. This is especially true if you are scanning with credentials and using Nessus .audit files. Hackerdemia is a great resource to test audit files or even use as a platform to create and test new locally developed checks.

    Additional Resources

  • http://www.damnvulnerablelinux.org/ - A Linux distribution which contains vulnerable software, primarily local exploits and vulnerable web applications.
  • How to audit an Internet Facing Server with Nessus - Contains information about performing Nessus scans, particularly more information about the open port re-checking.
  • Automated audit policy creation for UNIX Nessus compliance checks - More information about UNIX compliance checking