When pentesting a web application, an API or an internal network, there are generally 3 approaches: black box, grey box and white box testing.
These approaches or test conditions correspond to different levels of information provided to the pentesters to identify potential vulnerabilities and weaknesses that could compromise the integrity of a target system.
While a black box pentest involves providing no specific data, during a white box penetration test, the pentesters will have the maximum amount of information at their disposal.
In this article, we will focus on white box penetration testing, presenting the principles and objectives of this offensive security approach as comprehensively as possible. Using concrete cases as a starting point, we will present the methodology of a white box penetration test and examples of vulnerabilities on various targets.
What is White Box Penetration Testing?
White box penetration testing is a security assessment method in which pentesters have complete knowledge of the infrastructure, the system and the source code.
White box penetration testing is a security assessment method in which pentesters have complete knowledge of the infrastructure, the system and the source code.
Pentesters use this information to identify more specific and complex vulnerabilities. This includes examining the source code and/or infrastructure for development errors and configuration flaws to ensure that the target system is robust against attacks.
The aim of a white box pentest is therefore to identify vulnerabilities that would not necessarily be obvious without in-depth knowledge of the system, and to propose recommendations for strengthening security.
This method is also particularly effective for examining code quality. Furthermore, it saves the pentesters an enormous amount of time and provides a more exhaustive view of the security posture.
Preparing for a White Box Penetration Test
Preparing for a white box penetration test is an essential phase that requires meticulous attention to detail and good planning.
This phase begins with exhaustive information gathering. It is crucial to obtain full details of the system architecture, including network diagrams, server configurations, databases and the applications involved.
Access to the source code is also vital, as it enables an in-depth analysis of possible vulnerabilities and programming errors.
In addition, gathering relevant technical documentation, such as design specifications and security policies, helps to understand the internal structure and requirements of the system.
Once the necessary information has been gathered, the next step is to define the specific objectives of the pentest. This involves determining the critical components of the system that require particular attention and setting precise objectives for the assessment, such as identifying vulnerabilities, assessing resistance to attacks, or validating existing security controls.
What are the Different Phases of a White box Pentest?
A white box pentest is a structured process that takes place in several phases. Each phase plays a key role in the complete assessment of the system’s security.
Static code analysis
This initial phase focuses on examining the source code. Static analysis enables potential vulnerabilities to be identified without executing the code.
Pentesters examine the code to detect vulnerabilities such as SQL injections, XSS and broken access control.
This involves the use of automated tools and manual review to understand how the code works and spot security flaws.
Static analysis tools enable the auditor to be more efficient in his search for vulnerabilities.
These include Semgrep, which identifies security problems in source code.
By examining the code of a login form, for example, a pentester can identify flaws where the code does not filter user input correctly, leaving the door open to an SQL injection attack.
This analysis is crucial because it enables security problems to be detected before the application goes live.
Thanks to this detection, the auditor is able to test the vulnerability on the web application to prove its presence.
<?php
$servername = "localhost";
$username = "username";
$password = "password";
$dbname = "myDatabase";
// Connecting to the database
$conn = new mysqli($servername, $username, $password, $dbname);
// Connection check
if ($conn->connect_error) {
die("Connection failed: " . $conn->connect_error);
}
// Retrieving data from the form
$user = $_POST['username'];
$pass = $_POST['password'];
// Vulnerable SQL query
$sql = "SELECT * FROM users WHERE username = '$user' AND password = '$pass'";
$result = $conn->query($sql);
if ($result->num_rows > 0) {
// User found
echo "Successful connection";
} else {
// User not found
echo "Incorrect username or password";
}
$conn->close();
?>Dynamic analysis and pentesting
Unlike static analysis, dynamic analysis involves interacting with the application or system as it runs.
This stage enables vulnerabilities that are only apparent when the code is being executed to be identified.
Pentesters simulate realistic attacks to test the system’s responsiveness to intrusions, for example by assessing its ability to handle user input correctly or to maintain data integrity.
This stage is performed at the same time as an in-depth code reading to quickly determine where the code is vulnerable.
Listing of vulnerabilities and weaknesses
After the static and dynamic analysis, the pentesters compile a list of the vulnerabilities detected.
This list includes not only technical flaws and logical vulnerabilities, but also weaknesses in procedures and the overall architecture.
Each vulnerability is assessed in terms of severity, impact and ease of exploitation, and then reported in the pentest report.
White Box Penetration Testing of a Web Application With Access to an AWS Infrastructure
To illustrate white box testing of a web application, let’s take a concrete example where a customer provides us with the full domain name (FQDN): “pentest.vaadata.com”.
During the target reconnaissance phase, a DNS resolution reveals the use of CloudFront.
CloudFront is a Content Delivery Network (CDN) offered by Amazon Web Services (AWS). It acts as an intermediary layer between end users and the server where the web application resides. This type of tool speeds up the delivery of web content by distributing it from locations that are geographically close to the user.
The value of CloudFront lies not only in optimising the speed of access to content, but also in the security.
By masking the real IP address of the origin servers, CloudFront helps protect web applications against attacks such as DDoS (Distributed Denial of Service).
Nevertheless, during a white box pentest, obtaining the direct IP address of the server on which the application is hosted can be crucial.
By accessing the server directly, it is possible to bypass the protections offered by CloudFront, such as IP masking and attack mitigation, enabling an exhaustive assessment of the web application’s security.
AWS infrastructure analysis
This specific role allows us to analyze in detail the resources and configurations implemented within their cloud environment.
One of the things we discovered was that the customer had deployed an EC2 (Amazon Elastic Compute Cloud) instance to host their web application.
One of the first steps in the audit is to identify the real IP address of the EC2 instance. This information is important because it enables CloudFront to be bypassed, should the security configuration allow this.
Indeed, accessing the EC2 instance directly can reveal vulnerabilities that would otherwise be masked by intermediate content distribution layers such as CloudFront.
In addition, analysis of the AWS infrastructure revealed the use of an S3 bucket, named “web-storage-aws”.
S3 buckets are frequently used to store static web resources such as images, CSS style sheets and JavaScript scripts.
The configuration and security policies applied to this S3 bucket are therefore key elements to be audited. Improper configuration can expose these resources to unauthorised access or data leakage, compromising the security of the entire web application.
Identifying security misconfigurations
As part of our white box penetration test, we examined the permissions attached to this specific S3 bucket via the “Permissions” tab in the AWS console.
We found that the bucket is configured with an access policy that allows anyone to download the files it contains.
This configuration opens the door to the direct downloading of files by anyone who knows the precise path to the file, even though the directory listing is not activated.
This restriction prevents anyone from knowing the names of the folders and files in the bucket, adding a layer of security through obscurity.
Discovering sensitive files
Our white box analysis revealed the existence of a backup file located at the following address: backup/2024-02-22/website/.env.backup
This discovery highlights the importance of precisely knowing the paths to the files stored in the S3 bucket, because without this knowledge, access to the files would be much more difficult.
By comparison, in a black box audit context where the auditor has no access to internal configurations or access policies, discovering this file path would potentially have required a brute force attack, systematically testing various file paths to identify accessible resources.
This method is not only time-consuming but also less effective, increasing the risk of detection by traffic monitoring mechanisms:
It is also plausible to imagine static assets such as images and JavaScript files being stored in the same “website” folder.
Given that these resources are often referenced directly in the source code of the web application, an attacker could extrapolate the access paths to these files.
However, discovering the specific “.env.backup file”, which potentially contains sensitive information, would require precise knowledge or assumption of the access path.
The “.env.backup” file can be downloaded from the “website” folder.
This file turned out to contain AWS authorisation keys, a crucial element for the rest of our investigation.
Testing the validity of AWS access keys
To test the validity of these keys, we used the AWS CLI, a tool for interacting with AWS services directly from the terminal.
Using a specific command, we were able to list the user associated with these keys, revealing that they were valid and belonged to the web-deploy user.
Exploring further via the AWS interface, we quickly examined the policies attached to the web-deploy user. This user was associated with the secret-manager-viewer policy, a policy that allows all secrets present in the AWS account to be listed and their contents read.
This access capability is particularly sensitive because it can reveal critical information which, in the wrong hands, could compromise the security of the entire AWS infrastructure.
We listed the available secrets and discovered a secret called personal-db. This secret, apparently disconnected from the web application, seemed to be linked to a personal database.
The fact that we were able to discover and access this type of information highlights the importance of restricting permissions on an AWS account.
The credentials of this personal database were accessible due to excessively broad permissions assigned to the web-deploy user.
Pentesting Report’s Remediation Recommendations
Considering the vulnerabilities and misconfigurations discovered during our pentest, several fixes are needed to strengthen the security of the customer’s AWS infrastructure.
- Firstly, it is crucial to review and restrict the permissions granted to users, particularly those relating to the
web-deployuser. Applying the principle of least privilege, providing only the access strictly necessary for specific tasks, will significantly reduce the risk of data leaks or other security breaches. - Next, it is advisable to implement a stricter secret management strategy. Authorisation keys and database identifiers should not be stored in publicly accessible files, such as
.env.backup. The use of tools such as AWS Secrets Manager to securely manage this sensitive information is highly recommended. These tools offer automatic secret rotation and policy-based access features, thereby strengthening data security. - In addition, it is imperative to reconfigure the policies applied to S3 buckets to prevent unauthorised downloading of files. This includes implementing bucket policies that restrict access to specific files and folders, as well as using public listing blocking features to prevent disclosure of the structure of stored directories and files.
White Box Penetration Testing of a Web Application With Access to the Source Code
In this second example, examining the source code of a web application gives us a valuable window into its design and security.
From the very first lines, we can see that the application uses Flask, a micro-framework written in Python and designed for web development.
Flask is renowned for its simplicity and flexibility, but like any tool, its use can introduce vulnerabilities if best security practices are not followed.
One detail revealed by the code analysis is that the Flask server is run in Debug mode. Enabling Debug mode in a production environment is a highly risky practice for several reasons.
Firstly, this mode provides detailed error information, including stack traces and application configurations, which can be exploited by malicious actors to discover vulnerabilities or flaws in the code.
Secondly, Debug mode can sometimes allow arbitrary code to be executed if the debug interface is accessible (/console), providing a potential attack vector for executing malicious code on the server.
Analysing source code, especially when it is composed of thousands of lines, can be a complex process. However, it is essential for identifying insecure development practices and potentially vulnerable configurations.
Extracting the Web app’s routes
As part of our security audit, a key step is to extract and examine the web application’s routes.
In Flask, each route is defined with an @app.route decorator, making it easy to identify the various entry points to the application.
By developing a bash script capable of going through the source code to extract these routes, along with the associated request method (GET, POST, …) and the associated path, we can obtain a complete overview of the application’s endpoints.
This exhaustive list of routes allows us to carry out targeted tests on all endpoints, ensuring that nothing is overlooked during the audit.
Testing each endpoint individually helps to identify specific vulnerabilities, such as SQL injections, XSS flaws or configuration issues, which might otherwise go unnoticed.
The presence of the /api/v1/template/edit route in the web application, which allows a Jinja2 template to be modified and its contents returned, reveals a critical vulnerability.
This functionality, which retrieves the value of the content parameter to process it, might seem harmless at first glance.
However, the code reveals the use of the render_template_string method, which returns the value of our content parameter in the server response.
The security problem here is linked to template injection (SSTI).
Exploiting a Server-Side Template Injection (SSTI) vulnerability
Jinja2 template injection is a serious vulnerability because it can allow arbitrary code to be executed on the server.
Jinja2 is a powerful template engine that provides the ability to execute Python code within templates.
When a user can control the content of a template, as is the case with the content parameter, they can potentially insert malicious code that will be executed by the server when the template is rendered.
The fact that the simple multiplication tested returns 49 indicates that the template engine is processing and executing the contents of the content parameter, thus confirming that the template is being processed.
This ability to remotely execute code on the server via template injection opens the door to several attack techniques, ranging from the disclosure of sensitive information to the execution of arbitrary commands on the server.
Attackers can exploit this vulnerability to access environment variables, read files on the server, or even execute malicious code, thereby compromising the security of the application and its data.
How to prevent this type of vulnerability?
We strongly recommend disabling Debug mode in production environments to prevent sensitive information from being disclosed.
It is also crucial to validate and clean all user input to prevent injections, particularly when using Jinja2 templates, to avoid arbitrary code execution.
White Box Penetration Testing of a PHP Application
As part of another white box pentest of a web application using PHP, we analysed a feature that acts as a proxy.
This functionality is designed to retrieve the content of specific pages on the “vaadata.com” site, using a url parameter to pass the desired URL to the server, which then makes the request.
Filtering is carried out using a regular expression (regex) to restrict requests to the “vaadata.com” domain only, to prevent malicious exploitation.
However, we have identified a critical error in this approach. The regex does not check for the presence of the slash (/) immediately after the domain name. This opens the door to Server-Side Request Forgery (SSRF) injection attacks.
Exploiting a Server-Side Request Forgery (SSRF) vulnerability
A SSRF vulnerability allows an attacker to send forged requests from the server to internal or external systems, thereby bypassing the security measures normally applied to requests from external sources.
This vulnerability can be exploited to access internal services that are not publicly exposed, as in the case of an internal service that discloses sensitive database credentials.
Normally protected and accessible only via a local request (127.0.0.1), this service can nevertheless be reached by an attacker exploiting the SSRF vulnerability discovered.
This vulnerability can be exploited in several ways. For example, an attacker could bypass the regex by using “vaadata.com” as a sub-domain of an FQDN pointing to localhost, or by passing “vaadata.com” as a basic authentication parameter in the request, thereby faking a legitimate internal request and accessing the /api/internal service.
Another method of exploiting the SSRF vulnerability in the PHP web application lies in the ability to initially make a request to an external server controlled by the attacker, and then redirect this request to the targeted internal service.
This technique is based on the activation of the CURLOPT_FOLLOWLOCATION option in the application code, which enables the server to automatically track HTTP redirections.
By exploiting this feature, an attacker can perform several requests where the last step consists of accessing a specific internal service, such as /api/internal, which discloses confidential information, and which was presumed to be secure and inaccessible from the outside.
Fixing the SSRF vulnerability
To address the SSRF vulnerabilities identified during the PHP web application audit, it is essential to strengthen the validation of user input, especially for functionality that handles URLs or external requests.
The use of strict whitelists for authorized domains and the application of more rigorous regexes to check the format and legitimacy of URLs can effectively prevent bypass attempts.
It is also important to review the configuration of outgoing HTTP requests made by the application. Disabling the CURLOPT_FOLLOWLOCATION option for cURL requests is recommended so that redirects are not automatically tracked.
White Box Penetration Testing of an Internal Network
As part of an internal network pentest, the white box methodology gives us a significant advantage by providing detailed information in advance, including a complete network diagram, access to several Active Directory accounts with different privilege levels, including a domain administrator account, as well as access to the customer’s different VLANs.
These elements form a solid basis for launching the audit, allowing us to delve deeper into our analysis without the obstacles usually encountered in black box or grey box.
Using an administrator account plays an important role in this audit, enabling us to examine the Active Directory configuration, including access control lists (ACLs), the privileges assigned to different users, scheduled tasks and authentication policies.
The aim is to detect improper configurations, excessive or inappropriate permissions, and potential vulnerabilities that could be exploited by attackers.
To facilitate this analysis, we use BloodHound, a tool that performs LDAP queries to map privilege flows and relationships within the Active Directory.
BloodHound generates interactive graphs to illustrate these relationships, providing improved clarity and understanding of the complex interdependencies and potential attack paths within the network environment.
This graphical representation is particularly useful for quickly identifying high-privilege accounts and group configurations that may pose security risks.
Carry out a White Box Penetration Test With Vaadata, a CREST, ISO 27001 and ISO 27701 Certified Company
White box penetration testing, whether it is web application pentest, API or network, is a fundamental process in securing systems.
Thanks to in-depth knowledge of a target system (architecture, source code, etc.), it can identify and correct vulnerabilities that might otherwise go undetected in black box or grey box.
This article highlights the key stages in a white box pentest, underlining the importance of static and dynamic analysis in identifying and exploiting vulnerabilities.
Additionally, the concrete examples provided illustrate the risks associated with insecure development practices. We can help you identify the vulnerabilities in your systems and assist you in fixing them.
Contact us to discuss your challenges and needs.
Authors: Alexis MARTIN – Pentester & Amin TRAORÉ – CMO @Vaadata