Previous
Assess and validate your security with PurpleSec’s penetration testing services.
Author: Eva Georgieva / Last Updated: 11/02/2022
Reviewed By: Michael Swanagan, CISSP, CISA, CISM & Seth Kimmel, OSCP
View Our: Editorial Process
Table Of Contents
You may need to conduct a white box penetration test if you want to evaluate your application security, wireless security, infrastructure, network security, or physical security in an assumed breach scenario. During an assumed breach test, the goal is to test what the impact would be if an attacker successfully achieved initial access and if they are capable of causing the distribution of services or accessing the organization’s “crown jewels.”
What You’ll Learn
White box penetration testing approach, also known as an assumed breach, clear box, or transparent box testing, is where the penetration tester has full access and complete knowledge of the target that is being tested and its features. This includes source code, credentials, whitelisting, multiple account roles with different access levels, access to the documentation.
This type of pen testing is also called pen testing from a developer perspective and works on discovering the most effective way to break the target by examining the application, service or system in question from the inside.
This specific approach enables the uncovering of vulnerabilities in the logic flow of an application, which sometimes outside attacks or automated tools might miss.
The main point with this type of testing is that anytime a product is developed and accessible over a computer network it needs thorough testing to ensure that a third-party or anyone without proper access might exploit that product’s features for their own advantage or profit.
This test still mimics the activities of a malicious hacker, but with more access to the system’s information than an outside attacker would have.
Knowing when to execute a white box pentest and establishing whether your organization needs one is essential and should mostly be performed at an early stage of development before the software is launched and before it goes into production.
The rule of thumb is that the more critical your application is, the more thorough your test should be, meaning the better it is to perform a white box penetration test on it.
Such examples might include white box testing a bank application, where the primary focus and testing scope should be to find parts of the data that handle the sensitive customer’s data, how the storage of data is handled, the database security and ensure that the security controls there are at their finest.
However, it is worth noting that sometimes just a white box penetration test is not enough and depending on the type and scope of the application, system or service that you want to test it is best to use this type of testing together with other forms of security assessments.
There are a number of advantages and disadvantages to performing a white box penetration test including:
The main advantage of a white box penetration testing approach is that the penetration testers have information for the application from the point of view of development and can conduct deep and thorough tests. In addition, a white box approach maximizes the use of the time spent testing and the testing coverage is much more comprehensive.
A white box approach also ends up revealing way more security vulnerabilities than a black box approach and is involved in strengthening security by improving the design and usability.
In addition, you can also correct poorly structured paths in the development process.
Finally, a white box approach is a much faster process since the security assessor is already familiar with the application map and its features and can dedicate more time testing the critical parts of the target.
Overall, this technique showcases a proactive approach toward security that puts an emphasis on the prevention and minimization of the risk associated with security.
The main disadvantage of a white box pen test is that it can be time-consuming since there is much more information and knowledge at hand. The scope of the project can also be quite complex and expensive.
In addition, a white box approach is not quite realistic, since a malicious attacker wouldn’t have all the information that the penetration tester has and wouldn’t attack the application in the same way and manner.
This means a completely different approach to attacking the application will be used.
The steps of performing a white box pen test include:
This stage of the penetration testing process focuses on gathering information about the target system.
Usually, this is executed with meetings with developers where the application, its features, and functionalities are elaborated.
Credentials and source code are provided and the logic flow of the application is elaborated.
Most of the information does not come from outside sources rather than from the product owner itself.
In this stage of the penetration test, more information is gathered but through different techniques, regardless of the information already gathered from the initial planning phase.
The penetration tester looks for more information by scanning for vulnerabilities utilizing tools like Nmap.
The scan would usually produce information like the version of the operating system, the type of running software and check for vulnerable versions of the software that is running by enumerating all the services and subdomains.
Having in mind the information gathered so far through the different techniques, the penetration tester should now look for publicly known vulnerabilities and attack entry vectors that would be a possible way into the target.
This may include but is not limited to known CVEs in the system, vulnerable versions, or third-party applications used by the target.
In this phase of the penetration testing engagement, the penetration tester already noted several possible exploitable vulnerabilities gathered through automated scanning and manual research.
Depending on the scope of the project, the tester will deploy methods to exploit the discovered security vulnerabilities.
Each exploit requires different knowledge and most likely different tools that the penetration tester would use.
The goal is to penetrate the system and obtain initial access or gather some sort of sensitive information from the system that is being exploited.
After that for each vulnerability found the penetration tester creates proof of concepts to prove that the vulnerabilities discovered are actually exploitable and present a security risk.
However, even though the stages here are quite similar in its essence to other types of penetration tests, if looking at them in a more detailed manner they would come down to these steps:
Some common white box techniques during a penetration testing engagement could be the following:
A full port scan of the target is usually part of the penetration tester methodology since identifying open ports might expose and lead to information that could lead to different vulnerabilities or exploitation vectors.
The scan covers 1000 of the most popular UDP ports and the entire 65,535 TCP ports.
Fuzzing, or sometimes referred to as fuzz tests, is a process of automatically testing applications, specifically input fields for missing input checks.
The fuzzer provides a lot of invalid or random inputs in the program that the application might not expect or is not designed to handle.
Fuzzing attempts to detect:
Secure code review, if executed in a pentest, represents an automated process that examines an application’s source code with the goal to identify any existing security flaws or vulnerabilities.
When a penetration tester performs a secure code review they specifically look for logic errors, and possible security vulnerabilities due to how the code is implemented.
Eva is a security engineer, researcher, and penetration tester with over 5 years of experience working on both red teams and blue teams.
Recent Articles
Categories
Policy Templates
Most Popular