Penetration tests can simulate an attack to exploit vulnerabilities. In this video, you’ll learn about rules of engagement, the exploitation process, responsible disclosure programs, and more.
Penetration testing or pen testing is a process where we simulate an attack on our own systems. This is very similar to the process we follow with vulnerability scanning. Except with penetration testing, we’re performing actual exploits to see if we can gain access. Some organizations perform standardized penetration testing on regular intervals. And this may be not only a good security best practice, but it may be mandated depending on the type of business it is.
If you’d like a good overview of the pen testing process, I’d recommend looking into the National Institute of Standards and Technology. That would be NIST. They have a document called The Technical Guide to Information Security Testing and Assessment. If you’d like a download of that, there’s a link available at professormesser.link/800115.
Before anyone starts performing the first penetration test, we first need to understand the rules of engagement. The rules of engagement are a formal list of rules that are written out so that everyone understands the scope and the purpose of this testing. For example, it might be useful to know when penetration testing is allowed in your environment. The type of tests may be things like an on-site physical breach to see if someone can get into the actual building, or maybe someone’s performing an internal penetration test or external test from outside of the facility.
These rules of engagement might also define in what hours would be appropriate to perform these tests. Some organizations would prefer not having any type of pen testing occurring during business hours, and they might specify perhaps after 6:00 PM local time only. There are also detailed breakdowns of exactly what systems are allowed to be tested. For example, there might be specific IP address ranges. There might also be emergency contacts listed in the rules of engagement so that everyone knows who to contact in case of any questions.
Occasionally, a penetration test will uncover sensitive information. So it’s useful to know exactly how to handle that data, and we can document that also in the rules of engagement. And it’s also important that everyone understands exactly what systems are in scope for this test and which systems are out of scope and should not be touched. We want to be sure that we’re testing the right systems, but we also want to be sure that our production systems stay up and running.
Now it’s time to perform the penetration test. Our objective, of course, is to try to take advantage of these known vulnerabilities to gain access to a system. One of the challenges with this is the process of exploiting a vulnerability could also cause that system or service to fail. This is one of the reasons we document all of that information in our rules of engagement so that we’re not bringing down any systems that might be considered critical.
For example, during the process of trying to gain a privilege escalation, we might choose to use a buffer overflow. But unfortunately, that buffer overflow process may cause an instability in the system and cause that operating system to crash. And on a single system, there might be multiple exploits that you might want to try. You might want to use password brute force attacks. There could be social engineering. You might use database injections or perhaps buffer overflows.
Some of these vulnerabilities are very technical and require access to the system, whereas others like social engineering may all be done over the phone. Ultimately, we want to see if we can gain access to these systems. If we can exploit those vulnerabilities, then it’s entirely possible that a third-party attacker can do that as well.
Getting access to a system is really the first step in a much larger process. Of course, we want to find an exploit that allows us to take advantage of a known vulnerability and gain access to a system. Once we gain access to the system, our work has really just started. At that point, we want to use that system as a jumping off point where we can laterally move from one device to another now that we are inside the network.
We also want to be sure that we’re able to get access to the system again. And we may not want to use that same vulnerability to do it, especially if we’re concerned that they may close that vulnerability with a software patch. Instead, we may want to create a backdoor for ourself. We might want to add our own account on the system or change the default passwords for an existing account.
If you’re on the outside of a network, there are often firewalls and other security systems preventing access to the inside. But once you get that first inside access, you can use that as a pivot point to be able to gain access to other systems that are inside the network. Many attackers will set up that system as a relay or a proxy. So they would use that initial system as their starting point and use that as a way that they could jump to other systems within the same network.
If you look through a list of CVEs or any vulnerability list, you’ll see a constant flow of updated vulnerabilities that are made public. Although this vulnerability has been made public, there have been a lot of work prior to that date making sure that the software could be patched and perhaps releasing a patch for that vulnerability. This means a researcher had to identify that vulnerability and then show that vulnerability to the software developer or the manufacturer.
From that point, the manufacturer will need to update their code, test the code, and then publish an updated version of that software without the vulnerability. This process obviously takes time. So it may be weeks or even months between the time that a researcher identifies a vulnerability to the time that a patch for that vulnerability is available. Only after the patch is released is that information made public and put into a CVE list.
This process is often encouraged through the use of bug bounties. Bug bounties are rewards for someone finding a vulnerability in this software. Usually, it’s the software developer or manufacturer that provides the funding for these bug bounties. The process usually works by the researcher identifying a vulnerability with that software and bringing it to the attention of the software developer. From there, the developer spends time creating a fix and making that fix public. And at that point, the vulnerability and the mitigation for that vulnerability can be made public to everyone else.