Confusion between Vulnerability Assessment and Penetration Testing

There has always been a fair amount of confusion between Penetration Testing and Vulnerability Assessments. In India however the problem takes a new turn with vendors confusing between the two.

I was recently in a meeting with a potential customer and we were discussing their current vendors and what they provide in their Penetration Test. As I glanced over the reports I noticed that the service provided was purely a Vulnerability Assessment masquerading as a Penetration Test. The particular vendor in question had only conducted a port scan followed by listing possible vulnerabilities that exist for the service and operating system versions identified.

In my opinion I would barely even classify this as a Vulnerability Assessment. A Vulnerability Assessment Engagement from Security Brigade goes through the following phases:

• Pre-Assessment Analysis
• Information Gathering
• Port Scanning
• Enumeration
• Threat Profiling & Risk Identification
• Network Vulnerability Assessment
• Application Vulnerability Assessment
• Engagement Analysis
• Mitigation Strategies
• Report Generation
• Support

A Penetration Testing Service however goes many steps further with the following phases:

• Pre-Assessment Analysis
• Information Gathering
• Port Scanning
• Enumeration
• Social Engineering
• Threat Profiling & Risk Identification
• Network Vulnerability Assessment
• Application Vulnerability Assessment
• Exploit Research & Development
• Exploitation
• Privilege Escalation
• Retaining Access
• Network Propagation
• Engagement Analysis
• Mitigation Strategies
• Report Generation
• Support

The difference can be clearly seen in the fact that a Penetration Testing goes further after analyzing the vulnerabilities into exploitation, privilege escalation, retaining access, network prorogation etc. Simply put a Vulnerability Assessment provides an overview of the flaws that exist on the system while a Penetration Testing goes on to provide an impact analysis of the flaws identified, the possible impact of the flaw on the underlying network, operating system, database etc.

I believe it is fairly important for Clients and especially Vendors in India to understand the difference and represent the two services in their traditionally accepted form. I believe this is a crucial step for Indian IT Security to take a step forward and providing real security to customers.

One of the white papers that I am currently working on specifically looks at the difference between Vulnerability Assessments and Penetration Tests with a focus on:

• What is covered by each service
• What factors should be considered while determining their requirements
  
• How a Client can determine their requirements
• Comparison of the benefits and draw-backs of both the services
• etc.

The paper should be released sometime this month and can be found on Security Brigade's website.

Dan Kaminsky's DNS Cache Poisoning Vulnerability Explained

There has been a lot of talk recently about Dan Kaminsky's DNS Cache Poisoning Vulnerability. Simply put there are an extremely large amount of publicly accessible DNS servers that can fairly easily be tricked into storing and serving up malicious DNS Information. The impact of this malicious DNS Information is that users can be unknowingly tricked into accessing malicious sites and possibly compromise sensitive information such as: username, passwords etc.

DNS Cache Poisoning attacks have been around for years now. However this vulnerability is far more exploitable and dangerous than its predecessors. Luckily for the world and all of its administrators, Dan Kaminsky of DoxPara Research raised awareness about the criticality of this vulnerability and coordinated a massive effort with vendors to issue patches. He gave vendors time to make patches and the public time to apply them before releasing all the details.

In regards to the exploitability of this vulnerability, there are a few challenges that need to be overcome by the attackers.

• Knowing when a DNS Server will issue a particular DNS Lookup: If the server doesn't already have the name cached, you can try to spoof the response right then, but you only get one shot.
  
• Guessing the DNS query's transaction ID: it should be possible to blast the server with 65,536 spoofed responses (one for each transaction ID). The fact that this ID is only 16 bit is generally accepted as being too weak.
  
• Creating a proper spoofed packet with poisoned information in it: Vulnerable DNS servers reuse the same source port for every outgoing request, which makes crafting the spoofed return UDP packets trivial (DNS servers that already randomized the source port are generally seen as being practically immune to this exploit, since attackers would have to guess nearly 2^32 combinations instead of only 65,536).
  
• Getting the spoofed response to the DNS Server before the real response: Latency may work against an attacker. But an attacker attacking his own ISP might not face either of these problems.
  

Overall, an attacker would need an insane amount of patience and luck to pull this off.

The steps an attacker would take to exploit this vulnerability would be something like:

1. Attacker asks Victim DNS Server: Who is gmail.google.com?
2. Victim DNS server asks the authority for google.com, Who is gmail.google.com?
3. Attacker blasts Victim with spoofed responses, each containing a different transaction ID. The packet contains a response with an IP for gmail.google.com, as well as an additional RR stating www.google.com is an IP address of the Attacker's choosing.
4. (Exploit) If a valid, spoofed response is received before the real response comes back, the Victim updates its cache with both the requested info as well as the poisonous IP information contained in the RR. The subsequent response from the authority for google.com is discarded.

This is repeated as necessary with new sub-domain requests, until one of the spoofed responses takes. When it takes, the attacker has circumvented the TTL problem and outsmarted the same-domain defense. Reports are this can happen in less than 10 minutes. i.e. 10 minutes to replace cnn.com, or youtube.com, or any other popular site with a site of your own choosing. This means for a certain period of time and for the users of your victim DNS Server you control where these popular websites point. You will be able to deface the website, show them information of your choice, or try to phish for their personal information.

An exploit is currently available from the Computer Academic Underground. It provides a good technical summary on the vulnerability and how exploitation works.

This exploit attacks a fairly ubiquitous flaw in DNS implementations which Dan Kaminsky found and disclosed ~Jul 2008. It caches a single malicious host entry into the target nameserver by sending random sub-domain queries to the target DNS server coupled with spoofed replies to those queries from the authoritative nameservers for the domain which contain a malicious host entry for the hostname to be poisoned in the authority and additional records sections. Eventually, a guessed ID will match and the spoofed packet will get accepted, and due to the additional hostname entry being within constraints of the original request the malicious host entry will get cached.

So what's the fix? There really is no fix, short of using DNSSEC, or moving to some other cryptographic method of trust. Using TCP instead of UDP has come up (this would add the additional, now nearly impossible challenge of guessing sequence numbers), but was shot down as being too resource intensive. So the accepted workaround is what was already mentioned above: DNS servers should randomize their source ports. Then attackers would have a much, much harder time spoofing the return packets.

For those of us out of India, I don't see much hope in waiting for your respective ISPs to patch. In the meanwhile I recommend switching to the DNS Servers from OpenDNS as a precautionary measure.