Launching HTB CWEE: Certified Web Exploitation Expert Learn More

Intro to Whitebox Pentesting

Whitebox penetration testing enables thorough testing to identify various hard-to-find vulnerabilities. This module covers the process of whitebox pentesting and follows that with a practical demo by exploiting an advanced code injection vulnerability.

4.78

Created by 21y4d

Hard Offensive

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:

  1. Code Review
  2. Local Testing
  3. Proof of Concept
  4. 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
    1. Reviewing a NodeJS JavaScript code base
    2. Understanding the authentication mechanism of the application
    3. Reviewing the remaining functions to identify and prioritize potentially vulnerable functions
  • Local Testing
    1. Setting up a local testing environment to dynamically test the target application
    2. Debugging different functions to understand how they work thoroughly
    3. Planning the attack vector
    4. Landing our user input in the target function
    5. Preparing advanced injection payloads
    6. Reaching basic code injection
  • Proof of Concept
    1. Turning code injection into command execution
    2. Writing NodeJS web shells
    3. Advanced blind output exfiltration
    4. Injecting the output into HTTP responses
    5. Use time-based attacks to receive commands output
  • Patching & Remediation
    1. How to avoid introducing injection vulnerabilities
    2. 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.

Sign Up / Log In to Unlock the Module

Please Sign Up or Log In to unlock the module and access the rest of the sections.

Relevant Paths

This module progresses you towards the following Paths

Senior Web Penetration Tester

The Senior Web Penetration Tester Job Role Path is designed for individuals who aim to develop skills in identifying advanced and hard-to-find web vulnerabilities using both black box and white box techniques. This path encompasses advanced-level training in web security, web penetration testing, and secure coding concepts. It also provides a deep understanding of the application debugging, source code review, and custom exploit development aspects of web security. Equipped with the necessary theoretical background, multiple practical exercises, and a proven methodology for web vulnerability identification, students will eventually be capable of performing professional security assessments against modern and highly secure web applications, as well as effectively reporting vulnerabilities found in code or arising from logical errors.

Hard Path Sections 245 Sections
Required: 7500
Reward: +1500
Path Modules
Medium
Path Sections 15 Sections
Reward: +100
This module covers three injection attacks: XPath injection, LDAP injection, and HTML injection in PDF generation libraries. While XPath and LDAP injection vulnerabilities can lead to authentication bypasses and data exfiltration, HTML injection in PDF generation libraries can lead to Server-Side Request Forgery (SSRF), Local File Inclusion (LFI), and other common web vulnerabilities. We will cover how to identify, exploit, and prevent each of these injection attacks.
Medium
Path Sections 12 Sections
Reward: +100
In this module, we will look at exploiting NoSQL injection vulnerabilities, specifically MongoDB, with examples in Python, PHP, and Node.JS.
Medium
Path Sections 20 Sections
Reward: +100 NEW
Authentication plays an essential role in almost every web application. If a vulnerability arises in the application's authentication mechanism, it could result in unauthorized access, data loss, or potentially even remote code execution, depending on the application's functionality. This module will provide an overview of various access control methods, such as JWT, OAuth, and SAML, and potential attacks against each.
Medium
Path Sections 17 Sections
Reward: +100
Modern web browsers and applications utilize a variety of security measures to protect against CSRF and XSS vulnerabilities, rendering their exploitation more difficult. This module focuses on exploiting advanced CSRF and XSS vulnerabilities, identifying and bypassing weak and wrongly implemented defensive mechanisms.
Medium
Path Sections 15 Sections
Reward: +100
This module covers details on Transport Layer Security (TLS) and how it helps to make HTTP secure with the widely used HTTPS. That includes how TLS works, how TLS sessions are established, common TLS misconfigurations, as well as famous attacks on TLS. We will discuss how to identify, exploit, and prevent TLS attacks.
Hard
Path Sections 20 Sections
Reward: +100
This module covers three common HTTP vulnerabilities: Web Cache Poisoning, Host Header Vulnerabilities, and Session Puzzling or Session Variable Overloading. These vulnerabilities can arise on the HTTP level due to web server misconfigurations, other systems that have to be considered during real-world deployment such as web caches, or coding mistakes in the web application. We will cover how to identify, exploit, and prevent each of these vulnerabilities.
Hard
Path Sections 18 Sections
Reward: +100
This module covers three HTTP vulnerabilities: CRLF Injection, HTTP Request Smuggling, and HTTP/2 Downgrading. These vulnerabilities can arise on the HTTP level in real-world deployment settings utilizing intermediary systems such as reverse proxies in front of the web server. We will cover how to identify, exploit, and prevent each of these vulnerabilities.
Hard
Path Sections 16 Sections
Reward: +100
In this module, we cover blind SQL injection attacks and MSSQL-specific attacks.
Hard
Path Sections 18 Sections
Reward: +100
Whitebox penetration testing enables thorough testing to identify various hard-to-find vulnerabilities. This module covers the process of whitebox pentesting and follows that with a practical demo by exploiting an advanced code injection vulnerability.
Hard
Path Sections 18 Sections
Reward: +100
This module covers advanced web concepts and exploitation techniques, including performing DNS Rebinding to bypass faulty SSRF filters and the Same-Origin Policy, identifying and exploiting Second-Order vulnerabilities, and conducting common web attacks via WebSocket connections.
Hard
Path Sections 15 Sections
Reward: +100
In this module, we will explore deserialization attacks with specific examples in Python and PHP.
Hard
Path Sections 15 Sections
Reward: +100
This module explores several web vulnerabilities from a whitebox approach: Prototype Pollution, Timing Attacks & Race Conditions, and those arising from Type Juggling. We will discuss how to identify, exploit, and prevent each vulnerability.
Hard
Path Sections 12 Sections
Reward: +100
This module covers advanced SQL injection techniques with a focus on white-box testing, Java/Spring and PostgreSQL.
Hard
Path Sections 13 Sections
Reward: +100
This module focuses on developing custom exploits for .NET deserialization vulnerabilities from a whitebox perspective.
Hard
Path Sections 21 Sections
Reward: +100
This 'secure coding' module teaches how to identify logic bugs through code review and analysis, and covers three types of logic bugs caused by user input manipulation.