Planning

Now that we have a general understanding of our scope in the code base, we can start the next step of whitebox pentesting, Local Testing. We will begin by setting up the web application locally for our testing. We will then test the function we shortlisted to determine whether it is vulnerable and can be exploited.

---

Setting Up Local Environment

The backend replication process, or setting up the web application locally, varies from one whitebox pentest to another, depending on the web application.

As previously discussed, this may be prepared by the organization that hired us, like providing a VM or a docker container, as demonstrated in other HackTheBox Academy modules. For this module, we will assume the case in which we are provided only with the source code, instructions to get it running locally, and the fact that the backend server runs on a Debian-based Linux Distribution. Sometimes, we may not have instructions on replicating the backend, so we may need to reverse engineer that, but this is not the case here.

To get our web application running, we need to run the archive we downloaded in the previous sections with the npm install command, as follows:

[!bash!]$ cd ./intro_to_whitebox_pentesting
[!bash!]$ npm install

This web application is relatively small, so installing its packages takes only a few seconds. Once that's done, we can get it running with npm run dev, as follows:

[!bash!]$ npm run dev

> [email protected] dev
> nodemon src/app.js

[nodemon] 3.0.1
[nodemon] to restart at any time, enter `rs`
[nodemon] watching path(s): *.*
[nodemon] watching extensions: js,mjs,cjs,json
[nodemon] starting `node src/app.js`
⚡️[server]: Server is running at http://localhost:5000
⚡️[api]: APIs are running at http://localhost:5000/api

The package.json file contains all the necessary details on what packages need to be installed and which commands need to be executed to run the web application, and the above commands use this file to work. We can confirm that the application is running correctly by trying to get an authentication token.

We have already discussed the getUserToken function in the previous sections, so we know that we need to send a POST request to /api/auth/authenticate with a JSON body containing email data, which we can do using curl, as follows:

[!bash!]$ curl -s -X POST -H "Content-Type: application/json" -d '{"email": "[email protected]"}' http://localhost:5000/api/auth/authenticate
{"token":"eyJhbGciOiJIU...SNIP...KmC7FqcwI4JOLiiI6aaN_feUY"}

As we can see, we successfully obtained an authentication token, so the application is running as expected.

---

Checking for Public Vulnerabilities

Before we move on to testing the function we have shortlisted, now is a good time to look for public vulnerabilities found in any of the packages that the web application relies on, as these may also be another way to exploit the application. This can be easily done with the npm audit command, as follows:

[!bash!]$ npm audit
found 0 vulnerabilities

We see that it found no vulnerabilities. This may change as the installed packages age, so we must monitor and update the packages. Now, let's move on with our testing.

---

Running validateString

We can start testing and debugging our target function validateString. Let's start by testing the basic functionality of the /api/service/generate API endpoint, which we can also do with curl, though we need to provide the previously obtained token, as follows:

[!bash!]$ curl -s -X POST -H "Content-Type: application/json" -H "Authorization: Bearer <token>" -d '{"text": "this is a test"}' http://localhost:5000/api/service/generate
<img src="data:image/png;base64,iVBORw0KGgo...SNIP...5ErkJggg==" alt="QR Code" />

As we can see, our request successfully obtained the QR code, which is returned to us as a base64 encoded image.

---

Debugging validateString

As we have successfully retrieved the QR code output, we can safely assume that the generateQR ran successfully and that the validateString function returned true, indicating that the text string we passed was valid and safe. We can confirm this by setting a breakpoint within validateString, and the application should break when we send the above request again.

To do so, we first need to run the application in debug mode. The archive contains a .vscode directory with all the details required to run the application in debug mode. So, all we need to do is go to the Run and Debug tab in VSCode and then click on the Run icon next to Launch Program, as follows:

When the application runs in debug mode, the bottom bar should turn red to indicate that. Now, we can go back to the controllers/service-controllers.js file and add a breakpoint to line 4 by clicking on the line by using the [SHIFT+F9] shortcut. A red dot will appear next to it, indicating an enabled breakpoint. Then, all we need to do is re-send the previous request, and the application should break at that point (if our request reaches this line):

As we can see, the application hit the breakpoint. We can also see all the variables under the VARIABLES pane on the left. This confirms our previous understanding of the function, and will be an essential method to determine how our input looks at that point of execution and how other variables are affected by our input.

Before we move to testing whether the function is vulnerable to injection, we will need to take a quick refresher on code injections, especially eval injection, and then will continue our testing.