It’s important to find vulnerabilities in your network before the attackers. In this video, you’ll learn about vulnerability scans, false positives, credentialed scans, and more.
<< Previous Video: Threat Hunting Next: Security Information and Event Management >>
If you’re working in IT security you are undoubtedly going to be performing some vulnerability scans. These scans are designed to look at systems to see if potential vulnerabilities might exist in an operating system, a network device, or an application. These are a little bit different than a penetration test, which is really trying to gain access into the inner workings of your devices. Instead the vulnerability scan is trying to determine from the outside if there is the potential to gain access to those systems.
One common type of a vulnerability scan is a port scan. That’s when we will look at a device and determine what ports happen to be responding on that particular IP address. From here you may be able to gather information about things that might be less than secure. For example, in this device port 23 running over TCP which would be the Telnet service is an open port on this device. And without knowing anything else about the system we know that telnet inherently sends information that is not secure, it is not encrypted.
So this would be something to bring up as a potential vulnerability on this computer. It’s common to run vulnerability scans on all of the devices connected to the network. This would be servers, workstations, laptops, and other devices that are connected to the network as well. You want to be able to perform these vulnerability scans from the perspective of the attacker. So you want to perform these from the outside, on the internet side, coming inbound to your devices. But you might also want to run these scans internally as if you are an insider who had full access to these systems.
We’ll want to gather as much information as possible, and these vulnerability scans collect a lot of information. There’s plenty of details that we’ll need to examine in the log to determine what we want to do with this information once the scans are complete. The vulnerability scanners use are very powerful pieces of software that are designed to look at many different aspects of how your systems are running in the hopes that it will find some vulnerabilities on that device. We call these non intrusive scans, but of course, there’s a little bit of intrusiveness as it’s scanning the different port numbers and perhaps trying to find out if a potential vulnerability might exist.
But these aren’t penetration tests. These vulnerability scanners will not try to attempt to take advantage of the vulnerability. Instead they’ll simply decide if a vulnerability might exist or not. After the scan is complete you can run your own tests to see if that vulnerability really does exist. You can run a penetration test on its own or you can find a specific exploit that might attack that vulnerability and see if that vulnerability does exist.
There are different approaches to performing these scans. One approach is to scan as if you are someone who does not have access to the network. This would be a non credentialed scan. This user doesn’t have the credentials to be able to log on to a device and gain additional rights and permissions. You might want to think of this as someone who is out on the internet, who doesn’t have any access to your network, and this would be a scan that’s run from their perspective. But of course, there is the perspective of someone who is on the inside of your network and trying to exploit a system. So you might want to run these types of vulnerability scans as a user who has rights and permissions to log in. This is a credential scan and it’s a way to tell how much of a vulnerability might exist if you were someone who had a little bit of access to these systems.
Let’s look at the results of a vulnerability scan that I ran on my network. I ran this with the Nessus Essentials product that was able to look at an individual IP address at 10.1.10.13. It’s important to remind you at this point that you should never run a scan on your network where you do not have specific permission to do so. You should also make sure that if you’re running a scan on the network. That you understand exactly what that scan is going to do. There is some conversations that takes place between the scanner and that remote device, and there have been cases where a vulnerability scanner has found a bug in a piece of software that caused that particular system or application to suddenly become unavailable.
So you could potentially crash a system or make the system unavailable simply by performing one of these vulnerability scans. Make sure that everybody knows what’s happening and that you’re ready if anything should happen to those systems. On this device 10.1.10.13 I ran a vulnerability scan it only took two minutes to scan this particular device. Let’s click on this host and see what the results of this report might be. Let’s start with these two critical vulnerabilities at the top.
The first is a Debian OpenSSH SSH OpenSSL package random number generator weakness. This means that someone could gain a shell remotely into that system. I can see why they would have qualified this as a critical vulnerability. When we click on that, we can see more information about this specific vulnerability. The remote SSH host has been generated on a Debian or Ubuntu system which contains a bug in the random number generator of its OpenSSL library. This says that the attacker can easily obtain the private part of the remote key. That means that they’ll be able to decipher the remote sessions or set up man in the middle attacks because this vulnerability exists on the system.
It also gives you places to go to read more about it and things that you can do to resolve this particular problem. Let’s go back in these vulnerabilities and look at the other critical vulnerability, which is a Unix operating system unsupported version detection. I ran the scan against a very old version of Linux and in fact the vulnerability tells us that this is a very old Unix system that is no longer supported. There will be no security patches for the product. So this will have additional vulnerabilities as time goes on. The output from the vulnerability scan is listed here. And we can see that it is Ubuntu 8.04. That support ended many years ago and that was one where we now can make decisions about upgrading that system or putting a system in place that would have security patches ongoing.
Let’s go back to the listing of vulnerabilities. And you can see there are other vulnerabilities in here, such as mixed vulnerabilities, medium, low, and a lot of informational vulnerabilities are listed here. You now have to make a decision over which of these vulnerabilities are important, which of them you should cover first, which should be second on the list, and there may be vulnerabilities in this list that don’t affect you or do not have a concern in your environment. You’re going to have to go through each one of these and make those decisions. And that vulnerability scanner went out to that device and looked for every possible vulnerability that it might have, or at least every possible vulnerability that the vulnerability scanner knows about. There’s a database within the vulnerability scanner that’s to constantly be updated so that it knows what to look for and where to look for these types of vulnerabilities.
You will certainly find vulnerabilities associated with particular applications like desktop apps, or mobile apps. In fact, here’s a desktop app vulnerability CVE-2020-1889 which has a security feature bypass issue in WhatsApp desktop. And you’ll need to update the application to be able to resolve that security vulnerability. There are also vulnerabilities that you may find associated with web based applications, this is software that’s running on a web server. Here’s an example of one in a PHP file for an organization UCMS that has a product 1.4.8. And this results in an information leak via an error message and provides information that it should not be providing. And of course, there could be scans against network devices on your network where you get information about misconfigured firewalls, devices that have ports that are open that perhaps should not be open, and other vulnerabilities as well.
This is a vulnerability CVE-2022-5079. An issue was discovered on D-Link DCS-2530L before version 1.06.01 Hotfix and et cetera. This allows authenticated command injection. So this would be a vulnerability that is on the router itself that would need to be resolved with a firmware upgrade. If you’re performing these vulnerability scans you’ll be doing a lot of research prior to the scan, and a lot of research after the scan is complete. And there are many resources online that can give you the information you need to be able to make decisions when these vulnerabilities are found.
One very common place to go is the consolidated CVE database at the National Vulnerability Database. You can find that at nvd.nist.gov. This is a summary of all of the CVEs that you can also find at the common vulnerabilities and exposures database, those are the CVEs. And you’ll find that at cve.mitre.org. You might also want to go directly to the manufacturers themselves. And one great place to get information about Microsoft Windows is directly from Microsoft. You’ll find those Microsoft security bulletins at www.microsoft.com/technet/security/current.aspx.
There will be some vulnerabilities identified by the scanner that cannot be tied back to a specific known CVE. So you might also need to do some additional research to really determine the scope of this particular vulnerability. I mentioned earlier, one of the best places you can go to get a summary of these CVEs is the National Vulnerability Database at nvd.nist.gov. This is a list that is synchronized with the CVE list from mitre and has some nice search capabilities on it as well. But another feature that is inside the National Vulnerability Database is the Common Vulnerability Scoring System. This provides a number associated with the vulnerability that can give you a perspective of just how severe this vulnerability might be. Each vulnerability gets a score between 0 and 10 and this allows you to at least have some measure that you can use to determine which vulnerabilities may be more severe than others.
There’s currently two different scoring methods that are used, a scoring version 2.0, and another one that is currently version 3.1. These He’s use different criteria to create the score so you need to make sure that you pick the version that you would like to follow and then compare that against all of the vulnerabilities that you found. The National Vulnerability Database is a critical summary of these vulnerabilities and if you’re putting together a record keeping program or trying to automate the processes that you have around vulnerabilities, you will absolutely want to involve this National Vulnerability Database. As you saw in the vulnerability scan that I had created there were a number of different vulnerabilities that were identified and from different categories as well.
One of these categories is a lack of security control. These devices should be running antivirus, anti-malware, and its own personal firewall to allow or restrict access to that system. So vulnerability scan might be able to determine that certain security procedures are not in place on that device. There might also be misconfigurations. On the vulnerability scan I ran it found that there was an NFS misconfiguration that allowed anybody to see the NFS shares that were on that device. Vulnerability scans might also inform you that the guest log in access is enabled on that system. So that you can then go to that device and disable that type of access,
And of course there are operating system and application vulnerabilities that are found every day. So this vulnerability scan will give us the heads up to let us know if a particular piece of software needs to be updated. One of these challenges with vulnerability scans is you will occasionally find a vulnerability that is reported, you’ll go and investigate that vulnerability, and what you’ll find is that the vulnerability scan didn’t get it right. That in fact that vulnerability doesn’t exist on that particular device. We call these false positives because our vulnerability scan has positively identified this vulnerability. But after doing research, we find that positive indication was actually false. And the false positive now can be dismissed and we can continue with our research.
False positives of course, are different than a low severity vulnerability. Sometimes people will dismiss the low severity vulnerabilities as being something that they don’t have to worry about on this particular system. That’s different than a false positive. At least a low severity vulnerability is a real vulnerability that exists, albeit at a very low priority level. A false positive is one that doesn’t exist at all. So we need to be sure to categorize those properly when we’re trying to evaluate how to take the next steps with this system to make it more secure.
Perhaps worse than a false positive would be a false negative. This is when a vulnerability exists on a system but our scanner was not able to identify it and did not tell us anything about that vulnerability existing on that particular device. To be able to resolve problems around false positives and false negatives, you want to be sure that you have the latest version of the signatures running for that vulnerability scanner. This will allow it to filter out anything that it knows is not valid and find all of the vulnerabilities on the system that might have been missed if you were using an older database.
If you do run a scan and you get a false positive or false negative, you want to work with the vulnerability scanner manufacturer and see if they can create an updated database that resolves these issues. Of course there are a number of vulnerabilities you can look for without using some type of formal vulnerability scanner. For instance, you could do a configuration review of an operating system to see if there may be any obvious security issues. For example, you may want to validate what the security settings are in a device.
It’s easy to log into the device and see what the firewall settings might be set o or see if antivirus has been updated recently. You can look at workstations and see what the account configurations are and make sure that nobody’s turned on any particular security shares that might put the entire device at risk. On servers themselves we are concerned with the access control to those servers and the permissions of users who are connecting to that server. And we want to look at our security devices themselves and make sure that we haven’t missed configured a firewall rule to allow access when really we wanted to deny access.