0 Replies Latest reply: Apr 11, 2014 10:11 AM by Renaud RSS

How to test the 'heartbleed' vulnerability with Nessus (and the Nessus Perimeter Service)

Renaud Master

We tried to make it easy to perform a network scan for the 'heartbleed' vulnerability with Nessus and the Nessus Perimeter Service:

 

How to do a scan?

 

 

1. Make sure your plugins are up-to-date. We did changes to the UI to make it easier and they're in plugin feed#201404091456. In doubt, log into your scanner as an admin, go to Settings -> Last updated and click on the arrows next to the date.

 

2. Create a new scan policy by going to Policies -> New. You'll see the Heartbleed wizard:

 

HeartBleed.png

 

Click on it, and select how intrusive you want the scan to be. We've got three options -- a light scan that will only scan ports known to have SSL enabled, a normal scan that will try a larger set of ports and a thorough scan that will try to find SSL on any 65k ports

 

Save the policy.

 

3. Create a scan schedule

 

Go to "Schedules" -> New, name your schedule, and make sure you select your newly created Heartbleed policy. Then enter the IP range to scan (or the host names).

Save the schedule and run it, and you should see results quickly enough.

 

 

What does the policy do?

 

This policy is optimized for large coverage of IPs. It disables every plugin except the port scanner and the heartbleed plugin (and their dependencies). It will quickly determine whether a host is up or not (it will save time by not trying to determine if the host is a printer, novell netware server or a load balancer).

 

This policy only enable our remote heartbleed vulnerability check (73412). We also have a collection of local checks for various OSes that will locally determine if the packages are up-to-date, but they are not part of the policy, as local checks tend to be part of more comprehensive scans, not one-offs. We recommend local packages even if plugin 73412 does not fire up, as this will fix client-side vulnerabilities and will prevent any future problem.

 

Why am I seeing differences between the Nessus plugin output and other scripts I found on the internet?

 

Several proof of concepts that are available out there do not properly implement the SSL protocol and will fail in some situations, thus leading to false negatives. Note that a lot of these proof of concepts are really the same program ported to different languages. To alleviate doubt, the Nessus plugin displays a snippet of the memory content grabbed from the remote host, as below:

 

Output.png

(Note that the last 16 bytes are always random, so in the particular case above the memory we could read is just made up of zeroes. Don't wait to see something critical in that dump to patch the service )

 

What should I do if I'm not seeing the plugin fire up even though I thought it should?

 

Nessus has a feature called "audit trail" that logs why the plugin does not fire up. Click on it to see the reason:

 

AuditTrail.png

 

Keep in mind that sometimes the plugin won't fire up because the remote server is not affected Only servers running on OpenSSL 1.0.1 are vulnerable.

 

 

Why is the result marked as "High" and not "Critical" ? Can I change it?

 

Nessus uses CVSS as a scoring system, and heartbleed is interesting as it pushes CVSS to its limits. Basically, CVSS is all about the host itself and not the data that flows through it (or the innocent bystanders being compromised) -- heartbleed may let you get information from it, but not execute commands on it. So with all the right CVSS factors, we arrive at a score of 9.4, not 10. If you're not happy with this score, you can change it for this scan but also all future scans. Click on the list of vulnerabilities, click on the result for this plugin and click on "Modify":

 

Modify.png

 

Then you can recast the risk to "Critical" and tell Nessus to keep this change for all the future scans:

 

Critical.png

 

If for some reason you want to delete this rule in the future, go to User Profile -> Plugin rules

 

Edit: due to popular request, explaining why it's a "high" and not a "critical"