CompTIA Pentest+ PT0-002 – Section 6: Vulnerability Scanning Part 1

48. Vulnerability Scanning (OBJ 2.3 and 2.4)

In this section of the course, we’re going to discuss vulnerability scanning. This is going to be the second part of the information gathering and vulnerability scanning stage of our engagement. Up until this point, we’ve conducted both passive and active reconnaissance, but now we’re going to try and figure out exactly where our targets are most vulnerable so we can determine our plan for the upcoming attacks and exploits phase of the engagement. Now, vulnerability scanning is the process of assessing a computer, server, network, or application for known weaknesses. To conduct a vulnerability scan, we’re going to use a specialized type of software known as a vulnerability scanner. The vulnerability scanning process is going to include detecting and classifying system weaknesses in those assets, as well as creating a report for those identified vulnerabilities and possible recommendations for mitigating them.
In this section of the course, we’re going to focus on this concept of vulnerability scanning as we finish covering the rest of the objectives in domain two, Information Gathering and Vulnerability Scanning.

Now in this section, we’re going to be focused on two objectives. Objective 2.3, which states given a scenario, you must analyze the results of a reconnaissance exercise. And objective 2.4, which states, given a scenario, you must perform vulnerability scanning. Between these two objectives, there’s a lot of things for us to cover for the exam. Now we’re going to begin this section by learning about the vulnerability life cycle and how these vulnerabilities are actually introduced into a computer, a network, a server, or an application. Then we’re going to cover the process for conducting vulnerability scans and some scanning considerations that you need to think about as a penetration tester. Next, we’re going to jump into a demonstration so you can see how a vulnerability scan is conducted, and then how you can read the results of that scan. After that, we’re going to look at web vulnerability scans which are focused more deeply on web applications and the potential errors in their coding. With that said, let’s go ahead and get to work by jumping right into this section on vulnerability scanning.

49. Vulnerability Lifecycle (OBJ 2.3 and 2.4)

To better understand vulnerability scanning, it’s really important for us to understand the life cycle of a vulnerability. Now vulnerabilities can either be known vulnerabilities or unknown vulnerabilities, which we call zero-day vulnerabilities. Now, a vulnerability is any weakness in a system that can be exploited by a threat actor to gain unauthorized access to a computer system. After exploiting a vulnerability, the threat actor can run malicious code, install malware, and even steal sensitive data. Vulnerabilities can be exploited by many different methods, including an SQL injection, a buffer overflow, a cross-site scripting attack, and many others. Now, when we’re talking about vulnerabilities, these can exist in many different areas inside of an organization’s computer network. These can exist on a client. They can exist on a server. They can exist on networking devices, and many other places as well. All these places combined, we refer to them as the attack surface. Now, if you want to be able to protect your network, you want to reduce your attack surface.

There’s many different ways of doing this, including hardening that attack surface. For example, if you install a brand new Window’s server but you never install any patches and you never create any security configurations that system is wide open to attack and it has a very large attack surface because there’s lots of places where people can attack you and gain access into that server. Instead though, if we start shutting down ports, we start installing those patches and we start increasing our security configurations, we are tightening down that attack surface and reducing the attack surface area. This makes it much smaller and more difficult to attack. For example, if you’re running a web server, the only port that should be open should be port 80 and port 443, because those are the only two ports that the web server needs to have open to do their job. Now, if you have something else that’s open, you’re increasing the attack surface and making yourself more vulnerable. Now, when we talk about the life cycle of a vulnerability, it really is a five-step process that moves from discovery to coordinate, to mitigate, to manage, and then to document. Now, personally, I like to think about there being a step before the discover phase, because this is really stage zero where the vulnerabilities are initially created. For example, if I create a brand new website and I add some error into my code, that vulnerability is now existing in that code even before anybody else discovers it. But according to your textbook, they like to start out with stage one being discover. And so that’s where we’re going to start in this video. Now, the first stage is the discover step. This is the first phase of finding a potential vulnerability that an attacker can then exploit.

For example, let’s say I start doing a penetration test against your network, so I start scanning your network for vulnerabilities and I find there’s a server that’s missing a security patch or has a misconfiguration. Well, that is a vulnerability. That allows me to identify a way that I could break into your system. Now, once I’ve identified that specific vulnerability, I now have to create a matching exploit that I can then turn that vulnerability into something that I can attack. When we create this matching exploit, we do this first as a proof of concept to show that this vulnerability can be exploited. Now in stage two, we need to coordinate. At this point, we’ve already completed stage one. We’ve discovered there’s a vulnerability, and we now have a proof of concept working exploit that shows this vulnerability can be exploited. At this point, we need to coordinate with whoever owns that system or creates that source code that there is a problem. For example, if you ended up finding out during the discover phase that there’s a brand new vulnerability in Windows 10 that nobody’s seen before, you need to go and report that to Microsoft. That way they can generate a CVE to let other people know about it, and they can create a patch.

Now, once we get to the third stage, this is mitigate. Now, this is where the vendor or software designer actually takes a look at that vulnerability you’ve reported and they devise a strategy to deal with that vulnerability. Most often, this is going to be changing a configuration setting or issuing a security patch. When they do this, they’re all also going to make sure their CVE is updated and tells everybody here’s what the vulnerability was, here’s how you solve it, and you can either change this setting or install this patch to mitigate the risk. Now the fourth stage is manage. Now, when we manage the vulnerabilities, we’re actually going to go and make those changes. We’re going to deploy the security patch into the environment if we’re a system administrator. We might make a configuration change and test our systems to make sure they’re no longer vulnerable. This makes sure that we no longer have this vulnerability sitting out there as a known vulnerability, and we’ve actually compensated or mitigated the risk. The fifth stage is document. Now with documentation, we’re going to be recording the results and any lessons learned that we had throughout this vulnerability process.

Now, as you can see, this is a very basic five-step model, going from discover to coordinate, to mitigate, to manage, to document. Now, as outlined in this five-step model, there is that discovery that has to happen which makes it a known vulnerability. But before that, we really are at stage zero, which is where we have unknown vulnerabilities. And those unknown vulnerabilities are called zero days. Now, how can you exploit a zero-day vulnerability if you’re a penetration tester or a threat actor? Well, threat actors and penetration testers are always looking for new ways to attack systems. And they do this by using both known and unknown vulnerabilities. Now unknown vulnerabilities, or those zero days, are any unpublished vulnerabilities that somebody has discovered and hasn’t told the manufacturer about. Now, when this happens, the threat actors already know there’s something vulnerable on that system, and they can then attack you, even though you don’t know that you’re vulnerable because it’s not a known vulnerability.

That manufacturer doesn’t know there’s a problem. And so there’s no patch available for it, or no mitigating factors or security controls that could be implemented. Now, once that zero-day vulnerability is seen in the wild, it becomes discovered, and we’re now into stage one. When there’s that brand new zero-day vulnerability that’s been released and you learn about it in the news, as an organization, you need to start figuring out what you can do to mitigate the effects of that vulnerability. Normally this involves putting up extra defenses, like a web application firewall, a unified threat management system, or something like that to block inbound traffic and mitigate some of that risk until you can get a permanent solution, like a software patch, to be able to stop this vulnerability from being exploited. Remember, when we’re dealing with a zero-day vulnerability or an unknown vulnerability that is totally not known by anybody, the only person who knows about that vulnerability is the threat actor. Everybody else is totally unaware about it. Now, at some point, the vendor is going to see it and become aware of it. And when the vendor is aware of it, they’re going to release a CVE. Now this is that coordinate phase in stage two. When they do that, everybody in the public is now going to be aware that there’s this vulnerability for that particular software.

And this means people can go and reverse engineer some sort of an exploit based on that vulnerability. Now this is the time where you are most vulnerable and at risk as a system owner. We call this the risk gap. This is the time when people know there’s a vulnerability but there’s not a permanent solution that can be put in place. During this time, you need to put additional mitigations in place until a full security patch comes out, at which point you can become more secure again. Now what happens if you don’t actually patch those vulnerabilities or mitigate those zero-day vulnerabilities once you find out about them? Well, this means your data could be at risk. And this means somebody can attack your systems and conduct a data breach. This can involve exposing your sensitive data, which would be a violation of your confidentiality tenant of the CIA triad, or it can lead to the data being modified by a threat actor, in which case, you have an integrity violation. Either way, it’s not going to be good for your organization or your data. As a network defender, we want to be able to protect against that. Now this whole idea of a vulnerability life cycle is really something you need to think about as a network defender, as a system administrator, and as a cybersecurity analyst. But as a penetration tester, it also affects you too, because as a penetration tester, you should constantly be looking for new ways to break into systems. As a new zero-day vulnerability is discovered and exploits become available, that becomes additional tools in your toolkit that you’re going to be able to use in an upcoming penetration test. The reason for this is that most organizations aren’t doing a great job with patch management. Yes, they’re patching their systems and they’re getting 90 to 95% of them to be patched up and complete. But there’s still five to 10% of those systems that are missing patches. And if you can identify those systems that are missing the patches, you can now use known exploits to gain your way into those known vulnerabilities on those systems and conduct that as part of your attacks and exploits phase in the penetration test.

50. Vulnerability Scans (OBJ 2.3 and 2.4)

Vulnerability scanning is conducted by both network defenders and attackers. Vulnerability scanning is a specialized type of automated scan for hosts, systems and networks to determine exactly what vulnerabilities are there on a given system. When a vulnerability scan is conducted as part of a penetration test, however, we’re going to be looking at it from an attacker’s perspective to see what that the bad folks out there can actually figure out about a given network. On the other hand, if we’re working as a cybersecurity analyst then we’re going to conduct vulnerability scans internally to our network using many of these same tools, but we’re going to get the results from a defender’s perspective.

Vulnerability scanning and remediation is going to fall under the vulnerability measurement program and most organizations, and it is vitally important to maintaining strong defenses in a given network. Now, there are lots of tools that can be used to perform vulnerability scans, including things like OpenVAS Nessus, QualysGuard and Nexpose. In fact, even Nmap has additional vulnerability scanning scripts that can be used when you’re conducting your penetration testing of a given network. We’re going to cover the usage of these tools in a separate video. But for now, the key takeaway is that these tools are only as good as the configurations you use. So if you don’t configure them properly, you’re not going to get useful information back that you can use to do exploits inside the attacks and exploits phase of your engagement. Now, there are two types of vulnerability scans. We have credentialed and non credentialed scans. credentialed scans are going to use an authorized user’s credentials or administrative account credentials to perform their scans.

By scanning using a value user name and password, the penetration tester is going to emulate an insider threat to find out what an authorized user could actually see across the network. If you’re using a system administrator’s username and password though, you’re now going to see everything across the network, just like the administrator or cybersecurity analyst would. Usually credential scans are going to be performed by network defenders and cybersecurity analysts. But if you are able to find a valid username and password as part of your reconnaissance, then you could use that to conduct a credentialed scan to get even more detailed information about the vulnerabilities on a given network. Usually a credentialed scan is going to provide you with more information than a non credentialed scan will. Now a non credentialed scan is conducted when the vulnerability scanner doesn’t have valid credentials for a user or admin account. Because of this limitation the scan is going to be conducted in the blind, and it’s closer to what an outside hacker’s perspective would be like. During the planning and scoping of your engagement, your client should have determined if you’re going to be emulating an insider threat or an outside attacker. If you’re emulating an outside attacker, then you want to conduct a non-credentialed vulnerability scan as part of phase two of your engagement. When conducting a scan, there are four basic types of scans you can do.

We have discovery scan, full scans, stealth scans and compliance scans. The first one is a discovery scan. Now a discovery scan is the least intrusive type of scan. And it can be as simple as conducting a ping sweep across the network. For example, a discovery scan could be conducted using Nmap to try and figure out which hosts are up and which ones are down in order to build a network map and start figuring out what the architecture inside this network looks like. This usually occurs during the active reconnaissance portion of the information gathering phase in an engagement. When we conduct a discovery scan, all we’re going to really do here is start looking around to see what’s there. For example, in the physical world if I was conducting a discovery scan of an apartment building to figure out who’s home I could walk around and knock on each door to see if anybody’s home. During my discovery scan of this apartment building, I’m going to not open any of those doors or look inside the windows to see if they’re locked or not. Instead, I’m simply going to knock and say, “Knock, knock, knock, are you there? Are you awake?” This is essentially what a discovery scan is doing across a target network. Now, the second type of scan we have is called a full vulnerability scan, and this is much more in depth. During a full scan all of the doors and windows in that apartment building would be checked. We’re going to actually go up to it and start jiggling the door handles, and say, are there any ports that are open? What services are running in here? Are there any vulnerabilities associated with it? And we can usually do this with Nmap or using a more in depth vulnerability scanning tool something like OpenVAS or Nessus if we want to.

When we conduct active reconnaissance we also conducted parts of this full scan to determine if there was any open ports running services and the versions of those services on those ports. But we didn’t try every single potential vulnerability or try to match the vulnerabilities against the versions of software that we found on those target machines. Using a tool like OpenVAS or Nessus though, we could see exactly how many vulnerabilities exist on a given target. Now, the problem with doing a full scan is that it is very easy for network defenders and cybersecurity analyst to detect those scans because it’s extremely noisy when we’re running them. When we run this type of scan across an entire subnet, for example, it’s going to set off all sorts of alarms, notifications and warnings. IDSs and IPSs are going to fire alerts left and right because there’s lots of vulnerabilities that are being probe by that scanner. For this reason, an attacker or penetration tester will usually opt not to use a full scan. Instead, full scans are usually going to be conducted weekly by the vulnerability analyst and cybersecurity analysts, internal to their own network and their own organization to determine their network’s exact security posture. The next type of scan we’re going to cover is known as a stealth scan. Now, the goal of this type of scan is to be a little bit sneakier and try to go unnoticed by the IDSs IPSs and network defenders. To do a steal scan, we’re going to send a SYN packet into the network and then analyze the response that we get back by using a tool like Nmap.

For instance, if the SYN packet goes out, and the server responds with the SYN/ACK like we expect our client can then send a reset packet. Therefore we’re never going to finish the three way TCP handshake, and ideally it’s not going to be logged by the server as a completed connection. Simply put a stealth scan is terminus because it’s less noisy and more secretive than a full scan. Be aware though, that when you use a stealth scan some IDSs and IPSs can still detect this. If you’re going to be doing a lot of scans, you should really try to evade detection by slowing down your scans, breaking them up into multiple different individual scans, or trying to mask the true source of the scanning by routing your scans over the tour network, or other anonymization techniques. Many organizations though, don’t notice stealth scans. And so you can often get a lot of your scans conducted using some basic stealth scans without being noticed. This makes the stealth scans a valuable tool for penetration testers, even though they can take much longer to perform, and they’re not as accurate as a full in-depth scan. The final type of scan we have have is known as a compliance scan.

Now a compliance scan is done to meet a law or regulation. And this makes sure that we can identify any vulnerabilities that would affect our compliance with those laws and regulations and policies. For example, a PCI DSS scan is one of the most common types of compliance scans that are conducted by penetration testers. In fact, most vulnerability scanners have a pre-made scanning template that’s already going to support PCI DSS compliance scans because they are so very common. These templates are going to be based off the compliance checklist that’s been provided by PCI DSS. And when a network is scanned with this profile, it’s going to create a report that provides a full list of all the compliance issues that need to be fixed in order to be compliant with PCI DSS. And that way the organization’s credit card processing systems can remain in compliance. As I said, there are many tools available for conducting these types of vulnerability scans. Nmap is a great tool for mapping out your network, finding open ports, running services, and the basic versioning of each service. If we use the Nmap scripting engine known as NSE, we can also conduct basic vulnerability scans using Nmap too. We’re going to explore Nmap and the Nmap scripting engine in a few separate lessons, because there’s so much to learn about Nmap its usage, and how to rate and interpret its outputs. Another great tool for vulnerability scanning is Nessus. In fact, Nessus is one of the most popular vulnerability scanners out there. Nessus is used to do scanning of the target network and then create a report of the vulnerabilities missing patches, and misconfigurations that exist. Nessus is used to conduct a full scan and compliance scans, so it tends to be heavily used by network defenders instead of penetration testers or attackers due to the amount of noise it creates during its scanning process. With Nessus, it’s not just to tell you that a vulnerability exists, but also why it exists, and how you can fix it. For example, if I ran a scan and the report said there was a remote code execution vulnerability associated with a missing windows patch, it might also tell us that the patch that’s missing is MS17-010.

And as a defender, the best way for us to mitigate this would be to install patch, or turn off file and printer sharing on the affected windows, workstation or server. Now, once the scan is complete a full report is going to be created by the software, and it provides a list of the vulnerabilities, recommendations to mitigate them, and it’ll even classify the vulnerabilities as critical, high, medium, or low based on their CVE data and their associated CVSS score. Now, Nessus is a commercial tool and there’s others out there as well from other companies. For example, Nexpose is a vulnerability scanner that’s made by Rapid7 who developed the Metasploit framework. QualysGuard is another commercial available vulnerability scanner. All three of these have very similar capabilities. There’s another vulnerability scanner out there that you should be aware of, it’s known as OpenVAS. Now what makes OpenVAS different is that it’s an open source vulnerability scanner.

This means you can download for free and use it anytime you want. And all the source code is also available for review. OpenVAS uses plug-ins just like other scanners do to scan for known vulnerabilities. And then it’s going to sort your results by the risk of the vulnerabilities that we found just like Nessus, Nexpose, and QualysGuard does. The key difference with OpenVAS is that it is free and open source. So I highly recommend that you download it, run it against your home network to see what vulnerabilities you may have, and then start practice reading the outputs from one of these vulnerability scanners. Now, the vulnerability scanners I just mentioned are all great general purpose vulnerability scanners also known as infrastructure scanners, but there’s other vulnerability scanners out there that focus on specific classes of vulnerabilities. For example, Nikto is a web application vulnerability scanner, and it’s dedicated to conducting web application scanning.

While the other scanners discussed we’ll be able to scan a web server and then look at the Apache vulnerabilities or MySQL vulnerabilities and associate them with a particular missing patch or configuration, they’re not very useful against any custom code that the company’s web development team may have created themself, Nikto on the other hand, focuses on web application code and tries to find specific bugs and vulnerabilities in that code. Nikto can assess custom web applications that a company may have coded themselves making it a great addition to your penetration testing toolkit when you’re trying to identify if a site is vulnerable to attacks, like an SQL injection, directory traversal, cross-site scripting attack, or other coding vulnerabilities. If you’ve been asked to conduct an assessment of a web application, or you’re trying to break into a web application during an engagement Nikto is one of the best tools for that particular job. We’re going to talk more about web vulnerability scans in a separate lesson as well.

• Category: Uncategorized