Lots of changes in this major release:

• Performance improvements for scanning.
• Improvements to the Zenmap GUI.
• New tool Ncat, “a a much-improved reimplementation of the venerable Netcat.”
• The Ndiff scan comparison tool.
• Improved and new scripts for the NSE scripting engine.
• More documentation: a users’ guide and Nmap Network Scanning book.

No related posts.

openssl s_client -connect www.example.com:443

The above lets you connect via SSL to a web server and manually type HTTP commands just like you can with non-SSL web servers using plain old netcat and telnet.

The OpenSSL command-line utility is a swiss army knife for encryption protocols. You can use it for far more than just generating keys and connecting to SSL servers. But there are also many other command-line tools that are incredibly useful for SSL testing and discovery purposes:

• Gnu wget can fetch HTTPS URLs, if it has been compiled with SSL support. To view the HTTP response headers, try wget -S
• Lynx and elinks text-based web browsers (again, assume they have been compiled with SSL support)
• Cadaver for SSL-enabled WebDAV servers
• stunnel for tunnelling any traffic through SSL
• ssldump for sniffing and decrypting SSL traffic

SSL tools like these are valuable for assessing more than just web servers. About a year ago we had a contract to do a security assessment of Cisco Security Agent (a host intrusion prevention tool originally developed by "Okena"). After a bit of network sniffing and poking around the server directories, it turned out that CSA client and server communicate using HTTP encrypted with SSL over a non-standard port (a huge number of commercial products use simple HTTP and SSL as their client-server protocol. They just run it on a port other than 443 to disguise the fact).

To evaluate how robust the client and server were to attack, we used ssldump to decrypt and the raw HTTP traffic (this was possible only because the CSA server held the SSL host key).

Once we could capture the raw HTTP and understood how requests were formatted, we used openssl, stunnel and other tools to capture and replay communications between server and client, spoof traffic, impersonate endpoints, and "fuzz" the communications looking for overflows and other obvious vulnerabilities. The product withstood attack fairly well.

Were it not for the availability of these command-line tools, especially ssldump, performing the vulnerability assessment would been much more limited and involved coding a lot of custom SSL clients using something like Perl and the LWP library.

It always bugs me when vendors use the word "secure" when they really mean "encrypted". Encryption is only one tool that can be used in security, and usually it’s not the encryption that’s the weak point. In other products we’ve evaluated, a little sniffing and investigation revealed that while SSL was the method of encryption, the key size was 48 bits or lower, making brute force decryption feasible. Worse, some products ignore the authentication features of the SSL protocol, allowing either the client or server to be impersonated by an attacker with ease. There’s not much point in encrypting traffic when there’s no authentication of the client or server.

Many vendors use encryption to hide how weak their client-server communications really are. It’s a good thing that excellent open source tools like the above make vulnerability assessments of SSL-encrypted communications almost the same level of difficulty as assessing non-encrypted ones.

Related posts:

• OWASP meetings are depressing
• Public Key Signature Forgery

Nessus is primarily designed for manual scanning with an operator setting up a scan, letting it run then parsing the results by hand. When you need to regularly scan a network and report on changes, it can take a lot of manual work. Nessus supports several output formats for scan reports but none are particularly easy to parse using automatic tools such as Unix “diff”.

The problem is that Nessus output includes variables such as scan start and end times which are reported as changes by diff. Some plug-ins also place the all-important “risk factor” identifier in different places in the scan results making automated comparison even more difficult.

Various scripts and Per modules exist that attempt to parse Nessus output. Perl module Parse::Nessus::XML is one, but in our testing we found it can’t always handle XML format used by Nessus 3.0. The other perl modules for Nessus output only provided aggregate information, not details. The graphical client NessusWX has a comparision feature, but it can’t be automated.

We finally wound up adapting a perl script to parse NSR file output. The below file is based on work originally posted to the Nessus mailing list by Darren Bounds. Give it a Nessus .nsr file and it will spit out a sorted tab-separated list like so:

Sample output:

	10.0.6.106 example.com   High    submission (587/tcp) 11499
	10.0.6.106 example.com   High    unknown (32781/tcp) 10659
	10.0.6.106 example.com   Low     filenet-pa (32772/udp) 10228
	10.0.6.106 example.com   Low     submission (587/tcp) 11088
	10.0.6.106 example.com   Medium  http (80/tcp) 11267
	

Only Nessus results labeled “Report” or “Info” and having an identified Risk factor are printed. In other words, only items that need action should appear (the script actually parses some other info from the .nsr file such as CVE nummber, but doesn’t print it. It’s easily modified to include that info if you need it).

The output can be saved between runs then compared using nothing more than the “diff” command. Handy if you want to monitor a network automatically with Nessus and see only the changes.

To use the script, run the command-line Nessus client from cron with the -T parameter to force results to be output to NSR format. For example:

Run the resulting output.nsr file through the parse-nsr.pl script to get a list of vulnerabilities sorted by IP address:

Finally, run diff to compare vulnerabilities.txt with the same output from the previous run to get a concise list of changes:

	diff yesterday.txt today.txt
	382c401,402
	< 205.193.6.94	example.com	Medium	ftp (21/tcp)	10081
	---
	> 205.193.6.94	205.193.6.94	High	ftp (21/tcp)	10556
	> 205.193.6.94	205.193.6.94	Medium	ftp (21/tcp)	10081
	

The script seems to work well with Nessus 3.0. Click the following lnks to view or download the script:

Download: parse-nsr.pl (2.7k text file)

No related posts.