On the opposite end of the spectrum is “White Box Testing”. Here you would provide as much infrastructure information as possible to the tester. This would include Server IP addresses, operating systems, applications, network mapping, and even possibly an account. This approach is good to see what could happen in the worst-case scenario where an attacker has already gained access and knowledge.
In the middle of those two extremes is “Grey Box Testing”. Here you would provide more information than in the black box scenario, specific IP ranges and key servers for example, but not full access like with white box. A tester can use their information to make educated guesses and focus on different sections of infrastructure but still attempt to conduct reconnaissance and provide information on network discoverability.
Often, we think of a malicious attacker sitting somewhere in a dark room, maybe halfway around the world, trying to break in through your perimeter to get at your important internal servers. What happens if someone connects to one of your wireless networks? Or maybe plugs directly into an exposed ethernet jack? Possibly even successfully phishes an employee? A pen test can be conducted from an external perspective, an internal perspective, or even both given enough time. One approach can unveil vulnerabilities that the other may not.
Finally, in a category all its own is web application “Pen Testing”. Many companies have public facing website and applications and they are prime targets for compromise. Tools like Burp Suite and OWASP ZAP are used for automated scanning and testing as well as aiding in manual request crafting. Web applications require specialized sets of skills to both build and break. The OWASP foundation maintains a “Top Ten Project” for the most common and dangerous web application security risks, https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project .
Why have a Penetration Test?
One of the most frequent reasons we’ve see for a pen test is meeting compliance requirements. Nearly every industry has some sort of compliance need, whether its healthcare with HIPAA or retail with PCI. Depending on the box you’re trying to check there could be specific requirements to have a pen test conducted yearly or more vague directives like confirming with a third party that an application is secure.
Even if it’s not mandated, an unbiased third party testing your infrastructure can point out issues from a different point of view than someone accustomed to the environment. Good pen test will provide actionable responses to any findings and take the burden of research and investigation of the shoulders of internal IT. The finding will also be more in-depth than a simple vulnerability scan, chaining together vulnerabilities and techniques in ways that are more complicated than an automated system is capable of.
For many companies it’s a matter of when, not if, a compromise occurs. There are constantly news stories about well-known companies with major budgets suffering for massive data breaches and we all know about the constant plight of spammy phishing emails. One un-caffeinated employee could be caught off-guard and give their company credentials to a stranger over the internet and the rest is history. Every day, automated bots constantly scan anything connected to the internet and attempt to execute basic exploits for known vulnerabilities on unpatched systems or legacy devices.
Example Case Study – Healthcare
Protected Health Information (PHI), is a prime target for criminals to steal and it can wreak havoc on both the patient and the covered entities. As a covered entity you need to ensure an unauthorized entity cannot access PHI from either inside or outside your infrastructure. Below is a breakdown of how a pen test might go, divided up by the different stages of a test.
The tester and all stakeholders need to review the rules of engagement to point out any mission critical systems that can’t be brought down, establish clear lines of communication, and ensure everyone has the permission and authority to conduct these tests.
Before trying to get into the systems themselves the tester may be able to find plenty of information just sitting on the open web. Bugmenot.com houses previously disclosed credential dumps which may contain still active credentials and Shodan.io constantly scans down IoT devices. You can also use Google Dorks, a technique for crafting specialized Google searches to find documents that were indexed by Google but shouldn’t have been public facing.
Scanning and Enumeration
To properly understand and exploit the client’s environment, a tester needs to gather information on every system available to them. Nmap is the bread and butter tool for this task. The tester can gather information on the underlying operating system, available ports/services and even test for some specific vulnerabilities using the Nmap scripting engine. The Metasploit Framework is another good tool to use when testing for specific vulnerabilities in services uncovered by Nmap.
Metasploit returns in this section to help facilitate exploiting those vulnerable systems that were discovered in the previous steps. For example, an unpatched Linux machine hosting an internal web application was discovered and compromised, allowing for access to tons of company information, including PHI, that was internal only. Also, it turns out there were still default credentials present on one of the firewalls, so a couple extra rules were added to specifically allow all traffic heading out from that compromised server, so no one will notice the data is leaving the network.
After the initial breach, this phase is most useful on a pen test for proving impact. If any machine is compromised, the credentials can be extracted either encrypted or unencrypted and broken/used by the attacker. Persistent rootkits can be installed, and backdoor admin account can be created and never detected if there isn’t routine auditing. Those credentials and permissions can be used to access storage systems like Epic and then exfiltrate PHI from the company.
Performing a pen test is largely useless to the client without some sort of after-action report. Here the vulnerabilities should be categorized by severity and remediation suggestions should be attached. There are a few different popular methodologies for rating vulnerabilities, DREAD and STRIDE among them. Providing information on steps to recreate the test results could also aid the client in completing remediations. To aid in report creation there are automated tools as well as frameworks that contains a lot of information for known vulnerabilities and exploits, the Serpico Project is one of those automation tools.