Antique writeup HTB


An easy machine on an old printer server with a known exploit followed by another known exploit on a website running locally on the server.



Telnet is a protocol like SSH, except it doesn’t encrypt the data from the server to the client. Trying to connect to telnet gives us this banner :

HP JetDirect is a technology that allows printers to be directly connected to a local area network (googled it), and it’s configuration can be made through telnet. Searching HP JetDirect telnet exploit leads to a lot of interesting results.

A path traversal/Arbitrary code execution vulnerability is available, so let’s get to it.


Shell as lp

Unfortunately, the arbitrary code execution vulnerability above didn’t work for me (both the exploitDB version and the Metasploit version). As this server is really old, I’ll keep digging to find any other exploits that have already been found. Eventually, I find this article on hacking network printers : (read the article for a better explanation of the exploit)

To sum it up, the passwords for the HP JetDirect printers are stored and can be accessed with SNMP (Simple Network Management Protocol). For access, we need the SNMP community name (a collection of managers and agents). Since most people leave theirs as “public”, we can try to read the password using that community name. Using any tool that monitors networks using SNMP, we can send a specific request to the printer and have it leak its password in a hex-encoded format :

Using a hex-decode tool (I found a website instead) :

The password is leaked! We can now log into the printer server :

It looks like we can execute commands by typing exec <command> :

Since our options are still somewhat limited on this server, let’s initiate a reverse shell for better maneuvering : 

(Start the listener before executing the command, and the payload can be pretty much any reverse shell payload)

Now that we have a more comfortable setup, it’s time to climb our way to root.

Privilege escalation

I’ll be honest, this privilege escalation was a little tricky for me. Goes to show how important it is to not overlook anything while doing these kinds of challenges. There is a python script is the home directory named which imitates telnet that we can modify. If even a process with a UID of 0 (which is root) is executing this script, it first runs sudo -u lp, which technically means it’s running as lp. So that’s a no go there. At first glance, Linpeas didn’t show anything interesting either. It was later that I realized I overlooked something on my first scans :

Something is running locally on the machine on port 631. I can get an idea of what that is with netcat, which is installed on the target machine :

It’s a web server (running CUPS/1.6)! We can’t really do any more exploring like this, since the server is running on the localhost of the target machine. If we want to see what this website looks like, we’ll have to forward the local connection back on our machine. Chisel is a tool that does exactly this. We start a chisel server on our machine which will receive the connection and we execute chisel in client mode on the target machine to forward it : 

On our machine, listening on port 8000
On the target machine (upload the chisel binary)

Now we can access the website locally on our machine, using the port we specified the connection to forward to (mine here is 9002, but any port above 1024 works I think) :

The server is CUPS, and it’s running on version 1.6.1. The first result of my google search is a root file read vulnerability. There is also a RCE (Remote Command Execution) exploit but it didn’t work for me. For some reason, the Metasploit exploit also didn’t work for me (says my session isn’t compatible or whatever), so I’ll have to go manual on this one.

CUPS lets users in the lpadmin group (which we are in) modify certain parts of the server configuration. One of these is the error log path. When somebody visits the error log page on the website, like this :

The error log path gets printed to us. Apparently, the process (or whatever thingy is executing it) runs with the setuid of root, meaning we can grab important files that belong to root like /etc/shadow or the root flag. Since we can modify the path of the error log, let’s change it to root’s flag. Then, we can retrieve the new path printed on the error log page using curl :

Since I’m lazy and spent way too much time on the privilege escalation, I’ll cash in the flag and be on my way. However, having access to the /etc/shadow file might lead to root’s password if it’s weak enough (bruteforce password with the /etc/shadow and the /etc/passwd file as well as the John the ripper tool?).