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.

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.