Today we are starting a series of articles showing the different angles that can be taken when tackling a pentest.
"A PENTEST RECREATES THE ACTIONS CARRIED OUT BY AN ATTACKER IN ORDER TO IDENTIFY ANY VULNERABILITIES"
Let's start by defining what that is. A pentest is an audit process that involves carrying out controlled attacks against the defense mechanisms of the environment that is being analyzed in order to identify any vulnerabilities in them.
When someone who doesn't work in IT asks me about this business, I usually make a comparison with the movie The Italian Job, in which the one of the characters starts "attacking" a safe in order to test how secure it is.
When we carry out this type of test, we have to combine the use of “conventional” – or formal – methodologies with the “art” of the attacker (by putting ourselves in their shoes). This means we can use the OSSTMM (Open Source Security Testing Methodology Manual) or OWASP (Open Web Application Security Project) as a basis for our work.
The use of formal methodologies enables us to replicate the processes and procedures on different clients. But that is not enough.
When security professionals have to deal with complex defense systems, or simply the individual characteristics of each company, they have to use all their 'magic powers'.
Let's give a few examples to illustrate the different cases to you.
Attacking on all fronts
The pentesting process begins with defining the target. According to the different methodologies, this phase may be given different names, but the important thing is the concept: to discover all of the organization's or system's information before attacking it.
For various reasons, this is the most important part. The types of audit or pentesting can be categorized according to how much advance information the organization gives us:
- In the case of having detailed advance information, it's called White Box.
- In the case of having partial advance information from the organization, it's called Grey Box.
- And audits that are carried out without any advance information from the company are called Black Box.
Let's imagine a typical company whose website is hosted externally. The company contracts us to carry out Black Box pentesting (without advance information) and we discover the IP address of the hosting service provider. We don't have permission to carry out a network attack against this server, as the website is on a shared server. As such, it would be a mistake to define or prepare an attack from this angle.
Let's give another example. The company has a website that is hosted by a hosting service, but when we carry out a WHOIS, we discover that the mail server's MX record is stored on an IP of a regional ISP (Internet Service Provider).
Or, the MX is on the same hosting service provider but the mail server's SPF (Sender Policy Framework) record shows an IP address that's “external” to the hosting service provider. This is the line of attack we need to utilize: the IP address of the company and not that of the external web server.
"WE START BY DEFINING A TARGET TO KNOW ABOUT THE ORGANIZATION OR SYSTEM BEFORE ATTACKING"
If you carry out this part without obtaining the “real” IP address of the target, you can choose to send an email to the company. For example, you might request some business-related information. Very often, we find mail servers that are badly configured at the root, where in the email header we can find the IP address of the outgoing mail connection.
Other times, we browse the company's website in search of a link to an intranet, extranet, customer area, HR or similar, which points to resources external to the hosting service; the typical application that runs on the company's server and not the webserver's front-end CMS.
To browse the website, we can either use a Spider like Burp Proxy or do it manually. Of course, we need to go through the robots.txt file and try a zone transfer with this HackerTarget tool, for example.
Once we have found the IP address of the “main head office” or the main data line, we can use the WHOIS service that we mentioned before to detect entire sets of addresses leased by the company. Usually, medium-sized companies have a lot (I repeat, a lot) of public IP addresses, and they tend to “protect” the main ones, the ones that have most exposure and the services that run on them.
Another important aspect when working on the initial reconnaissance phase is to look into the company's defensive capabilities. Performing tests on a highly secure environment isn't the same as testing a company that we know in advance does not have any security mechanisms.
What if we have to tackle a moderately secure environment?
In a moderately secure environment, with web firewalls and intrusion detection/prevention systems, we have to be very careful when it comes to performing web application tests, port scans, brute force attacks, and so on. The systems are sure to detect the “noise” we make and will put themselves into defensive mode, so it can pay to do a little research when defining our attack processes.
For example, we can use a browser on the Tor network and send queries from a malicious user-agent like Nikto, Openvas, or similar. We can carry out a basic XSS/SQLi attack, run a standard port scan, try brute force against uncontrolled services, and send 10 queries per second.
"WE HAVE TO TRY TO ENTER BY ALL POSSIBLE MEANS"
Depending on the results, we can configure the tools we use to provide, more or less, deep evasion. Remember that evasion tasks tend to have a time cost, and a slow scan from the Tor network – which is already slow as it is – can take up a lot of the project's hours.
As auditors, we want to “enter the castle” any way we can. Generally, the castle will have a wall, a good gate and a good front-end defense, so if it isn't possible to enter through the front door, we will have to work out how to breach this defense by attacking on all fronts. We have to try all means possible, including going around the door, making a tunnel, entering through a window …
This is the wrong way of thinking because an attacker in a faraway country, who is not looking to attack one specific organization but rather to find one that is attackable, does not distinguish between an IP address ending in 103, 104, or 105 …
My recommendation is to attack or audit the entire set. The Black Box audit process requires approval by the customer, as we said before. We are not attacking a partner or provider without permission.
In the next article in the series, we will talk more about these “tricks” or approaches in another of the phases of a penetration test or pentest.
