Category Archives: Uncategorized

3 Types of Vulnerability Scanning – Pros and Cons

Posted on by
Reply

The 3 Main Types of Vulnerability Scanning Approaches

 

There are 3 major types of vulnerability scanning you can use on your networks. Most large organizations will have to use all 3 (or at least a couple) methods.

  • Unauthenticated Network Based Scanning

  • Authenticated Network Based Scanning

  • Agent Based Scanning

This post will go over the differences of these methods and explain why a combination of methods is typically needed. (This is standard network and host scanning. Containers will be covered in a different post) Yes, passive network scanning exists too. I don’t feel knowledgeable enough on that yet to speak to it.

Back in 2011 I posted a quick explanation of some of the differences between authenticated and unauthenticated scans. Not much (if anything) has changed since then in regards to the differences between those 2 types of scans. However, I will add some more details on the differences in this post.

Unauthenticated Network Based Scanning

These are scans that you run from a system with “scan engine” software or a an appliance type of system. These scans run across a network, targeted at other systems without knowing anything about the targeted systems other than the IP address or DNS name.

No credentials are provided in these types of scans.

The unauthenticated scan has to mostly guess at everything it tells you about the target system because all it can do is probe the ports and services you have open on your system and try to get it to give up information.

  • Cons – More false positives. (it is guessing)
  • Cons – Less detailed information. (it is still guessing)
  • Cons – May require more network connections than authenticated scans.
  • Cons – You are more likely to impact legacy services or applications that do not have authentication or input sanitation.
  • Cons – You have to maintain access to your targets through firewalls, IDS, IPS, etc.
  • Cons – You have to manage a scanner system(s)
  • Pros – Only shows the highest risk issues
  • Pros – Gives you a good view of the least capability an attacker on your network will have. Any script kiddie will be able to see anything an unauthenticated scan shows you.
  • Pros – Is usually faster than an authenticated scan in many cases.

Authenticated Network Based Scanning

These are scans that you run from a system with “scan engine” software or a an appliance type of system. These scans run across a network, targeted at other systems but provide login credentials to the targeted system that allow the network scanner to get a command shell (or similar access) so it can simply run commands and check settings on the targeted system. This allows for much more accurate and detailed information to be returned.

You will never get 100% authenticated scanning success on large networks because of the variety of system types and authentication methods required. You will probably not be able to get into every appliance, printer, iot device, etc.. So 100% is not typically a realistic goal for diverse environments.

  • Pros- Less false positives. (Much less guessing)
  • Pros- More detailed information. (again, doesn’t have to guess anymore)
    • You can now see things like missing patches, specific os versions, locally installed 3rd client software versions.
  • Pros- May require less network connections than authenticated scans.
  • Pros- You are less likely to impact 3rd party legacy services or applications that do not have authentication or input sanitation, because the scanner doesn’t have to guess about the service.
  • Pros – You can now gather configuration information off the system to help feed a CMDB or perform configuration baseline checks. You are now a configuration checking tool and not just a vulnerability checking tool..
  • Cons – Still has most of the type of impacts on custom written socket servers/services.
  • Cons – You are now awash in a sea of data (vulnerability data) about that system.
  • Cons- Risk assessment requires more analysis because instead of a handful of findings from an unauthenticated vulnerability scan, you may now have 30-40 findings.
  • Cons – Is often slower than an un-authenticated scan in many cases, because it is running specific commands from a shell on the system and waiting for the returns etc.. This is not always the case, and it some cases authentication may speed up scans.
  • Cons – You have to maintain access to your targets through firewalls, IDS, IPS, etc.
  • Cons – You have to manage a scanner system(s)

Agent Based Scanning

Agent based scanning requires the installation of a daemon/agent on Linux and Unix systems, or a “Service” on Windows systems. I will refer to this an a “agent” from now on.

The agent is installed locally on the targeted systems, runs on a schedule, and reports the data up to a centralized system or SaaS service. Vulnerability scan agents are usually fairly light weight, but the different variations and vendors all have their own quirks. I highly recommend you perform testing on a variety of systems and talk to existing similar clients using the vendor’s agents before going with this approach.

One of the big pitfalls with an agent is that it cannot fully talk to the target system’s network stack like a network based scanner.. So if you have an nginx service that is misconfigured, it likely won’t report that as an issue, while a network based vulnerability scan would.

This lack of capability to simulate a network client is the big gap in agent functionality. As a result, you cannot truly get a “full” vulnerability picture without running at least an additional network based scan. In some cases, the agent data may be good enough, but that is a decision up to each organization.

Agents are good solutions for systems like mobile laptops that may rarely be on the corporate network, or for systems like some public cloud scenarios, where you can’t maintain full network scanner access across a network to the target host.

  • Pros- Less false positives. (Much less guessing. The agent is installed on the system and just asks for the information. )
  • Pros- More detailed information. (again, doesn’t have to guess anymore)
    • You can now see things like missing patches, specific os versions, locally installed 3rd client software versions.
  • Pros- Requires Far less network connections. Usually just an outbound push of data.
  • Pros – The system with the agent can report up its data from anywhere to your Saas backend or potentially into an internet connected backend if that is your design scenario. So the scanner just resides with each host.
  • Pros- You are less likely to impact 3rd party legacy services or applications that do not have authentication or input sanitation, because the agent doesn’t talk to the network stack and services like a network client.
  • Pros – You can now gather configuration information off the system to help feed a CMDB or perform configuration baseline checks. You are now a configuration checking tool and not just a vulnerability checking tool..
  • Cons – You are now awash in a sea of data (vulnerability data) about that system.
  • Cons- Risk assessment requires more analysis because instead of a handful of findings from an unauthenticated vulnerability scan, you may now have 30-40 findings.
  • Cons – You now have an agent and piece of software on every target system that you (or some team) has to own and somewhat manage. Since every company has slight different ways this is done, it adds a layer of complexity and overhead compared to running a scan across the network.
  • Pros- You have to maintain far less network access (usually just an outbound connection) IDS, IPS, WAF’s etc don’t matter anymore.
  • Cons – You now have to manage an agent, and are now a customer and user of every target system
  • Cons – Your agent may (will) get blamed, (and sometimes rightly so) for impacting performance on a system.

So what is the best solution?

Like almost everything in IT and IT Security, the best solution depends on your requirements. Most larger organizations want the verbose data that an authenticated scan or agents provide.

With most people using laptops these days, classic network based vulnerability scanning is going to miss a lot of assets that an agent will be able to cover.

Datacenter implementations may be covered fine with authenticated scanning, and not having to manage an agent or be called in to every performance issue (because you have something running on the system) in that scenario may reduce headache.

Public iaas hosts may require unauthenticated scanning from an Internet based scanner, and an agent on the host to get the full picture of data..

Ultimately, the right approach is the one that meets your requirements and fits within your funding and capabilities.

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

Posted on by
Reply

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.

 

Root Cause Analysis in Vulnerability Management

Posted on by
Reply

 Root Cause

If you are not familiar with the subject of “Root Cause” or Root Cause Analysis I would encourage you to read about it on Wikipedia before reading the rest of this post. In short, Root Cause Analysis is trying to determine the earliest factors of the Cause of an event or issue and not simply treating the Symptoms of an event or issue.

Nothing New Here..

I worked in IT Infrastructure and studied business for years before I started working in IT Security. I’ve found that most operational management principles apply to Information technology and Information security processes in nearly the same way as they apply to manufacturing or other business processes.

Root Cause Analysis is yet another operations management topic that directly applies to information security vulnerability management.

Some use cases for Root Cause Analysis in Information Security Vulnerability Management.

(Root cause analysis for these 4 cases below will be broken out into another post and linked here when complete)

  • Why are system vulnerabilities there?
  • Why do system vulnerabilities continue to show up?
  • Why are coding weaknesses in my code?
  • Why do coding vulnerabilities continue to show up in our code?

 

Isn’t this Common Sense?

No.  See below for why…

Treating or Correcting Root Cause is Harder than Treating Symptoms

Treating symptoms is nearly always quicker and easier than resolving root cause.

– Treating symptoms gives an immediate short term relief. This short term & quick fix creates a very direct emotional response. If you are in pain, and a doctor gives you a shot to numb the pain, that feels great right? But what if they never fix the reason you are having the pain in the first place? You could keep needing those shots every day. After a while you will probably decide that putting in the effort of fixing the “root cause” of your pain is a better option.

Resolving the root cause to an issue typically doesn’t have that immediate emotional feeling of relief because it takes longer. It takes planning, discipline, and often a strategic patience to influence others to help resolve the root cause of an issue.

I think that treating symptoms is the more “natural” reactive response to a problem. The more proactive and mature response to an issue is to take the time to determine and analyze root cause.

Examples…

– Reboot it? A great example of this issue is very common in IT Infrastructure or Development operations. An application area or systems team has an application or system that starts behaving strangely or stops working. The common response is to just reboot the system or restart the process. This may resolve the problem that time, but it is likely that the problem may re-occur, or just be an earlier indicator of a larger problem. If you take the time to gather documentation (memory dumps, logs, etc..) for root cause analysis before rebooting the system or restarting the process you will be able to research root cause. This is more difficult initially because the process of getting memory dumps and logs may take a while longer than simply restarting something. If you never address the root cause, these symptoms will keep stacking up and drive up your support and maintenance costs as well as impact availability.

– Patches – Is it easier to install a bunch of patches on some systems, or to implement a solid process and resources to ensure that patches are always correctly installed and validated on systems? Installing a patch is treating a symptom. Implementing an effective patch management process is treating root cause.

Some may argue that root cause of patching starts all the way back at the processes of the operating system development. That is true, however you always have to realize that there are some root causes that are out of your control. In this case, you can effectively treat the root cause reason of why the patches are missing, but not why they are needed in the first place.

–Social Issues – Social and political issues most often have symptoms treated because resolving root cause is typically assumed to require behavior changes or other changes that are considered too difficult or unpopular to implement.

Should my focus always be on fixing Root Cause?

Now we are getting into opinion, but I think that root cause should be identified and how to resolve the issue should be analyzed. Choosing to address root cause or not is a business prioritization issue just like any other project that should be evaluated. However, the choice to Not address root cause needs to be documented and known. Why? Because the symptoms of that root cause will continue, and they should be expected to continue.

 Hybrid Approach

I think that taking the parallel approach of treating some symptoms while working on remediating root cause is a reasonable approach. Unfortunately, since the temptation to focus on treating symptoms is so strong, it often takes a very determined person to ensure that root cause is addressed.

BADSIG errors when updating Backtrack using apt-get

Posted on by
6
  • If you are getting BADSIG errors when updating your Backtrack install.. (Like below)
Reading package lists... Done
W: GPG error: http://32.repository.backtrack-linux.org revolution Release: The following signatures were invalid: BADSIG AB6DA34B475A6B7F BackTrack Repository Admin <emgent@backtrack-linux.org>
W: GPG error: http://all.repository.backtrack-linux.org revolution Release: The following signatures were invalid: BADSIG AB6DA34B475A6B7F BackTrack Repository Admin <emgent@backtrack-linux.org>
W: GPG error: http://updates.repository.backtrack-linux.org revolution Release: The following signatures were invalid: BADSIG AB6DA34B475A6B7F BackTrack Repository Admin <emgent@backtrack-linux.org>
  • You can run the following commands to clean things up and allow your updates to start working again. I found this on someone else’s website in regards to Ubuntu updates, so it doesn’t have anything directly to do with Backtrack as far as I can tell.
  • I created a little script called fixsig.sh to resolve this issue as it seems to happen a lot to me. Probably because of something I’m doing causing the issue.
root@bt:~# cat fixsig.sh
sudo apt-get clean 
cd /var/lib/apt 
sudo mv lists lists.old 
sudo mkdir -p lists/partial 
sudo apt-get clean 
sudo apt-get update
root@bt:~#

Hope this helps someone!

How To Understand a Vulnerability Scan Report – Part 1 – The IP Address

Posted on by
1

Part 1 of a multiple part series explaining vulnerability scan data and nuances of how that data should be used.

 

  • IP Address

    • This is (of course) the network address that the vulnerability was found on.
    • The IP address is the one piece of data you can count on to always be in your vulnerability scan data.  A vulnerability scanner always must have an IP address to probe for vulnerabilities, so this is the key starting point for any vulnerability scan data.
    • Some of your customers or app/developers infrastructure developers may not understand networking very well, so it is a good idea to supply dns name and/or host name to them also.  I will cover those in a later post.
    • One host (server, machine, appliance.. whatever you want to call it) may have multiple IP addresses. Correcting a vulnerability may resolve the finding on multiple IP addresses.  Some common uses of multiple network adapters listed below..
      • Main Adapter
      • Backup Network Adapter
      • HeartBeat/Cluster Network Adapter
      • Management Card (This is often an embedded device on its own and not managed by the host OS)
      • Other (Redundant adapter, Crossover cable adapter, Some servers may have adapters on multiple networks for various reasons)
    • One good approach for vulnerability footprint reduction is to ask the server and application owners if their services and/or apps need to be available on all the IP addresses on the system where the service is found running.
      • For example.. Apache may be found running on all the IP addresses on the server.. It usually does not need to be on all of them.
    • The IP address listed may actually be the Virtual IP (VIP) that points to a particular port on a webserver. (ports will be covered later)
      • One Host/Webserver may have multiple websites running on it. The VIP that you see in the vulnerability scan may be redirected by a network load balancer to a particular listening port on one of the webserver IP addresses. This means there can easily be a Many-to-One relationship of IP addresses to one server or group of servers..
      • In this case you will need to have information about the load balancer configurations of your environment to determine which webserver port/instance and/or server may have the vulnerability in question. This information should show the VIP and which port on another IP address that gets the traffic from that VIP. The VIP is often facing a non-trusted network like the Internet, or just used for load balancing and/or to allow a webserver to be used more efficiently.
    • Other– The IP address can often tell you other information. Based on your network design it could tell you physical location, system type, network zone (like DMZ) etc.. It is a good idea to understand how your company provisions and allocates IP addresses and networks. This information can often allow you to understand more about an IP address than what they vulnerability scanner tells you.

Your Internet Presence and Vulnerability Mgmt

Posted on by
Reply

If you get put in charge of vulnerability management for a large organization with many internet facing websites, you may run into some roadblocks on

1) Determining who owns what websites,

2) What servers host which websites.

3) What virtual IP’s load balance to which internal webserver hosts.

4) Which different outsourced entities have ownership over different websites and IP ranges.

5) Getting a listing of your total internet facing IP ranges.

6) Determining which websites and IP ranges are hosted by your company, and which are 3rd party.

7) Determining which websites process any PCI or PII data.

Scans Versus Penetration Tests

Posted on by
Reply

What is the difference between scanning and penetration testing?

Those of us responsible for managing Vulnerability scanning and penetration testing often seem to get the same question over and over… What is the difference between a vulnerability scan and a penetration test?

You would think that this is not a difficult topic to grasp, but some folks really do struggle to remember the difference. I’ll lay it out here in the most simple way I know how..

  • Scan = Look for holes and issues on a network or website. Usually with some type of scanning tool.
  • Penetration Test = Exploit and Hack holes that you have found on a network. And see how far you can get. A penetration test often starts with a scan, but is not limited to just the scanning.

Some good scanning tools are..

McAfee Vulnerability Manager (used to be called Foundstone)

QualysGuard

Nessus

Many companies offer penetration testing services.  I’ve only had experience with a few, so my only advice is to make sure your contracts are well written and that you are careful when working with a small company.