How To Understand a Vulnerability Scan Report – Part 2 – The Network Port

How To Understand a Vulnerability Scan Report – Part 2 – The Network Port

Part 2 of a multiple part series explaining vulnerability scan data and nuances of how that data should be used. Part 1 was about IP addresses.


  • Network Port
    • This is the network Port identifier number (1 through 65535) where the vulnerability scanner found a vulnerability.
    • The port number is not always provided in some vulnerability scan reports, although it is a critical piece of information, as will be discussed below.
    • The teams that own the systems or applications with vulnerabilities will often be unfamiliar with network ports until they do some further research on their application or system.
    • In part 1 of this series it was discussed that a system can have more than 1 IP address. The level of complexity increases with ports because each IP address can have up to 65,535 tcp and/or udp ports.
    • It is very unusual for most IP addresses to have more than 100 or so ports open, so many vulnerability scanners will consider a system with many ports open to be a firewall configured to respond on all ports as a defensive measure.


    What does a port number tell me?

  • A listening port tells you that some piece of software is accepting network socket connections on a specific network port. Your vulnerability is on the software that is using that port.
  • The port number should be your starting point to determine which service or application is listening for incoming socket connections. This service or application port listed in your vulnerability scan is what typically has the vulnerability.
  • There are many common ports used that are easy to identify.
  • Once you know what the program or service is, your next step is often to contact the person or team responsible for managing that service or application.
  • One nice thing that most vulnerability scanners will do is give you the text response that the vulnerability scanner got from the port when it initially fingerprinted that port.
    • This text info is valuable because it will often give you the response header/banner/response from the service and often has enough information for you to understand what the service is, even if you had no previous information about that port.


    Okay, that’s nice, but if I see a webserver vulnerability, I already know to call the webserver folks.

  • It’s not quite that easy. Run a port scan (all ports) on a heavily used server and you might be surprised how many http/https protocol servers are running.
    • Even dedicated webservers will often have many different instances of a webserver running, each one on different ports. Being able to tell the owning team the specific port that had the vulnerability finding is critical to being able to determine the source of the problem.
    • If the vulnerability is application related, knowing the port is likely how you will determine the application team that needs to remediate the vulnerability finding. The team that manages the webserver may know which application instance is running on which port, and can direct you to the proper application team.

    Load Balancing can throw you off.

  • Network Load Balancers can take traffic directed at one port on an IP address, and redirect that traffic to different ports on different IP addresses.
  • This can obviously cause some issues for you since you will see the port on the Virtual IP address on the load balancer as having the vulnerability.
  • This is a more common scenario you will face when scanning servers from outside a DMZ, from the Internet, or on a hosting or cloud environment.
  • It is critical for you to have the network load balancer configuration and be able to trace which IP addresses and ports are actually responding with vulnerabilities. Without this information you are stuck at the Virtual IP address without being able to go any further to find the true IP and port that has the vulnerability.


CVE ID Syntax Change – My Feedback

CVE ID Syntax Change – My Feedback

Today (Jan 22, 2013), I saw that Mitre had released a public call for feedback in regards to proposed CVE identifier syntax changes.

I took a few minutes after reviewing their proposed choices and sent a response. If you work heavily in vulnerability management or information security I would recommend you review the proposed changes at the link above and give your feedback.

The text from my feedback on the propose changes is below.


 I think Option B is the best option.. 

Reasons for Option B
– Option B provides the clearest path forward for programs that use or parse CVE numbers because it…

  • Allows backward compatibility (software shops can continue using current parsing logic & display formats) It only has to change if/when needed.
  •  Allows companies to update their CVE data field parsing algorithms to a best practice of taking any numbers found in the digits field without requiring them to expect the padded zero formats. Expecting and forcing a new format forces changes throughout any existing code.
  • Allows simpler algorithm for parsing new or old CVE format data. If you force padded zero’s, then programs will have to base their parsing logic for the number field based on the year field, or be based on the number of digits in the field. If you choose option B, the logic can be the same for the old and new format (just accept whatever is there), and not really care about the number of digits initially. This might allow for an easier adoption by code that currently parses CVE data. (option C would require even more changes)

– Yes, option B does not force the hand of every software developer to immediately update code and logic for your changes,  which might actually be your saving grace. This puts the responsibility on the software developers and companies to comply with the format changes, but does not force a change on them that breaks functionality and their product otherwise.

This takes the pressure off Mitre that will come from “breaking” money-making products for companies, and puts it back on the companies to make the changes.

Why Not A?
-Depending on a certain number of digits (6) with leading zero’s forces programs to immediately update algorithms and display fields before they are compatible. 1 year is not much time for applications heavily integrated into enterprises. I doubt you will get good adoption for your new format in the requested 1 year timeframe regardless.

Why Not C?
-Same reason as “why not” for reason A. And you are now adding yet another field to be parsed that adds very little effective value.

Why Not B?
– The reasons posted on Openwall as shortcomings for reason B are valid, except that I don’t really buy the whole “it’s not as forward compatible” logic. It actually could be the most forward compatible option if your guideline is that you must accept any number of digits given.

Malware Analysis Tools Overview

Today I gave a presentation to our local Northwest Arkansas ISSA chapter on the topic of Malware Analysis Tools and handed out some of Lenny Zelter’s cheat sheets.

I’ve attached the LibreOffice Presentation file to this post to allow easy access. Malware Analysis Tools Presentation

The NorthWest Arkansas ISSA chapter typically meets the first Tuesday of each month at Dink’s BBQ in Bentonville, Arkansas.