'Logic will get you from A to Z; imagination will get you everywhere.' - Albert Einstein
The primary focus of this article is infrastructure security assessment.
Supposing you are a C-Level executive, CISO role, or holding a similar position, within this article, we tried detailing a few hints about what a mature security vendor should provide to you as part of an engagement journey.
Infrastructure penetration testing or an adversary simulation helps you identify how a malicious actor could potentially access your data through your network.
The security test should try fingerprinting, enumerate active services and open ports, validates, and exploits known vulnerabilities in your network infrastructure, on-premises, or the cloud, helping to keep your sensitive information and systems better protected. While the final benefit of executing security, testing remains somewhat the same for all the infrastructure penetration testing type, a couple of key differences between them should be mentioned as follow:
- Help highlight how a malicious actor could take advantage of various internal security misconfigurations.
- Threat model and expose potential business risk and blast radius damage that an internal attacker can inflict.
- Test and highlight potential flaws within the firewall or API gateways configuration level that can be leveraged and lead to sensitive information exposure.
Cloud / Containers / Virtualization
- Test and highlight potential security misconfigurations within architecture design blueprint implementation and how those are leveraged to pivot or escape container or virtualized environments, setting up access for different attack vectors.
- Provide detailed technical recommendations describing methods and fixes that need to be applied to increase the security resilience, logging, and tracking capabilities for the affected cloud services and components.
One of the questions raised among numerous C-Level executives, CISO roles, or professionals holding a similar position is, how do I know the vendor did a professional job?
Most of the time, a penetration tester assesses infrastructure using commercial tools like Nessus / Qualys or well-known open-source options as Nmap, Massscan, Zmap, or similar others. With the companies increasing their appetite to move their presence from on-premises into the cloud, an external perimeter network security assessment should report limited and low-risk findings.
So, let us try to bring some light here.
In this blog post, we decided to detail a little about why nowadays it is essential as infrastructure penetration testing MUST shapeshift into an adversarial simulation and generate, at least, the same excitement as a Web application, API, or a Mobile engagement.
There are alternative methods to execute port scan and fingerprint applications and running services. Before going into the subject, we would like to remind the reader what it means a TCP connection and what elements are involved.
A picture of a TCP IP handshake flow
A picture of TCP IP packet components
We will assume we have an internal machine running on a C-Class IP address, 192.168.126.132, with a Python3 HTTP Web Server on TCP/IP port 8000. We have already run the Nessus and Nmap. Now, what is next? Should we stop and start reporting, or? Let us go more in-depth and cover it from all angles.
We decided to start looking into a library named SCAPY and the p0f tool.
Q. What's SCAPY?
A. According to Scapy.net, Scapy is a powerful interactive packet manipulation program. It can forge or decode packets of a vast number of protocols, send them on the wire, capture them, match requests and replies, and much more. Also, while this library has many pros, one of the scapy cons is not very fast. We noticed that scapy might not be able to deal with large amounts of packets.
Q. What's p0f?
A. p0f is a tool that utilizes an array of sophisticated, purely passive traffic fingerprinting mechanisms to identify the players behind any incidental TCP/IP communications (often as little as a single regular SYN) without interfering in any way. Version 3 is a complete rewrite of the original codebase, incorporating a significant number of improvements to network-level fingerprinting and introducing the ability to reason about application-level payloads (e.g., HTTP).
Running Nmap and p0f against the machine, no firewall, we will get these details where both the Nmap and p0f fingerprinted the HTTP server banner.
Picture of a Nmap tool ran against the targeted machine.
Image of a tcpdump output captured on the targeted machine side.
Image of p0f tool fingerprinting result.
Let us go deeper into the SCAPY library.
First, scapy uses a command-line interface (CLI) to build up packages. The beauty of this is you can interact with almost anything and assign valid or random values, have the package sent and investigate the response.
Here is an example of how an IP package does look from a SCAPY user perspective.
Based on the above, this is an example of a simple scapy network port scanner, port 8000, using the "SYN-ACK" flag.
sr(IP(dst="192.168.126.0/24")/TCP(dport=8000, flags="SA") )
res1,unans1=sr(IP(dst="192.168.126.132/32")/TCP(dport=, flags="SA") )
Here is a picture of the expected results when the above commands are used.
Tools like Nmap are limited to a TCP connect scan because they do not have a documented way of adding a TCP option in an SYN scan. However, with SCAPY, we can do this as below:
res,unans = sr(IP(dst="192.168.126.132/32")/TCP(dport=8000,options=[('Timestamp',(0,0))]),timeout=4, retry=-2)
So far, we went through a couple of examples about how the SCAPY library can be used during an infrastructure security scan and enumerate and fingerprint potentially available services.
We would advise you to use p0f from the terminal instead of loading the module from the scapy IDE as something we discovered during our engagements. The main reason is detailed here, and we will not go further this path.
Now, to make things a little more difficult, we will enable UFW on our target host. UFW stands for Uncomplicated Firewall and is probably the easier firewall to configure and use. If you never worked with it before, then DuckDuckGo is your best friend here.
We will rerun the Nmap scan, and the port will return as filtered this time, as was expected.
A SCAPY scan will return a similar result too:
At this point, we will repeat the test as follows:
- In one tab, we have SCAPY loaded. Then we launch a packet fuzzer targeting the target machine IP and, to expedite the things, we mention port 8000.
- In the second separate tab, we will capture the targeted machine's traffic to analyze it later. Notice the random flags sent to the firewall because of fuzzing.
- In a separate tab, we start the p0f sniffing tool and capture the traffic.
As a result, and under this circumstance, we were able to fingerprint the HTTP server banner, as shown in the next picture. Thus, using SCAPY allowed us to fingerprint the HTTP server running, although the machine assessed has UFW enabled.
An adversarial simulation brings a different assessment approach, more robust and oriented to follow various rabbit holes. It might produce a rich technical output, comparing to a standard penetration testing engagement.
We refer here to the standard penetration testing concept because, sadly, we noticed that lately, those engagements are treated as a boring customized results report of a Nessus, Qualys, Nmap, or other similar tools.
Imagine you are a C-Level executive, CISO role, IT Security Manager, or having a similar position, and you are going through a penetration testing report. Then you start noticing a couple of details as we have described above; this should be a good sign that the vendor did a great job.
Overall, the SCAPY library and p0f tool are making a good addition during a network infrastructure adversarial simulation. SCAPY can generate custom packets at a low level, and p0f is a versatile fingerprinting tool. Besides, p0f is coming with a library of fingerprinting signatures that can be extended. It is worth checking out. SCAPY is not the only option that can be used and play with the IP packets; however, we will try to provide broad coverage of the other options as part of the next blog posts.
It is essential to go deeper and try as many techniques as possible. Fingerprinting underlying infrastructure, discovering the open ports, and banner out running services is a key step before any further actions.
Also, it is important to do further research on the detailed techniques, understand them, and write your custom tools.
This blog post is aimed at beginners and beyond. It does not present any novel research and only serves as an introduction to taking an infrastructure security assessment further than just using tools everyone else is using.