Markers Offsec Proving Grounds Practice Labor Day CTF Machine Walkthrough
I guess this is the hardest machine among Offsec PG CTF-200 Labor Day CTF machines. The first vulnerability is obvious, allows you to get a key, but you actually can’t use it for common purposes. Think twice about what you can do with the key. The RCE is a bit tricky I would say, the hint here is something to do with debugging. Check what you can do with the additional port found on the machine.
Enumeration
sudo nmap -p- $ip -Pn -vv -sS -A --open -T 4 -oN nmap-sS.txtOnly 22 and 3000 are open.
Port 3000
A markdown to PDF converter file. Markdown file is file with .md extension. We try to upload a .md file and get a PDF downloaded to our machine. From pdf title we found out is markdown-pdf 11.0.0.
Google “markdown-pdf 11.0.0 exploit” and found a potential Local file Read Vulnerability.
You can create a .md file with the payload or use burp to intercept the traffic and replace it with the payload. Here I will be using burp to intercept the traffic.
Click convert with burp intercept is on, replace the file content with the payload, and click forward. Let’s check the output pdf file.
Reading local file
We able to read local file. From the /etc/passwd file, we discover sau user. After checking around node.js config file but nothing much. We tried to get sau SSH private key at /home/sau/.ssh/id_rsa and we manage to get it. Copy the private key to a file and chmod 600 id_rsa. Make sure the id_rsa format is copied correctly. As per below.
However, when we tried to SSH but failed to do so. 😭
Checking the /etc/passwd file, we found that sau user has /usr/sbin/nologin means can’t SSH in. Hence we can’t get an SSH session.
💡 The
/usr/sbin/nologinis a shell or executable that is typically used as the login shell for user accounts where login access is not allowed. When a user has/usr/sbin/nologinset as their shell, they are effectively prevented from logging into the system. If they try to log in, they will receive a message indicating that login is not allowed for that account.
What next ? 🤔
Let’s review what we have now.
- We have an SSH key
- The ability to read local file
- A HTTP server running on port 3000 with node Express
The website seems nothing much even though we did URL enumeration, from the /etc/passwd only has root and sau user, both has nologin set. Seems like SSH to the target machine is not the way.
With read-local file capability, what else can we read? credentials, SSH key, config file, does not seem to work here. Upload a pdf with an embedded script to get RCE? Does not have any indicator showing we can execute the command to download files from our Kali machine. If you found a way to do this please leave a comment below how you do it.
For the SSH private key, we can do a port-forwarding via SSH which turns the target machine into a SOCKS proxy server. By connecting to the proxy, we can scan local ports on the target machine.
SSH Dynamic Port Forwarding
#create a dynamic port forward, at kali machine run this.
ssh -q -i id_rsa -N -D 127.0.0.1:1080 sau@192.168.227.34
#edit proxychains4.conf, you can use any text editor you prefer
sudo echo 'socks5 127.0.0.1 1080' >> /etc/proxychains4.conf💡-i: tell the SSH to use private key for authentication.
-N: tell SSH that no remote commands will be execute as sau has nologin configured.
-q: quiet mode, only showing critical info or error message.
-D: Dynamic Port forwarding, create a SOCKS proxy server on local machine. It forwards outgoing connection from local machine(which is our kali machine) through the target machine. The 127.0.0.1:1080 refers to our kali localhost and local port.
😄If you need a diagram to help you better understand how Dynamic Port Forward check this , or video check this
You can use netstat -tulnp to check if local port 1080 is listening. Once ready, we can continue our journey.
Nmap with proxychain
#start nmap scan with proxychain, -q is for quiet mode
proxychain -q nmap -p- -T 4 127.0.0.1 -oN nmap_localhost.txt❗️ The mistake I made here was scanning the target IP 192.168.177.34 instead of 127.0.0.1. There is a difference here where some ports might be accessible locally ONLY. Scanning 192.168.177.34 will get a different result from scanning 127.0.0.1. As we are connecting to proxy, scanning 127.0.0.1 is scanning the target machine’s local ports.
As using proxychain to do nmap scan will take a longer time, you can consider using nmap --top-ports 1000 to scan the most common port. However not the case here. It took me 3 hours ++ to complete a full port scan. To save your time, here is the result. You can just scan these 3 ports to get the result you need.
I do recommend you try scanning to familiarize yourself with the command and output without waiting for it to complete, then only scan the services on these specific ports.
Ports 1313
From the nmap result, we discover port 1313, by further scanning the services on the port. Seems like nothing much. At first we google “bmc patrol db” and seems to be irrelevant as it is for Oracle ( looks so strange 😵).
We also notice a 400 bad request from nmap result where it expect a websockets request to connect/talk to port 1313. Hence I decide to try connect port 1313 via websocket.
💡WebSockets provide a bidirectional communication protocol over a single, long-lived connection, enhancing real-time data exchange between a web browser and a server. Unlike traditional HTTP requests, WebSockets enable efficient and low-latency communication, making them ideal for interactive and dynamic web applications, chat applications, online gaming, and other scenarios where real-time updates are crucial.
Testing Websocket
Google “websocket exploit” we found this useful page.
Go through the page, I try connecting using websocat ( if you curious I am using websocat.x86_64-unknown-linux-musl ) and it does not work. I also tried another tool wscat however still does not work. I wondering if it is proxychain connection issue or if this is not the way to connect to websocket. If you know why please leave a comment down below will be much appreciate ❤️
Somehow it’s there
On websocat github page, we notice we can use Chromium to establish a remote debug connection to get the ws URL. So we can connect using websocat… I guess ? But the configuration looks strange to me. chromium --remote-debugging-port=9222
💡You can install chromium via sudo apt install chromium
Our port 9222 is nothing, we want to connect to port 1313 instead, but there is no need to input target IP, like 127.0.0.1:1313. If we try to run via proxychain chromium --remote-debugging-port=1313 it returns a bunch of errors and cannot start chromium.
Chromium Remote Debugging
I google “Chromium remote debug” and discover this. We need to do a port forward from kali machine to the target machine.
#stop the previous SSH Dynamic port forward and start an individual port forward
ssh -q -i id_rsa -L 9222:localhost:1313 sau@192.168.177.34 -N💡 -L: local port forwarding, allows you to forward a port from our local machine to a remote machine. The parameter is [our LocalPort]:[RemoteHost]:[RemotePort]
There is a difference between -R and -L where -R is for remote port forwarding, forwarding from the remote machine to your machine.
Once port forward is established, we try again with chromium remote debugging. It should auto-open chromium. At the URL tab, enter chrome://inspect/
chromium --remote-debugging-port=9222🎓
chrome://inspect/is a URL within the Google Chrome browser that provides access to the Chrome DevTools for inspecting and debugging web pages running on various devices or emulators. This is a useful tool for developers to analyze and troubleshoot web applications on different platforms.
We discover a target /opt/src/apps.js, click on the inspect button, it should pop out DevTools windows.
By looking at the code, it seems to be the website running on port 3000. We can conclude that port 1313 allows us to have debug mode access to the node express web application.
The exploit part 🔫
Google “chromium remote debug exploit” and found a page from hacktricks.
Going through the page, we can get a NodeJS RCE via node inspector. It also mentioned NodeJS RCE exploits won’t work if connected via Chromium devtools. Hence we will connect using node inspector instead.
To install nodejs, you can just type node and hit enter, it will tell you nodejs is not installed and ask if you want to install it, press Y and hit enter. Else you can
sudo apt install nodejs
Once installed nodejs on kali, we can connect using node inspector.
#at kali machine, ensure the SSH port forward is running
node inspect 127.0.0.1:9222
We then enter the payload.
#at kali machine, another terminal
nc -nlvp 3000
#at debug terminal
Enter the payload, medium don't allow me to paste the payload ='(
Check the screenshot below, the payload can copy from the hacktricks page.
Great! We can confirm an RCE here. Time to get our reverse shell.
After a few tries, below reverse shell payload works for me.
Don’t worry, you can get the reverse shell payload from revshells.com. The one works for me is nc mkfifo.
And here we go, get our root flag and sau flag!
Thank you for reading! If you found value in this post and want to delve deeper into the world of cybersecurity, I invite you to subscribe to my Medium page. Click 👉here👈 to subscribe.
By subscribing, you’ll get regular updates on CTF strategies, OSCP preparation tips, and the latest in cyber security trends.
Your support means everything. Subscribe ➡️now ⬅️and let’s embark on this cyber journey together!
🚀 Got a burning topic in mind? Stuck on a CTF machine? Can’t find the walkthrough? Drop it in the comments below 👇! Whether it’s the latest CTF challenge, a tricky OSCP concept, or anything cybersecurity that gets your gears turning — we want to hear it. Let’s make our next posts as awesome as your ideas. Can’t wait to see what you’ve got in store for us! 🎉👾
Follow me on X:
