Other Labs¶

OS Injection¶

This lab contains an OS command injection vulnerability in the product stock checker.
The application executes a shell command containing user-supplied product and store IDs, and returns the raw output from the command in its response.
To solve the lab, execute the whoami command to determine the name of the current user.

We visit the website and randomly visit a product page to see where the vulnerable function is.
Below, we can see that there is a "Check stock" button and we attempt to try the function out while intercepting it with burp suite.
From the request below, we can see that "Check stock" will send a POST request and the POST request will contain the parameters.
It seems like storeId can be manipulated.

Hence we try to see if we can elicit a command by doing a ls command
From the above response, it seems like we are able to inject command into the query.
We try again by reading stockreport.sh and it seems to be the sh file that is running the backend for the stock query.
This confirms that using | will allow us to run commands.
Hence, we do a | whoami to solve the lab.

This lab contains a file path traversal vulnerability in the display of product images.
To solve the lab, retrieve the contents of the /etc/passwd file.

We are brought to the webpage below
We then navigate to view details of a random product
We viewed the page source and realised that the image is querying the webserver for a file 6.jpg.

We try to query the file directly by using the "Open Image in New Tab"
True enough, we see that the image appears, seems like ?filename=6.jpg does a file read operation.
Using burp repeater, we intercept a request with ../../../../etc/passwd parameter and look out for the response.
As can be seen above, in the response captured, the /etc/passwd of the host is read.

This online shop has a live chat feature implemented using WebSockets. Chat messages that you submit are viewed by a support agent in real time.
To solve the lab, use a WebSocket message to trigger an alert() popup in the support agent's browser.
Web socket exploitation is further mentioned here

We access the lab website and on the top right hand corner we see "Live chat"
We visit the "Live chat" page and below is the page in question.
We inspect the page source to see the element responsible for the interactive chat below.
As can be seen, wss://0ae600df04a148c4c08ec9a400e00087.web-security-academy.net/chat is used. wss suggests the use of websockets.
This is further confirmed with Websockets History on burp suite
We then continued on to inspect resources/js/chat.js which gives us the javascript responsible for displaying and sending the message.
In the function above, we can see that there is another function writeMessage() that is called which we can see what it does below.
The writeMessage() function takes in 3 parameters, className, user and content.
As message content is the only thing we can manipulate, our focus will be on lines that contains variables content and contentCell.
document.createElement("td"), contentCell.innerHTML = content and row.appendChild(contentCell) will create HTML element <td>content</td> and append it in row so that messages will appear like below.
The send message function below. We notice that there is a foreach loop that places data into an object[] array and does the function htmlEncode().
htmlEncode seem to be an input santisation function, however, it does not seem to sanitise '(' and ')'.

Thus a payload that we can try is as below :
```
<img src=1 onerror='alert(1)'>
```
To bypass html encoding, we have to use burp repeater to change out the content below to our payload above.
After hitting the 'Send' button, we can see that alert() is successfully triggered.

This lab uses a serialization-based session mechanism and is vulnerable to privilege escalation as a result. To solve the lab, edit the serialized object in the session cookie to exploit this vulnerability and gain administrative privileges. Then, delete Carlos's account.
You can log in to your own account using the following credentials: wiener:peter
Insecure deserialisation is explained here and this explains how to test for and exploit insecure deserialisation.

We first visit the website and see that there is a "My account" tab. Where we find a login form.
We use the credentials provided and attempt to login. The intercepted POSt request is as such and in the Set-Cookie parameter, we see what looks like a base64 encoded string.
We decode the string to get what looks like a PHP serialisation format.

To get to the admin panel it seems like we simply need to change b:0 to b:1 as below and encode it in base64.
```
O:4:"User":2:{s:8:"username";s:6:"wiener";s:5:"admin";b:1;}7
```
The manipulation can be done by intercepting the GET request and modifying the cookie.
As can be seen below, the "Admin panel" tab is revealed.

This lab uses an OAuth service to allow users to log in with their social media account. Flawed validation by the client application makes it possible for an attacker to log in to other users' accounts without knowing their password.
To solve the lab, log in to Carlos's account. His email address is carlos@carlos-montoya.net. You can log in with your own social media account using the following credentials: wiener:peter.
More about OAuth can be found here and this will explain more about OAuth grant types. Information on OAuth implicit flow can be found here.

We first visit the website and we find a "My account" tab which leads to a "social media" sign in redirect.
Below is the redirected page and we subsequently went logged in with the credentials provided.
The requests were proxied and we investigated the exchanges using burp suite proxy HTTP history.

The interesting request will be the authenticate POST request that comes after the oauth-callback GET request.
The email parameter in the request above was changed to carlos@carlos-montoya.net and sent to repeater.
We get a 302 redirect which we right click and choose "request in browser".
Upon successful authentication, when we go to "My account" the GET request was to id=carlos.
We are logged in as Carlos.