Meow

One open port, Telnet, and root with no password. Trivial to own, but worth dwelling on *why* a passwordless root login is even reachable - it is a PAM nullok plus securetty story, not a Telnet one.

Meow is the first HackTheBox Starting Point box: a single service, no exploitation, root in two commands. The lesson is not the foothold, it is the misconfiguration behind it. A passwordless root login is not something Telnet does to you - it is something three separate defaults have to agree to let happen. This write-up spends its length on that chain, because it is the same chain that shows up on real IoT and appliance targets.

Path to root, at a glance:

nmap -> one port, 23/tcp Telnet.
telnet in, user root, empty password -> session as root.
Read flag.txt.

Recon - nmap

┌──(r3vpwnx㉿r3vpwnx)-[~/CTF/HTB/Meow]
└─$ sudo nmap -Pn -A 10.129.118.250
Starting Nmap 7.99 ( https://nmap.org ) at 2021-09-30 15:09 -0400
Nmap scan report for 10.129.118.250
Host is up (0.61s latency).
Not shown: 999 closed tcp ports (reset)
PORT   STATE SERVICE VERSION
23/tcp open  telnet  Linux telnetd
Device type: general purpose|router
Running: Linux 4.X|5.X, MikroTik RouterOS 7.X
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

-Pn because HTB blocks ICMP and I do not want host discovery to drop the target; -A for version/OS so I know what telnetd I am talking to. One port. When a box exposes exactly one service, that service is the box - there is no lateral surface to map, so the entire question is what that one daemon will hand me.

Telnet in 2021 is already the finding. It is cleartext end to end (credentials included), but more to the point, a host still running telnetd is a host whose configuration has not been touched in a long time - which is exactly the kind of host that still carries shipping defaults.

┌──(r3vpwnx㉿r3vpwnx)-[~/CTF/HTB/Meow]
└─$ telnet 10.129.118.250
Trying 10.129.118.250...
Connected to 10.129.118.250.
Escape character is '^]'.
root

Username root, password left blank (the prompt that follows is a root shell). No brute force, no second factor, no su. That is the whole foothold - and the interesting part is why the system said yes.

Why this is even possible

telnetd itself does not authenticate anyone. On a login connection it execs /bin/login, and login defers the actual decision to PAM (/etc/pam.d/login). Three defaults have to line up for a blank root password to be accepted:

nullok on the auth module. The password stack typically ends in a line like auth [success=1 default=ignore] pam_unix.so nullok. That nullok is the switch: it tells pam_unix to accept an empty password field as a valid empty password rather than refusing it. With it present and root’s hash set to empty in /etc/shadow, no password is the right password.
An empty root hash. grep ^root /etc/shadow on this box shows root::... - the hash field is blank, meaning no password was ever set. nullok is only reachable because of this.
securetty permits it. pam_securetty restricts where root may log in to the tty list in /etc/securetty. Historically this blocked network root logins; here the pseudo-tty Telnet hands out is allowed (or securetty is not enforced on this path), so the network login is not vetoed.

Remove any one of the three - drop nullok, set a root password, or keep root out of securetty - and the box no longer gives up a shell. That is the real takeaway: “Telnet let me in as root” is shorthand for “the PAM auth stack was left permissive and root had no password.”

Root - the flag

Already root, so there is no privesc step; just locate and read the flag.

root@Meow:~# ls -al
total 36
drwx------  5 root root 4096 Jun 18  2021 .
drwxr-xr-x 20 root root 4096 Jul  7  2021 ..
lrwxrwxrwx  1 root root    9 Jun  4  2021 .bash_history -> /dev/null
-rw-r--r--  1 root root 3132 Oct  6  2020 .bashrc
drwx------  2 root root 4096 Apr 21  2021 .cache
-rw-r--r--  1 root root   33 Jun 17  2021 flag.txt
drwxr-xr-x  3 root root 4096 Apr 21  2021 .local
-rw-r--r--  1 root root  161 Dec  5  2019 .profile
-rw-r--r--  1 root root   75 Mar 26  2021 .selected_editor
drwxr-xr-x  3 root root 4096 Apr 21  2021 snap
root@Meow:~# cat flag.txt
[flag redacted]

Detection and hardening

Worth noting what this looks like from the defensive side, because the fix is trivial and the detection is cheap:

Kill the protocol. Disable telnetd and use SSH with key auth. Cleartext credential protocols have no place on a reachable interface.
Never ship an empty root hash. passwd -S root should never report NP (no password). Lock direct root login (PermitRootLogin no on the SSH side; - out of securetty on the console side) and work through an unprivileged account with sudo.
Audit nullok. A blank password is only acceptable anywhere if a PAM line explicitly allows it; grep your pam.d stack for nullok and remove it.
Blue team: a successful root login over 23/tcp is a single-line alert - watch auth.log for login: ROOT LOGIN on 'pts/0' paired with any connection to the Telnet port.

Lessons