Tenable's Research group recently added the ability to perform WMI (Windows Management Instrumentation)  queries to Windows servers and desktops as part of a Nessus configuration audit. These new features allow for rapid and in-depth auditing of a wide variety of configuration settings that are only available through WMI. This blog entry describes how the new API works, and includes several examples.

Most enterprises are required  to run some sort of Anti-virus (AV) software on all or a portion of their desktops and servers and report on the status of the deployment. This blog entry discusses some of the limits of self-reporting within an anti-virus application and how Nessus can help you detect systems that are not AV compliant.

Self Reporting with Anti-Virus Software

Enterprise versions of most anti-virus software typically include a central management console that enables the organization  to track which systems have AV installed, the software version and the status of the AV signatures. What these products cannot do is tell administrators about the systems that it doesn't know about - those without AV installed at all.

From vendor to vendor, there is variation of the detection mechanism and how this information is reported. The central management console of each vendor may use different mechanisms to report if  the anti-virus agent software is installed, if it is running and when the last time it had a signature update. Not displaying all of this information can provide a false sense of security that a host is indeed protected by some form of AV. In addition, this type of technology only reports on AV agents from that specific vendor, ignoring mixed vendor environments.

Lastly, most anti-virus products can only report on systems they are installed on and not other nodes or systems in the network, which are not in the management system. Some agents do keep a list of Ethernet addresses that are unique, and then attempt to reconcile this list at the management console. This may help identify some nodes without anti-virus software, but it does not find all devices that have been filtered, are behind screening devices or that simply are not communicated with.

Performing an Audit with Nessus

Previous blog posts have discussed how a Nessus credentialed scan can be used to identify if common anti-virus software is installed, if it is running AND if their signatures are up to date. This blog was recently updated to reflect support for testing Sophos and Windows Live OneCare.

Clearly, there are several advantages to this approach.

• No need for an agent - Many  organizations wish to avoid  deploying more agents to their desktops and servers. Agent based solutions that can be used to audit installed software increase the complexity and potential attack space of a network. It also requires that third party visitors to the organization install an agent to ensure AV compliance. A Nessus credentialed audit does not require an agent to be installed on the target.
• Support for a heterogeneous environment Since Nessus is not dependent on a specific vendor's anti-virus technology, it can be used to identify deployed solutions in a multi-vendor environment, common to larger enterprises.
• Verification of signature updates - Nessus independently reports any discrepancies in signature updates, or if the anti-virus solution is installed, but not running.
• Validation of AV software - During the credentialed audit, Nessus will also test for the presence of anti-virus software that is vulnerable. There has been some discussion of this in recent blog postings about the increasing trend towards vulnerabilities contributed from anti-virus solutions. Nessus has checks for vulnerabilities in many host security agents including Symantec, Trend Micro, CA eTrust, Clam AV, NOD 32, Kaspersky, McAfee, F-PROT and Sophos.

Your organization is also likely deploying more than one technology (other than AV) to defeat the threat of virus outbreaks. Examples include system hardening, the use of desktop firewalls and having traffic flow through proxy servers. ProfessionalFeed users can make use of Nessus's ability to audit system configurations to ensure the following:

• The corporate authorized web browser is enabled and configured correctly
• Proxy settings are in effect to require web browsing to go through other forms of inspection
• The system itself has been hardened to limit the impact of a successful virus compromise
• The system is running the corporate standard(s) for Anti-virus software

For More Information

The following Tenable blog entries discuss virus discovery, anti-virus auditing and software discovery:

• Enterprise Software Discovery with Nessus
• Auditing Anti-Virus Products with Nessus
• Detecting Compromised Windows Hosts
• Boss, I think half of our FTP Servers are fake!

The current DNS cache poisoning issue is a great example of a vulnerability that must be tested with both patch auditing as well as network scanning. Nessus is ideally suited to perform both types of   audits. This blog entry discusses the advantages of using an auditing tool like Nessus as compared to pure patch auditing or network scanning.

NAT and DNS Cache Poisoning

A key part of exploiting this vulnerability is the ability to predict the source ports of replies from a DNS server you wish to inject malicious data to. Consider the following sequence of source ports for queries to a DNS server that randomized its responses:

request 1 - 51256
request 2 - 56277
request 3 - 54798
request 4 - 58272
...

Now consider the same set of queries performed against the same server, but this time the DNS server connectivity is going through Network Address Translation (NAT) (e.g. a firewall) that is port forwarding port 53:

request 1 - 46093
request 2 - 46094
request 3 - 46095
request 4 - 46098
request 5 - 46099
...

Clearly the responses are not randomized and the issue occurs due to the network address translation process not using randomization to translate queries across this interface.

Performing a patch audit of the DNS server would show that it was indeed patched and in this situation, would give a false sense of security. Of course, performing a network scan on the inside of the network would also show a DNS server with randomized source ports and give a similar false sense of security. However, performing an audit outside of the NAT device would show that the ports were not randomized. Clearly, a network scan in this case was a convenient way to discover the security issue where other methods would fail.

Patch Auditing vs. Network Scanning

If an organization only does patch auditing or they only do network scanning, they are missing network nodes and information that could be vital to finding highly vulnerable systems or non-compliant systems.

We have a white paper that can be downloaded (without requiring registration) that details the strengths and weaknesses of each technique and also includes a discussion of continuous network monitoring as well. The paper is titled "Blended Security Assessments".

I frequently ask our customers how they perform such monitoring and remind them of the value of extending their coverage. For organizations that just perform un-credentialed network scans, I encourage them to obtain credentials for their target systems and start to perform patch audits. Similarly, for organizations that don't have a network scanning solution and are entirely relying on some form of patch management or software distribution system, a network scan will often discover many other network devices and systems which are not under control of the patch management system.

Exposing More Vulnerabilities with Network Scanning

If a NAT device can directly impact a major DNS vulnerability, what other types of interaction from the network can result in more exposure for an organization? This is not an exhaustive list, but consider the following "network" or infrastructure devices that can have a major impact on your security posture:

• Unknown Firewall Rule Changes - From an internal perspective, you may feel comfortable that your systems are patched, thinking that insecure services like SNMP, RPC, TFTP, .etc are blocked by your network firewall. If this changes though, you may end up exposing vulnerable services to the Internet. External network scans help to look to see what is really exposed.
• Load Balancer Rule Changes - I've encountered many hosting organizations that have sophisticated fail-over, load-balanced and out-of-band managed web and content servers. When these systems have unauthorized changes or partial outages, they can expose management ports that rely on the firewall shielding them from public to protect them essentially.
• Virtual System Managers - More and more organizations are relying on VMWare and Xen. Sometimes these  virtual systems are simply migrated from one physical server to another. This can have unanticipated exposure if the previous system was firewalled or secured in some manor. Virtual servers also have their own NAT technology which can also make it difficult to identify their exposure without performing a network scan.
• IPv6 - Performing an IPv6 scan with Nessus can identify which systems in your network run this protocol. Those types of systems may be able to communicate with each other and bypass more traditional IPv4 filtering and access control techniques.

For More Information

We've visited the topic of scanning and patch auditing several times in this blog. Below are relevant blog entries that may be of interest:

• Testing the Effectiveness of your Patch Management System
• Knowing When to Patch (a.k.a. - Don't let your scanner tell you when to patch)
• Reporting Vulnerabilities in an IT Managed Environment
• Finding Vulnerabilities Older than 30 Days
• Security Metrics - Differentiating new Vulnerabilities from Change
• Security Metrics - How often should we scan?

Nessus plugin #33523 "Network Camera Detection" will alert if it encounters a web page that belongs to a WebCam.

Typically, these web pages are not password protected and on ports other than port 80. If it is not password protected and not behind a firewall, it may be allowing unauthorized users from your organization, or even users from the Internet to view and/or listen to activity and conversations in the viewing area of the cameras.

Below is an example screen shot of this plugin being active during a Nessus scan.

The plugin does not require credentials, but is dependent on having its scan target the web server port if it is running on something non-standard, such as 8000.

The plugin is currently available to Direct Feed users.

Previously, I've blogged about Digital Bond's effort (project Bandolier) to produce Nessus audit polices for a wide variety of control system devices and applications. Digital Bond recently published alpha releases of audit files for Siemens Spectrum Power and Televent OASyS DNA systems. These audit polices are available to Digital Bond Site Subscription users and work with the Nessus Direct Feed or ProfessionalFeeds. Below is a screen shot of example results against an audit of an OASyS DNA system:

For more information on project Bandolier and other control system security information, please visit Digital Bond's web site and their SCADApedia.

Tenable recently announced two programs to provide access to the ProfessionalFeed for charitable organizations and classrooms that offer information security training. Full details of the programs are listed below:

• Tenable Information Security Training Organization Subscription Programs
• Tenable Charitable Organization ProfessionalFeed Program

Charities in the United States must be a 501(c)(3) organization to qualify. Charity organizations not based in the United States must provide equivalent documentation to substantiate their standing as a charitable organization.

Academic and commercial classrooms should also be aware that the HomeFeed license for Nessus will include language to permit distribution of Nessus within a classroom environment. If you are looking to teach the basics of port scanning, vulnerability scanning and patch auditing, the HomeFeed for Nessus will allow you to accomplish this.

If you want to instruct in more advanced Nessus concepts such as auditing system configurations, searching for sensitive content and other features specific to the ProfessionalFeed, training organizations can apply to receive one subscription for their class. The plugins and activation codes can not be distributed to the students, and they should instead perform any labs, testing or exercises by interacting with the Nessus scanner directly.

If you have interest in these programs, please consider the above links which have more detailed information. Further questions should be directed to either infosectrainingPF@tenablesecurity.com for Nessus use in classrooms or charitablePF@tenablesecurity.com for charitable organizations. 

I will be participating today in a White Hat World "Thought Leadership Roundtable Webcast" today at 2:00 PM EST on the topic of Phishing. Other panel members include representatives from Secure Computing, SonicWall, and Missing Link Security Services. To register for the event or watch the recorded session after it occurs, please use the following link:

• White Hat World Webcasts

The event is free, but requires registration. Tenable will be participating in several other White Hat World webcasts in the near future.

Recently, CERT issued vulnerability note VU#800113 which describes a variety of issues with multiple DNS commercial and open source tools.

The vulnerability pertains to an attacker being able to perform a cache poisoning attack. This could result in an attacker being able to re-direct email, web and other types of traffic to hosts under their control. This has many implications for identity theft, malware propagation, credit card theft and denial of service.

Tenable's research group has produced several Nessus plugins which test for this vulnerability.

• The "Remote DNS Resolver Uses Non-Random Ports" plugin, ID #33447 and currently available to Direct Feed users, performs a variety of queries to a DNS server to determine if the source ports used in these transactions is sufficiently randomized. You do not need credentials to perform this test. It is purely based on DNS queries sent to the DNS server.
• Plugin #33441 is a credentialed check for Microsoft servers that tests for the presence of the MS08-037 patch which fixes this issue.
• Plugin #33451 and #33450 is a credentialed check for Debian DNS servers.
• Plugin #33462 is a credentialed check for Red Hat DNS servers.
• Plugin #33464 is a credentialed check for Ubuntu DNS servers.
• Plugin #33448 is a credentialed check for CentOS DNS servers. 

As more patches for this advisory become available in other operating systems, Tenable will add checks for those systems as well.

Dan Kaminsky of IOActive, Paul Vixie of the Internet Systems Consortium (ISC) and Danial J. Bernstein have all been credited with finding this security issues and raising awareness to ISPs, vendors and network administrators.

If your organization is modifying their DNS servers because of this vulnerability, we also suggest that you test to see if DNS recursion is enabled and if it is not needed, disable it as well.

Previously, Tenable announced that full su/sudo support for UNIX host-based checks was now supported by Nessus 3.2 but that UNIX configuration audits did not have access to this feature. With the latest release of the unix_compliance_check.nbin file (version 1.5.8), full support for su and sudo while performing UNIX compliance audits is now supported. This blog entry discusses this and several other new features.

Tenable's Research group has released two new audit polices for Nessus and Security Center users which audit the AIX operating system.