Penetration testing is a useful tool to improve the security of IT infrastructures as well as applications. They help uncover security vulnerabilities early on and give the company a chance to fix security issues before they are actually exploited. Penetration tests are therefore an effective means of improving the security of a company or having it evaluated. Be it customer requirements, an upcoming certification, or your company’s intrinsic need for security. Often, a penetration test by an external service provider is the requirement.
In advance to a penetration test, however, it is often assumed that one’s own company is secure in principle. Accordingly, a penetration test should identify few to no vulnerabilities, and remediation of these findings should also be feasible in a timely manner. The use of monetary and human resources is predictable. Accordingly, a timely pentest is carried out by an external party, which evaluates the security of one’s own company concluding in a final report. That definitely sounds like a desirable process, and not just for you!
"What actually happens if you don't find any vulnerabilities? Will there even be a final report?"
Problem definition
In reality, however, the results of a penetration test often differ from the expected result. Even in the few cases where applications or IT infrastructures are securely built and operated, the associated pentest reports are usually never empty. A variety of deployed standard configurations of web servers, firewalls, or other network components provide a multitude of findings to report in a final report. Coupled with a standardized risk assessment methodology such as the Common Vulnerability Scoring System (CVSS), these misconfigurations often end up as a medium risk finding in the final report.
The result of the penetration test is then perceived by companies as a surprise, as the final report does not confirm the company’s security with a green seal. This often brings up the need for a second test (a retest) after corrective actions have been implemented. This leads to potentially unplanned and additional costs, as the initial result of the penetration test is not desired to be passed on to third parties such as customers, insurance companies, etc.
Even if this very probable course is already addressed in advance of the penetration test and the offer also lists a re-test, customers are often taken by surprise by the result of a penetration test. The combination of faulty expectations and a cognitive bias such as “survivorship bias,” where only other companies are hacked and you yourself have never had an incident, often make the emotional experience of a penetration test a negative one.
However, this does not have to be the case. By preparing for a penetration test independently, many findings can be avoided in advance. This brings you, the customer, a little closer to your desired goal of a blank final report and allows us penetration testers to test in a more targeted manner. This can lead to an earlier completion of the pentest project and effectively save costs, should the pentest provider, such as Pentest Factory, charge transparently according to maximum effort.
Means of preparation
The preparations for a penetration test are, of course, based on the frame parameters of the underlying penetration test. Since there are a variety of test types and test objects, we will focus on general preparation options. These can and should be incorporated into an internal corporate process that is executed regularly and deliberately. Regardless of whether a penetration test is due or not.
In addition, we would like to clarify that preparation in advance of a penetration test is not always desirable. For example, if you’ve been raising the lack of resources for your IT department with management for years and finally get approval to conduct a penetration test, don’t do anything yourself up front. Temporarily glossing over the results would be the wrong approach here; after all, you are hoping for a realistic result from the penetration test that represents your company’s current situation and defenses. Only a negative result can signal grievances in your company to the management. You should also stay clear of preparative measures when conducting phishing campaigns, interview-based audits, or audits of your external IT service provider. After all, a real attacker does not announce himself beforehand to sensitize his victims.
The following preparation options are available in principle:
- Performing an active port scan on your IT infrastructure components
- Identification of unneeded network services and ports
- Identification of faulty firewall rules
- Identification of obsolete software components and vulnerabilities incl. CVEs
- Identification of typical misconfigurations
- the disclosure of version information in HTTP headers and software banners
- The use of content from a standard installation (IIS default website, Nginx or Apache “It works” website)
- Failure to forward unencrypted HTTP to the secure HTTPS protocol
- and many more
- Execution of an automated vulnerability scan
- Independent identification of so-called “low-hanging fruit” findings of a penetration test
- Identification of obsolete and insecure software components incl. CVEs
- Receive recommended actions to address the identified vulnerabilities.
Carrying out port scans
For all non-technical readers of this blog entry, we would like to briefly explain what port scanning is and what advantages it brings. Network services, such as a web server for providing a homepage, are operated on so-called network ports. A network port is a unique address that can be used to clearly assign connections to applications. A website like this blog therefore waits for incoming connections on the standardized ports 80 and 443. Network port 80 is usually used for an unencrypted connection (HTTP) and should automatically forward to the secure port 443. Behind port 443 is the secure and encrypted HTTPS protocol, which loads the page content from the server and makes it available to your client browser for display. From an attacker’s point of view, these network ports are very interesting, as there are usually services or applications behind them that can potentially be attacked. There are a total of 65353 ports, each for connectionless (UDP) and connection-oriented communication protocols (TCP). The assignment between a port and the service behind it is standardized. However, the configuration can vary freely and does not have to be based on the standard. From an attacker’s point of view, these ports must therefore be enumerated in order to know which services can be attacked. From the company’s point of view, these ports are important to ensure that only those services are offered that are intended to be reached. All unnecessary services should be closed or their front door secured by a firewall.
Network ports can be identified using freely available network tools. One of the best-known tools for identifying open ports and recognizing network services is called “Nmap”. This program is free, open source and can be started under both Windows and Linux. It provides a large number of call parameters, which cannot be fully explained and discussed in detail.
Nevertheless, in this blog post we would like to provide you with the basic information you need to carry out your own scans. To successfully start an Nmap port scan, you only need the IP address(es) of the IT systems to be scanned. Alternatively, you can also provide the DNS host name and Nmap will automatically resolve the IP address behind it.
You can use the following command to start a port scan after installing Nmap. All open TCP ports in the range 0-65535 are identified and returned. An explanation of the call parameters can be found here.
nmap -sS -Pn –open –min-hostgroup 256 –min-rate 5000 –max-retries 3 -oA nmap_fullrange_portscan -vvv -p- <IP-1> <IP-2> <IP-RANGE>
As a result, you will receive three result files and an output in your terminal window as follows:
The results of the first port scan only list the network ports identified as open. In addition, we receive the network service behind it, which should be located behind the port by default (RFC standard). However, as already mentioned, network operators do not have to adhere to these port assignments and can tend to operate their services behind any port. For this reason, we need a second port scan to reveal the real network services behind the ports that have now been identified as open.
To do this, we execute the following command, specifying the previously identified ports and the same IT systems to be scanned. An explanation of the call parameters can be found here .
nmap -sS -sV –script=default,vuln -Pn –open –min-hostgroup 256 –min-rate 5000 –max-retries 3 –script-timeout 300 -d –stylesheet https://raw.githubusercontent.com/pentestfactory/nmap-bootstrap-xsl/main/nmap-bootstrap.xsl -oA nmap_advanced_portscan -vvv -p <PORT1>, <PORT2>, <PORT3> <IP-1> <IP-2> <IP-RANGE>
After completion, we again receive three result files and a new output in the terminal window as follows:
The resulting “nmap_advanced_portscan.xml” file can also be opened with a browser of your choice to visually display the results of the port scan as an HTML web page. HTML reports are not supported by Nmap by default, but an individual stylesheet such as “https://raw.githubusercontent.com/pentestfactory/nmap-bootstrap-xsl/main/nmap-bootstrap.xsl” can be defined when the scan is called up, which visualizes the results as an HTML report. Furthermore, the results can be filtered and there is an option for CSV, Excel and PDF downloads.
The results of the port scan should now be checked by a technical contact, preferably from the IT department. Make sure that only those network services are offered by your IT systems that are really necessary to fulfill the business purpose. In addition, take a close look at disclosed software versions and check whether the versions used are up-to-date and have been hardened with all available security patches. Also check the validity of identified SSL certificates and refrain from using insecure signing algorithms such as MD5 or SHA1. For internal IT infrastructures, you will usually have identified a variety of network services because you have scanned from a privileged network position within the organization. Here, firewall restrictions are generally implemented somewhat less strictly than for publicly accessible IT systems or services within a demilitarized zone (DMZ).
Execution of automated vulnerability scans
Vulnerability scans are usually performed using automated software solutions that check IT systems for known vulnerabilities and misconfigurations. The resulting findings are problems which are publicly known and for which automated scripts have been written to detect them. Please note that automated vulnerability scanners are not able to identify all potentially existing vulnerabilities. However, they are a great help to detect standard problems quickly as well as automatically.
The regular execution of automated vulnerability scans should be integrated into your internal business process. This process is independent of whether and how often you perform penetration tests. However, it is generally recommended to also have penetration testing performed by an external service provider, as both automated and manual techniques are used to identify vulnerabilities. Only by combining both types of testing by an experienced penetration tester a majority of IT vulnerabilities be detected and ultimately fixed by you. Accordingly, implement a vulnerability management process in your company and scan your IT assets regularly and independently.
Several products can be used to perform an automated vulnerability scan. For this blog post, we are focusing on free variants. This includes the following products:
- OpenVAS by Greenbone
- Nessus Community by Tenable
The products are usually self-explanatory after an installation. After specifying the scan type and the IT assets to be checked, an automated scan takes place and the results are clearly displayed in the vulnerability scanner web application. All findings are usually reported with a description, risk assessment, and recommendation for remediation. Moreover, you get the possibility to export the results as CSV, HTML, PDF, etc.