Summary
While blackbox pentesting closely resembles how attackers exploit targets, whitebox penetration tests enable a more thorough way of testing. This can disclose vulnerabilities well before any attackers find them or even disclose vulnerabilities that may otherwise be impossible to identify. This module covers the process of whitebox pentesting and follows that with a practical demo by exploiting an advanced code injection vulnerability.
The Intro to Whitebox Pentesting module will cover the following process:
-
Code Review -
Local Testing -
Proof of Concept -
Patching & Remediation
Each step will be detailed in its own section. Then, the demo will demonstrate how to carry out each of these steps.
For Advanced Code Injection, the module will cover the following:
-
Code Review- Reviewing a NodeJS JavaScript code base
- Understanding the authentication mechanism of the application
- Reviewing the remaining functions to identify and prioritize potentially vulnerable functions
-
Local Testing- Setting up a local testing environment to dynamically test the target application
- Debugging different functions to understand how they work thoroughly
- Planning the attack vector
- Landing our user input in the target function
- Preparing advanced injection payloads
- Reaching basic code injection
-
Proof of Concept- Turning code injection into command execution
- Writing NodeJS web shells
- Advanced blind output exfiltration
- Injecting the output into HTTP responses
- Use time-based attacks to receive commands output
-
Patching & Remediation- How to avoid introducing injection vulnerabilities
- How to patch existing vulnerabilities through the use of safer alternatives or external packages
The module is packed with exercises, challenges, extra questions, further reading, and hands-on labs to help you practice the different techniques we will cover. It also includes a practical hands-on skills assessment to gauge your understanding of the various topic areas.
To know more about this module before starting it, we recommend watching this talk from the module author at the HackTheBox University CTF 2023 titled Advanced Code Injection. It goes through one of the sections at the end of this module and explains how to exfiltrate command output in extreme edge cases.
As a "Hard" module, it requires knowledge of reviewing code bases, understanding their different functionalities, and a good grasp of JavaScript. It also requires intermediate-advanced web application pentesting skills.
The following modules are also considered as pre-requisites before starting this module:
- Introduction to Python 3
- Command Injections
Intro to Whitebox Pentesting
As penetration testers, it is vital that we fully utilize all resources at hand to identify potential issues and flaws in any given application. Sometimes, a client may provide partial/full access to their source code so we can review it and find potential coding issues. We may also be given a replica of their backend server in a test environment to thoroughly test our findings in an environment that best matches the real target environment.
Furthermore, many vulnerabilities and attacks may lead to information or source code disclosure, like LFI, XXE, or even exposed development environments (e.g. Git Repository or Dockerfile). If this is the case, we can do our best to replicate that target's backend environment, including the type of OS, database, installed libraries and packages, firewall and security configurations, and anything else that may affect how the application runs or our attack vector. Doing so may not always be easy, but if we review the source code, especially if we have an exposed development environment, we may be able to replicate it closely, enabling us to perform whitebox pentesting on these applications.
This section will cover what whitebox pentesting is and how it can benefit us as penetration testers.
What is Whitebox Pentesting
Where a blackbox penetration test (pentest) usually means approaching the target as attackers would (i.e. with only publicly accessible information), a whitebox pentest means having partial/full access and knowledge about the target. A whitebox pentest starts with us having access to the development environment and user access with various roles, including ones with admin and root privileges. Most importantly, a whitebox pentest usually provides access to the application's source code, which allows us to closely examine how an application works and where its flaws may reside, which may uncover many unforeseen vulnerabilities.
The following are some of the assets provided at a whitebox pentest:
- Full Source Code of the target "full application or certain functionality."
- Access to the backend server
- Access to the DB
- Access to server logs
- Access with all/most user roles/privileges
- Access to the documentation
We may not "and should not" be given access to the production servers, but instead should have access to a replica server that closely matches the production server to avoid causing any disruption to the production environment. In some cases, the security measures active on the systems (e.g. Web Application Firewall or Anti-Virus) may be lowered to increase the chances of identifying and exploiting vulnerabilities. However, when we want to test any identified vulnerabilities on an actual production target, they would not be disabled, so we would need to bypass them to prove the exploitability of the target. Otherwise, it may not be remotely exploitable.
This level of visibility enables more thorough testing, which leads to multiple benefits, as we will discuss next. As we can imagine, all of this takes a more significant effort and may take much longer to complete, which is why this level of testing is usually only done on critical and sensitive systems and applications, like banking systems, governmental internet-facing applications, and other similar applications that organizations highly values. Still, if we possess these skills, we can incorporate them into a company's development cycle, which leads to a more secure development flow and ensures vulnerabilities are identified and patched as early as possible.
Note: While whitebox pentesting can cover all parts of a pentest, in this module, we will be focusing on web application whitebox pentesting, so we will not cover any points related to scanning networks or other non-application related sides of pentesting. Having said that, the overall concepts are largely similar, regardless of the phase of pentest we are at.
Benefits of Whitebox Pentesting
When we compare whitebox pentesting to a traditional blackbox pentest, we can see multiple benefits not found with a blackbox-only approach. First, due to our knowledge and transparency about the target, this usually leads to more findings that we may otherwise miss during a blackbox pentest. This also includes vulnerabilities that are difficult "or even impossible" to identify without direct access to the source code and the backend server, as they may occur in ways that are impossible to identify through blind testing. All of this allows us to identify and patch critical vulnerabilities before the attackers do, which is the whole point of a penetration test.
Another important aspect is how well a whitebox pentest fits in an applications development cycle (e.g. DevOps). Since we would be working on a test server and will be studying the source code, we can gradually test the application's different functions as they get built and developed, and will not need to wait for the entire application to be ready for use, since the developers will likely also have their testing server that we can utilize as well. This allows us to identify and patch vulnerabilities before an application 'or some of its functions' go into production and avoid major redesign delays that some types of patches require.
As a whitebox pentest usually requires studying and understanding an application's source code and its design, this allows us to suggest direct and clear instructions on how to patch the identified vulnerabilities since we would have a good understanding of the application and would be in an excellent position to know how to rectify the identified issues.
Also, we often see many vulnerabilities that only receive partial/temporary patches to prevent a specific direct threat without significant changes to the application's design. As whitebox pentesters, we would be able to suggest patches that fix the source of the vulnerability, which should prevent similar vulnerabilities from arising in the future. For example, suppose an application suffers from an SQL injection. In that case, we can suggest fixes that prevent injections throughout the application rather than simply fixing that one user input that leads to an SQL injection, thus fixing the root of the issue rather than a single symptom.
Why Do We Need Blackbox Then?
It is important to remember that a whitebox pentest can never be enough on its own, as it tests the application from a developer's mindset and not from a pure attacker's mindset, as the blackbox approach. This can (and likely will) lead to overlooking certain vulnerabilities that may not be visible through studying the source code. This is why it is essential to carry out both tests, though the blackbox pentest can start later in the development cycle. Likewise, a blackbox pentest is not enough on its own, as certain types of vulnerabilities may be difficult/impossible to identify through a blackbox-only approach.
In addition to the above, a whitebox pentest can be very time-consuming, especially for applications with large code bases, so it's usually only performed for critical systems. This makes blackbox pentests the default type for many applications that may not qualify for this level of testing. Hence, it is essential to learn good techniques to quickly review code and identify the most interesting functions, as we will discuss later in the module, which may enable whitebox pentesting for other non-sensitive applications.
Furthermore, whitebox pentests are generally harder to carry and require more advanced knowledge than a traditional blackbox pentest. This is due to whitebox pentests requiring skills in understanding an application's design, how it works, and how to identify hard-to-find flaws. It also requires the ability to read and understand an application's source code, which requires a good grasp of different programming languages.
In a whitebox pentest, we will usually not be looking for basic vulnerabilities, as we will likely be dealing with critical applications, and a blackbox pentest would easily identify such vulnerabilities. This also means performing a whitebox pentest requires knowledge of more advanced vulnerabilities and their causes in code. All of this helps us understand why whitebox pentesting is considered an advanced skill in pentesting.
Now that we have a good understanding of what whitebox pentesting is, in the next section, we will go through the process we will be following when performing whitebox pentests.
