Security researchers may use many techniques to identify vulnerabilities on a system or in software. In this video, you’ll learn about vulnerability scans, static code analyzers, and fuzzing.
Vulnerability scans are used to determine if a system may be susceptible to a type of attack. This process does not perform an attack on the operating system. Otherwise, it would be a penetration test. Instead, this is simply checking to see if the potential for an attack exists on a particular system.
For example, a port scan is a very simple type of vulnerability scan. It informs you what ports may be open and which ports are closed on a particular system. This doesn’t mean that every open port is somehow susceptible to an attack. But it does show where certain ports are open which could potentially be used by an attacker to take advantage of a vulnerability.
We commonly use these vulnerability scans to try to find these systems before the attackers do. And the engine of these vulnerability scanners are very good at identifying all of the systems that might exist in a particular IP subnet. We often associate these vulnerability scans with someone who’s on the outside trying to gain access to devices that are on the inside. But we also have to consider performing scans inside of our network as well because it’s very possible that an attacker could be part of an insider attack.
Vulnerability scans are also notorious for providing a large amount of data. And not everything found by a vulnerability scan is always accurate. So we generally have to go through vulnerability scan reports after the fact to see if we can determine what type of vulnerabilities may exist and what others might be a false positive.
Here’s a better view of this vulnerability scan. And you can see there are a number of vulnerabilities that were found. Some are designated as critical, others medium and low, and then informational. And you can see the details for each of those vulnerabilities listed next to the severity.
Here’s the full report for this vulnerability scan. You can see the severities are listed here. You can see there are two critical, two high, nine medium, and so on. As we scroll through this list, we can see the first critical vulnerability is one that is an OpenSSH or OpenSSL package random number generator weakness, which tells us that the SSH host keys are weak on that particular device and explains that it’s due to a bug in the random number generator of its OpenSSL library. That would certainly qualify as a critical vulnerability.
The next vulnerability on the list is a Unix operating system unsupported version detection. This is for a system that maybe we had no idea was still running in our network. And this has identified this Unix operating system on the remote host as being no longer supported and therefore no longer able to be patched with security updates.
All of the vulnerabilities listed in this report would need to be checked and verified before making any changes to that system. And if we are able to confirm these vulnerabilities, especially those of higher severity, then we may want to put them through our normal change control process to patch the operating system or the applications.
Application developers also have a way to check their code for potential vulnerabilities. They would use a static application security testing system. This is software that will review the source code of an application to determine where potential vulnerabilities might be. So it might be able to identify a buffer overflow, a database injection, or some other type of vulnerability that can easily be identified inside the code itself.
Although these static code analyzers are quite good at finding vulnerabilities written in the code itself, there are certain types of vulnerabilities that may not appear on a static code analyzer. For example, a static code analyzer doesn’t understand how certain technologies may have been implemented in the code. For example, something relating to authentication security or an insecure implementation of cryptography is not often found by using a static code analyzer.
And just like vulnerability scans on the network, we also have to check the results of the static code analyzers as well. In the list of output, we’ll need to determine what part of the static code analyzer is correct and what of the recommendations may be a false positive.
Here’s the output from a static code analyzer. You can see there are a number of issues that were found within the code itself. For example, we can look at test.c, which is code, on line 73. And this says that the SetSecurityDescriptorDacl tells us to never create a NULL ACL. That would be an Access Control List. And it explains that an attacker can set it to Everyone, which is deny all access, which would even forbid administrator access. That’s important feedback for an application developer. They may be able to use this to now create a more secure application.
Application developers can also perform dynamic analysis. You’ll sometimes hear this referred to as fuzzing. Fuzzing is designed to take random input and put it into an application to see what the results might be. You’ll sometimes hear this referred to as fault injecting, robustness testing, or a number of other different terms.
This dynamic analysis is looking for the application to respond in an unexpected way. It may be that we crash the entire application with certain types of input. Or maybe the server itself creates an error. Or there’s an exception message on the screen. All of these can be used to gather details about where we may want to provide additional input verification, especially in the code itself.
One of the first fuzzers was created in 1988 as a class project at the University of Wisconsin. It was the Operating System Utility Program Reliability class. And Professor Barton Miller and his class created the Fuzz Generator.
From that point forward, there have been a number of different fuzzing engines created, some of them for different operating systems or code bases. Some of these are platform specific, while other fuzzers may focus on a particular programming language. This is almost always an automated process because there may be hundreds or even thousands of different iterations putting input into the application to see what the results might be.
If you want to try a fuzzing engine yourself, you can download one from CERT. That is the Carnegie Mellon Computer Emergency Response Team. They have one called the Basic Fuzzing Framework, or BFF. And you can find the link to that at professormesser.link/bff. Here’s a sample of the CERT BFF running on my system. And it’s going through a number of different iterations, where it’s putting random information into the app and waiting to see what the application does with that data.
When you’re installing an application in Windows, macOS, or Linux, you may find that the application is provided as a complete package. This may be part of an executable that’s run during a setup process. Or it may be a standalone package, especially if you’re in Linux.
As with any application that you would install in a system, it’s important to verify the contents of that software. One of the first things you’ll want to check is that the package that you’re installing can be trusted. Did you download the package from the manufacturer directly? Or did this come from a third party. If it came from a third party, there may be an opportunity for an attacker to add malware or put some other type of vulnerability into that package.
When you install the package, you’re also installing this vulnerability. And if you’re not quite sure what’s inside of that package, it might be worthwhile to load it into a lab environment. Test out the contents of the package so you really know what’s on the inside. Once you trust the data, you can then deploy it into your production environment.