"But I patched our DNS servers ..."

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?