Grey Box Application Testing: What It Is and Why You Need It

Grey box pen testing is the best approach to ensure optimized app pen testing

Rodrigo Contarino

Offensive Security Managing Consultant

Mobile, web, and cloud-based solutions for online communications and other technologies proliferated after the pandemic, and the trend shows no signs of slowing down. Apps are omnipresent these days. Apple’s trademark phrase, “There’s an app for that,” has become more than a savvy marketing ploy—it’s today’s reality. To ensure that your applications minimize critical security risks, you need to test your applications for vulnerabilities and remediate them.

According to the Open Web Application Security Project (OWASP), broken access control was the number one security risk to applications in 2021, accounting for a staggering 94% of occurrences. Most web applications are easily accessible by design, making them prime targets for threat actors.

There are myriad different approaches you can take to application pen testing. However, we recommend you go with a full grey box approach if you are willing to share the source code. The security team at VerSprite encourages you to share the source code because by doing so, you combine both Dynamic and Static testing during the exercise. We also encourage you to share additional documentation about the environment and architecture of the application so that the pen testing team better understands the inner working of the app and how the different components work together. This increases the testing coverage because it concentrates on all the layers of the application.

Gray box testing is an application security approach combining white box and black box testing principles. In a white box assessment, the tester has full internal knowledge of the application being tested, such as source code, design, and credentials for authenticated testing. Alternatively, a black box assessment is performed without knowledge of the system’s internals and without access to the application. Black box testing evaluates your application in a scenario closest to a real-life attack.

Threat actors have unlimited time to research their intended targets in the real world. When they conduct the attack, they can test out different vectors and try different methods to access the application. Your security team doesn’t have this luxury, so sharing the source code is imperative. They are handicapped because they do not have time to analyze and research, unlike their black hat counterparts. Pen testers are hobbled by time constraints, so sharing the source code allows your grey box team to test the apps for security gaps and vulnerabilities more efficiently.

How Does Grey Box Testing Work? 

Application penetration testing, or app pen-testing, is a form in which ethical hackers apply general pen-testing principles and approaches to apps. This includes native apps built for phones, tablets, or other devices; however, web applications are the most common targets for app pen-testing.

The foundation of VerSprite’s penetration testing methodology is based on emulating realistic attacks by a malicious actor through PASTA (Process for Attack Simulation and Threat Analysis).

The most effective penetration tests don’t adhere to a strict set of steps—instead, the pen-testers should tailor the tests to address a company’s specific needs. For example, a healthcare company will have much stricter regulatory guidelines to which it must adhere. Therefore, using a stock template for pen testing may not address these standards.

Grey box testing analyzes code and identifies vulnerabilities. A grey box penetration test requires access to the different credentials that the app supports to cover all use cases. This approach to application testing ensures that unauthorized users cannot access another user’s data or escalate privileges.

Once the testing is done, the team reports to the client to strategize fixes. The PASTA methodology allows the client to prioritize the app remediation process so that they make the most crucial fixes first.

Grey Box Pen Tests: Real-Life Scenarios

Full grey box testing with the source code is more thorough than other types of testing because it focuses on identifying security bugs in the code itself while simultaneously testing the application. It doesn’t rely exclusively on user feedback or manual inspection; therefore, grey box pen testing effectively detects vulnerabilities and helps guide remediation efforts.

The examples below discuss real-life pen tests the VerSprite AppSec Team conducted for clients.

Client #1: OS Command Injection

Because grey box testing allows access to the source code, VerSprite’s pen testers can find a much more comprehensive range of vulnerabilities. This includes those more challenging to identify with dynamic testing that could be undetected during dynamic analysis.

In this case, we discovered an “OS command injection” issue, where we identified the affected parameter dynamically but could not determine the injection point. However, after examining the source code, we identified the entry point, saving us significant time in testing. Furthermore, accessing the source code allowed us to see the construction of the affected command in detail. After that, we quickly crafted a suitable payload for that specific parameter to exploit this issue.

This investigation saved hundreds or thousands of payload iterations that would’ve been sent to the application otherwise. It also ensured that the payload sent wouldn’t adversely affect the application or cause any Denial of Service (DoS) condition.

It is important to note that the team didn’t detect this issue during the original vulnerability scan. In this case, having access to the source code allowed us to quickly identify the root cause of the vulnerability and provide actionable recommendations for remediation.

In the following examples, we can see the original HTTP Request and the modified HTTP Request once we identified the injection point through source code analysis:

Original HTTP Request
POST /user/profile HTTP/1.1
Host: vulnerable.app
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:95.0) Gecko/20100101 Firefox/95.0
Accept: text/html,application/xhtml+xml
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Content-Type: application/x-www-form-urlencoded
Content-Length: 192
Origin: https://vulnerable.app
DNT: 1
Connection: close
Referer: https://vulnerable.app
Cookie: CAKEPHP=[...]

data%List%5D%5B5D=1&[...]

After examining the source code, we observed that the value submitted in the data[List] parameter was appended directly to the $appendStr variable, which was later used to build the shell command executed by shell_exec().

function [...]

$appendStr = '';

foreach ($requestedInfo as $sName => $value){
       $appendStr .= " " . $sName;
}

//Run the shell script to build the app bundle
$command = RUN_COMMAND_APP_BUILDER . $sBuildVersion . $appendStr;
$output = shell_exec($command . " 2>&1");
return $output;

}

Modified HTTP Request

POST /user/profile HTTP/1.1
Host: vulnerable.app
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:95.0) Gecko/20100101 Firefox/95.0
Accept: text/html,application/xhtml+xml
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Content-Type: application/x-www-form-urlencoded
Content-Length: 192
Origin: https://vulnerable.app
DNT: 1
Connection: close
Referer: https://vulnerable.app
Cookie: CAKEPHP=[...]

data%List%5D%5B<INJECTION POINT>%5D=1&[...]

Client #2: PHP Code Injection

In this case, we found a “PHP code injection” issue through a simple keyword search in the source code using “eval() .” Searching for these dangerous functions in the source code allowed us to identify a critical issue in less than 20 minutes.

It is worth noting that this issue could not be detected by any tool during dynamic testing, as the affected functionality was not in use from the user interface. However, after identifying the issue in the source code, we could trace its usage to a user-controlled parameter on an exposed API. By dynamically analyzing the application with the help of the source code, we could identify a critical issue that might have otherwise gone undetected, which could have resulted in severe consequences. Once we had this information, dynamically validating and exploiting the vuln was trivial, compromising the server and part of the cloud environment. This highlights the importance of conducting a comprehensive security assessment, including dynamic and static testing.

In the following excerpt, we can observe a PHP function named processDataFromRequest, which ingests data and executes it after performing several replacements using the eval() function.

function processDataFromRequest($requestData)
{
$resultData = array();
$updatedString = str_replace(",",";",$requestData);
$convertedCode = str_replace(":","=",$updatedString);
$convertedCode = str_replace ('data','$resultData',$convertedCode);
$convertedCode = str_replace ('[','["',$convertedCode);
$convertedCode = str_replace (']','"]',$convertedCode);
$finalCode =$convertedCode. ";" ;
eval ($finalCode);
return $resultData;
}
[...]

From this point, we were able to trace back the usage of this allocate_network function and find the only place where it’s used:

[...]
function allocate_network($id=0,$view='edit')

[...]
validateInfo($this,'/vulnerable/path/'.$id.'/'.$view);
$ndata = $_REQUEST['requestData'];
$id = $_REQUEST['id'];
$ajax_data = $this->Utilities->processDataFromRequest($requestData);

[...]

Within the code, we observed that the allocate_network function maps to an URL, where $id is the site identifier, and $view is the action to perform. Additionally, we can see that the $requestData parameter submitted to the processDataFromRequest function is user-supplied. Knowing this, we attempted to craft and access the URL through the application.

In layman’s terms, our grey box pen tests were able to find issues affecting the application by leveraging the source code provided that otherwise could have gone missing with typical black box dynamic testing. Our AppSec team reported these two critical findings related to input validation and worked with the clients to remediate them before the apps went live.

VerSprite’s comprehensive application pen testing approach leverages a risk-based threat model that goes beyond simply testing for OWASP Top 10 issues. PASTA methodology helps our team understand the context of the application within your business, which helps us determine the most critical attack patterns to exploit. The PASTA framework and the application source code optimizes application pen testing.

Want to know more? Check out this blog post.

PASTA Threat Modeling: The Process for Attack Simulation and Threat Analysis

VerSprite leverages our PASTA (Process for Attack Simulation and Threat Analysis) methodology to apply a risk-based approach to threat modeling. This methodology integrates business impact, inherent application risk, trust boundaries among application components, correlated threats, and attack patterns that exploit identified weaknesses from the threat modeling exercises.

Download the eBook →