User flag
Started by doing some nmap scans:
The only interesting port seems to be port 80, so lets enumerate it.
Found a statistics vhost but returning a 401 unauthorized http code:
Still, gonna add it to the /etc/hosts file. Going to this subdomain, we are asked for credentials:
The login form is simply sending the username and password, base64 encoded, in the authorization header:
I also did a dir scan on the page, but only got the expected results, except for a messages page:
This might be the page where the administrator sees the messages we sent by the contact form:
By going to this page we get a 200 http code, but the page is empty:
Finally, I also did a file inclusion scan to see if I could get any files returned, but got nothing.
Lets move on to the markdown viewer functionality. I recently done a box in htb were there also was a markdown viewer and there, I spent quite some time trying to do some XSS attacks (with no success). But since this box is called Alert, I immediately am thinking we can do some of those.
I created a markdown file with some simple XSS payloads:
Some markdown viewers also process html tags, so lets try it:
Success. So now for the exploitation:
We get a request back, but no cookie:
If we generate a valid md file:
We get a link to share the md file. We can check if sending this url through the contacts form, if the administrator clicks it.
This script will get the index page, convert it to text, then URI encode the text and send it to my nc listener. So lets see if we receive anything when we share the link with the administrator.
When we generate the md, we receive data and when we share it with the contacts page:
We receive it as well. So we can confirm that the administrator is clicking in the url that we sent him thought the contact form.
Now, lets remember that there was a messages page, that seemed that only the administrator could see. We can use this exploit to send the data of the messages page back to us.
We do the same process of sharing the md url and wait for the data:
By decoding the date we can see that there a link to a file in the messages.php page. Lets download it:
We do the same process and we get:
Humm, it seems that the file is empty? But if we can read this file maybe now we can do the file inclusion vulnerability.
We got it.
From the nmap scan we know that the webserver is an apache http server. So lets try to get some of its conf files:
We get the apache conf file and looking and the decode data we find:
We know that there is a statistics vhost, so lets get its conf:
We get no data. Lets try the default sites available apache naming:
We can see where the .htpasswd is stored. Lets get it:
We get a user and an hash. Time to crack it:
And we are in.
Still lets try to login to statistics subdomain:
And get a bunch of usernames, but probably not relevant:
We can ssh and get the flag:
Root Flag
We are in group management:
And there is only one file that belongs to this group:
Looking at the website monitor app, it seems that is supposed to take some metric from the previous webapps we interact at the beginning of the machine and save its results.
This seems to be the webapp running in the port 8080, so lets port foward to interact with it:
Looking for the process of the web-site monitor, we can notice that the inotify command is running with the dir that the group management owns.
The man for the command says that the command as the ability to execute a script every time it changes. So potentially whenever the /opt/website-monitor/config/configuration.php changes, that inotifywait command will execute it again.
Looking at the flags of the commands this seem exactly what is happening, so lets try changing the php file with a rev shell:
And as soon as we save the configuration file we get the shell:
And the root flag!