Have you ever looked at Nessus scan results to find the below in the output? Recently I was on engagement and encountered just this situation. I found myself wondering how in the world I would validate all of these findings for SSL/TLS.
Luckily, one of my co-workers suggested I take a look at testssl.sh. This tool sped up the process significantly and I found that I could do some really great things with its output.
Before we get into testing at scale, we should become familiar with the tool and its output. As you’ve probably already guessed, testssl.sh is a shell script that interrogates SSL and TLS configurations to provide comprehensive information on the protocols and cipher suites supported by a service.
The tool can be found on GitHub at https://github.com/drwetter/testssl.sh. There are a number of options that can be used to run very specific tests against a service (specific protocols, cipher suites, vulnerabilities, etc). However, since there are numerous findings and a single host is likely to match multiple of those, we’ll opt to run all tests (no arguments). This will provide a great deal of flexibility in reporting. It is worth noting that testssl.sh can evaluate non-HTTP services as well. This article will focus only on HTTP services.
Run against a single host from a terminal testssl returns output that looks very nice with colorization in the terminal output. However, this is somewhat limiting in that it restricts the tester to taking screen captures rather than providing a customer an actual report as output.
The terminal coloring that testssl.sh outputs is ANSI Escape Code. As a result, terminal control sequences are intermingled with the output text. This could be troublesome, but there just happens to be a tool named aha (ANSI HTML Adaptor) for Linux that will convert the output that testssl.sh generates into an HTML page as illustrated below.
I’ve found that piping output from testssl.sh through aha has a couple of drawbacks. First, testssl.sh sometimes hangs while enumerating the ciphers supported by SSLv3. If this occurs, we have to break out of the command (CTRL-C) which kills both evaluation and reporting. I’ve also found that aha sometimes encounters a broken pipe error and hangs waiting for input to proceed. Once again, reporting and evaluation both fail due to this issue.
For both of these reasons, the best strategy for testing at scale involves the following two steps. First, run testssl.sh in a for loop feeding IP addresses of the hosts under test from a file and limit the runtime of the process. If you really want to speed things up, you can use xargs to make the whole process multi-threaded. Next, capture the raw output from testssl.sh and process it with aha after all of the raw output has been generated. Doing so will allow you to build custom reports focusing on only the details of a specific finding. The raw output will have full details included in it. This means that you can run testssl.sh one time and create custom reports for each individual finding listed.
Let’s walk through the process. The first thing you need to do is grab the target IP addresses from the Nessus results. One great way to do this is to use EyeWitness. This tool is best known for assisting in performing quick triage of Nessus scan results. EyeWitness will consume a .nessus file and produce an HTML report with screen captures of all web servers (or rdp/vnc) found in the report. The option that we’re interested in the “–createtargets” switch. This takes the Nessus file and creates a list of URLs in the output text file.
With the target list generated, the for loop can be built to begin scanning. The following syntax will iterate through each of the URLs (Nessus was configured NOT to resolve names) in the targets file.
for FILE in $(cat https_targets.txt); do IP=$(echo $FILE | cut -d ‘/’ -f 3); timeout 20 /opt/testssl/testssl.sh $FILE > $IP.txt; done
Each host will be scanned with a timeout of 20 seconds and the output will be piped into a text file with the naming convention <IP Address>:<port>.txt. Using the timeout command allows us to avoid the issues with cipher enumeration hangs. Since we’re outputting to a text file we also don’t get broken pipe issues with aha. Note that the timeout value should be tuned to the environment you’re working in to ensure that all output from testssl.sh is captured.
Once scanning is complete, we can use the output files to create custom reports that are purpose built for a particular finding. As an example, the cat and egrep commands are used below to gather all of the SSLv2 results from the text files created as a result of scanning. The output produced by this command can also be piped through aha to produce an HTML report that is specific to this finding.
An example HTML report can be seen below.
So, go grab a copy of testssl.sh and let your imagination run wild. This tool generates output that is very easy to parse into reports that are focused on specific issues that need to be addressed.
Don’t forget that validation doesn’t stop here. If you find something that is exploitable (heartbleed, shellshock, etc) make sure that you demonstrate exploitation and put it into context for the organization.