Intro to Whitebox Pentesting

Patching & Remediation

All of the efforts we have made so far were intended to identify previously unknown vulnerabilities and then patch them. So, this last step is critical, as our whitebox pentesting exercise would only be complete with it. We must end our whitebox pentesting exercise with a thorough review containing our findings and knowledge and, most importantly, detailed code patches to remediate the identified vulnerabilities.

Patching

Before writing our report, we should patch all identified vulnerabilities in our test environment. Since we have an excellent understanding of how each function works and how the vulnerability is occurring, it should be clear what we should change to prevent it. Of course, this can only be done where possible, as certain applications and vulnerabilities would make the patching very complicated and outside the scope of our testing.

We can apply these patches and then re-test our PoC exploit to ensure the application is no longer vulnerable. We must also go through the Local Testing process to ensure the vulnerability is remediated at every stage. If, at any stage, we notice that the vulnerability still exists (e.g. payload not being filtered properly), we should update our patches and start the testing again. Most importantly, we should ensure that our patches do not break any original functionality.

We have already established that the code reviewing and vulnerability analysis processes are different for each application, and so is the patching process. Throughout the various whitebox pentesting modules in HackTheBox Academy, including this one, we will provide different examples of patching and testing our code to ensure we deliver the best results.

Reporting

Like any other pentesting exercise, we end our pentest by writing a full report detailing the steps necessary for exploitation and how to use the PoC script. We should also include a detailed review of each function and point out any potential issues we identified. We should provide the code patches we tested with the exact details of what we modified so senior software engineers can review our changes and ensure they comply with their standards and do not break anything.

If we could patch the vulnerability and maintain the full functionality of the application, we can add a note saying that the patch has been verified as working. Patching certain major vulnerabilities may take more work as they affect multiple other functions. If this is the case, we can suggest a patch and note that it has not yet/fully been tested.

It is also recommended that we provide some secure coding tips to avoid introducing similar vulnerabilities in the future. These would be similar to the ones we provide in our various whitebox pentesting and secure coding modules. Of course, these tips would only be highlights, so software engineers are always recommended to learn secure coding directly, as that would be the best way to reduce the flaws and vulnerabilities in their applications.

Previous Next

Intro to Whitebox Pentesting

Patching & Remediation

Skills Assessment

Skills Assessment - Intro to Whitebox Pentesting

My Workstation

OFFLINE

/ 1 spawns left

Cheat Sheet

The cheat sheet is a useful command reference for this module.

The Whitebox Pentesting Process

Order	Step	Description
1.	`Code Review`	General review of the code to understand its functionality and shortlist potentially vulnerable functions
2.	`Local Testing`	Testing/Debugging the code locally to test our findings and identify vulnerabilities
3.	`Proof of Concept`	Writing an exploit to prove the exploitability of the target automatically
4.	`Patching & Remediation`	Patching the vulnerability and all of its sources/causes

Examples of Code Review Techniques

Select functions based on the application design.
Select functions and files through search.
Select functions through the use of the application.

Exploit Scripting Language Guide

Use Case	Recommended Language	Reason
Attack is on a network application (including web applications)	`Python`	It works similarly on most operating systems
Attacking a client-side function (e.g. a CSRF attack)	`JavaScript`	It is the only script executed by browsers
Web chain including a client-side attack	`Python` & `JavaScript`	We prepare a `JavaScript` payload for the client-side part. Then, use it with a `Python` script to trigger the exploit and carry on the rest of the back-end attacks.
Binary exploitation	`Python`	`Python` has good libraries for debugging and exploiting binaries, while `C`/`C++` may be used to develop a binary exploit.
Targeting an operating system	`Bash` or `PowerShell`/`CMD`	Whatever pre-installed scripting language on that operating system
Thick client or some advanced types of exploitation	The application's programming language	This would enable us to reuse code/functions to generate some payloads, which would save us a lot of time (vs re-scripting all of the logic in Python)

Code/Command Injection Functions

JavaScript 'NodeJS'	Python	PHP	C/C++	C#	Java
`eval`	`eval`	`eval`	execlp
`Function`	exec	exec	execvp
`setInterval`	subprocess.open	proc_open	ShellExecute
`setTimeout`	subprocess.run	popen
`constructor.constructor`	os.system	shell_exec
child_process.exec	os.popen	passthru	system	System.Diagnostics.Process.Start	Runtime.getRuntime().exec
child_process.spawn		system	popen

Payload Development Rules

Comment out the rest of the code
Ensure quotes/parentheses/curly braces are even
Maintain a working function without syntax errors

Methods for Obtaining Command Output

Log output to console "for local testing"
Use a reverse shell
Use DNS exfiltration (or ping exfiltration)
Store the output in the database
Write the output to a file, then access that file
Inject the output into the HTTP response
Use sleep timers or boolean output to read the content

Intro to Whitebox Pentesting

Patching & Remediation

Patching

Reporting

Table of Contents

Whitebox Pentesting Process

Code Review

Local Testing

Proof of Concept (PoC)

Patching & Remediation

Skills Assessment

My Workstation