Archive for the Uncategorized Category

Nmap’s New Math? 9 = 8 but does 3,674 = 65,536?

Posted in Penetration Testing, Uncategorized, Vulnerability Assessment with tags , , , , on November 13, 2008 by Tim

Fyodor’s inclusion of the results from the Top Ports Project into the latest version (4.76) of Nmap is a welcome addition to information security professionals who need to perform port scans of large networks in short periods of time. **cough*** Consulting Firms ***cough**

However, the claim that using the “–top-ports” switch to scan only the top 3,674 TCP ports is 100% effective opens the door for yet another false sense of security. I wholeheartedly believe that it was NOT Fyodor’s intention for organizations to rely solely on port scans using this configuration to determine which ports are open. However, it does not require a leap of faith to believe that some less “offensive minded” security professionals will now use this configuration to get a “complete picture” of their networks.

Why is this a problem? If you are reading this blog, you probably already know where I am going with this. It doesn’t require another leap of faith to believe that an attacker or offensive minded individual would examine the “Top Ports” list and code their malware or configure their tools to operate on ports that are not included in the list. The result? Those who subscribe to this complete picture mentality will not discover the open ports.

So how do we effectively leverage the hard work of the Top Ports Project? I’m not entirely sure yet. Perhaps we use the “–top-ports” switch to perform differential scans and continue to use “-p-” to perform baseline scans? Or maybe we use the “–top-ports” switch to perform discovery scans and “-p-” to perform enumeration?

I do know that the information that has been provided as a result of the Top Ports Project is valuable. How do you think we can effectively use this information?

Advertisements

Remediating Common PCI SSL Vulnerabilities with a Simple Windows Registry File

Posted in PCI, Uncategorized with tags , , , , , on November 12, 2008 by Tim

Recently I was working with a client who was struggling to remediate two vulnerabilities identified by their quarterly perimeter PCI scans. Specifically, they needed to remediate the following vulnerabilities:

  • SSLv2 Enabled
  • Weak SSL Encryption Ciphers Enabled

With these vulnerabilities being so common amongst those bound to the PCI DSS, I would have hoped that better remediation information existed beyond Microsoft’s overcomplicated Knowledgebase Article,

In response to this lack of quality remediation information, I created the following Windows Registry file that aims to simplify the remediation of both vulnerabilities. This file has been tested on IIS 6.0 (Windows 2003) and disables the following weak ciphers, hashing functions, and protocols associated with SSL:

  • Weak Ciphers – DES 56, NULL, RC2 40/128, and RC4 40/56/128
  • Weak Hash Functions – MD5
  • Weak Protocols – PCT 1.0, and SSL 2.0

You can download the registry file from our website, here.

The standard “Backup your registry first” and “Test on non-production systems first” rules apply. Happy remediating! (and more importantly…SECURING!!!)