# Whats Your Name? {% embed url="" %} The following post by 0xb0b is licensed under [CC BY 4.0

](http://creativecommons.org/licenses/by/4.0/?ref=chooser-v1) *** ## Recon Scanning our target with Nmap we can discover three open ports, of which on each of them runs a different service. On Port 22 SSH, and on 80 a web server, and on 8080 also a web server. Both web servers are running Apache/2.4.41.

On the web server at port 80, we run a directory scan via Gobuster. We can see that we are probably dealing with PHP using PhpMyAdmin.

We move on with a manual inspection of the web server. Unfortunately, we only see a blank page on 8081.

The situation is different on port 80, where we see the announcement of a social network to be released soon.

We can register in advance, and our registration will be reviewed and activated by a moderator. We may have our entry point here. Furthermore, we have four input fields; maybe XSS is possible here. Further resources can be found here: {% embed url="" %}

Since we don't know what the moderator sees, we have to be able to somehow find out whether our XSS was successful or not. We test our XSS by making requests on our web server with them. So that we know which input field is vulnerable, we design our requests so that we can distinguish which payload was executed.

We make use of the following simple XSS payload: ```javascript ``` After submitting, we see the registration was successful, nice.

We set up a PHP server and wait a few seconds. ```bash sudo php -S 0.0.0.0:80 ``` After a short time, we see requests to our server. All input fields, except for the password field, have responded to our XSS attempt. Probably the password is not displayed to the moderator or is hashed, so we have no success here. We can therefore continue and create a payload that steals the moderator's session cookie, for example, to hijack his session so that we can use it to gain access to WorldWAP.

## Access To Moderator Account We prepare the following payload to retrieve the cookie of the moderator:\ Our PHP web server is still running in the background. ```javascript ``` We register a new user and place our payload in the email field.

AAfter a short time, we receive the request and get the session cookie encoded in base64.

We decode the transferred cookie...

...And replace our `PHPSESSID` cookie with the one we retrieved.

After reloading `worldwap.thm` we get redirected to the dashboard. There, we get information about a subdomain `login.worldwap.thm` which is now operational and working.

Adding that subdomain to our `/etc/hosts` and reaching out to it, we retrieve another blank page.

We could run now a Gobuster scan to enumerate directories or look into the source of the blank page, and find a note from the developer to implement a redirection to `login.php`.

With our session cookie set, we head to `http://login.worldwap.thm/login.php` and we get redirected to `http://login.worldwap.thm/profile.php`. We have access to the social network as the `moderator` and find the first flag in red in the header. It might be necessary to apply the retrieved session cookie also to the cookie of `login.worldwap.thm`.

## Access To Admin Account Looking further through the social network, we see that we are able to reset the password. Interesting. This could be exploited for a CSRF. Let's look further. Further resources can be found at: {% embed url="" %}

Furthermore, we have a chat, among others, with the administrator of the page.

Let's see if we are able to inject some XSS to make use of CSRF. Placing the following simple payload: ```javascript ```

We see it gets evaluated.

Inspecting the pages further we do not find any mitigations like CSRF tokens used to mitigate CSRF. Ok, let's clear all chats and make a password change request to get an idea how to craft a payload that forces the admin to reset his password. For this, we use Burp Suite, and we see that a `POST` request is required with `new_password` as data to be transmitted.

We craft a script that creates and submits a form to change the password to "hello" when the page loads. We make use of hidden form fields to post data without user interaction. If that script gets planted in the chat and the admin visits the chat, the admin will automatically request a password change. ```javascript ``` Unfortunately, it did not work right away. Looking at the source, we see that the HTTP URL we submit gets automatically formatted to ``.