靶场通关16--victim1

靶机：Victim: 1（VulnHub，作者 iamv1nc3nt）

难度：Easy-Intermediate　类型：Web 文件泄漏 + WPA 抓包破解 + nohup SUID 提权

攻击机：Kali 192.168.236.145　靶机：192.168.236.144

一.信息搜集

先扫网段找存活主机：

bash 复制代码

sudo nmap -sn 192.168.236.0/24

.144 是本次的靶机。全端口扫描：

bash 复制代码

sudo nmap -T4 -p- 192.168.236.144

开放 22、80、8080、8999、9000。再对这几个端口做服务和系统识别：

bash 复制代码

sudo nmap -sC -sT -sV -O -p22,80,8080,8999,9000 192.168.236.144

端口	服务	说明
22	OpenSSH 7.6p1（Ubuntu）	后面拿到凭据后从这里进
80	Apache 2.4.29	首页返回 403/报错
8080	BusyBox httpd 1.13	默认 404
8999	WebFS 1.21	文件服务器，直接列目录
9000	PHP cli server（PHP 7.2.30）	Bolt CMS，报数据库驱动错误

一台机器上开了五个 HTTP 服务，大概率是作者故意堆出来的干扰项，需要逐个判断哪个是真正的入口。

二.逐个看 Web 服务：先排除三个干扰项

80 端口 ------ Apache 下挂的是 Joomla，但没装好：

text 复制代码

No configuration file found and no installation code available. Exiting...

这是 Joomla 缺少 configuration.php 时的典型报错，等于一个空壳，没有可利用的页面。

8080 端口 ------ BusyBox 自带的 httpd，根目录下没有 index：

text 复制代码

404 Not Found
The requested URL was not found

9000 端口 ------ Bolt CMS，同样装坏了：

text 复制代码

Uncaught Exception. Bolt Database driver error.
SQLite was selected as the database type, but the driver does not exist or is not loaded.
Please install the pdo_sqlite driver.

缺少 pdo_sqlite 扩展，站点起不来，也没有入口。

8999 端口 ------ 这个不一样。WebFS 是一个轻量级的 HTTP 文件服务器，配置不当就会把整个目录（包括源码和杂项文件）直接列出来：

列表里是完整的 WordPress 源码根目录（wp-admin、wp-content、wp-includes、index.php 等），而最扎眼的是根目录下多了一个 WPA-01.cap（197 KB）。WordPress 源码本身没给什么可用信息，但这个抓包文件明显不属于网站，先下载下来。

三.从 WPA 抓包里破出 WiFi 口令

WPA-01.cap 是 802.11 的抓包文件，用 Wireshark 打开，可以看到大量 802.11 管理帧和 Probe Response，SSID 是 dlink：

也就是说这份抓包里很可能包含了 WPA/WPA2 的四次握手（EAPOL），可以拿字典做离线爆破。aircrack-ng 就是干这个的：它读取 cap 文件里的握手，把字典里的候选口令逐个代入 PBKDF2 计算，比对握手校验值，命中即为真实 WiFi 密码。因为是离线计算，速度取决于握手是否完整和机器性能：

bash 复制代码

aircrack-ng -w /usr/share/wordlists/rockyou.txt WPA-01.cap

跑了一小会儿就命中：

text 复制代码

KEY FOUND! [ p4ssword ]

SSID 是 dlink，密码是 p4ssword。靶机 22 端口开着 SSH，而很多人会把 WiFi 密码和系统密码设成同一个，于是拿 dlink:p4ssword 去试 SSH ------ 密码复用，直接登上去了。

四.SSH 登录

bash 复制代码

ssh dlink@192.168.236.144
# password: p4ssword

登录成功后拿到的是普通用户 dlink 的 shell（主机名 victim01），接下来做本地枚举找提权点。

五.nohup 的 SUID 提权

先列 SUID 文件：

bash 复制代码

find / -perm -u=s -type f 2>/dev/null

结果里大多数是系统自带的正常 SUID（su、mount、passwd、ping 等），但有一个不该出现的：/usr/bin/nohup。

nohup 的正常用途是让命令忽略 SIGHUP，在退出 SSH 后继续运行，它本身不需要 root。这里被加上了 SUID 位，就意味着执行 nohup 时进程的有效用户会变成 root；而 nohup 会去 exec 我们指定的程序，如果指定的是 sh -p，shell 因为 -p 参数不会丢弃权限，有效 UID 保持 0，就得到了 root shell。这也是 GTFOBins 上 nohup 的经典利用：

bash 复制代码

nohup /bin/sh -p -c '/bin/sh -p </dev/tty >/dev/tty 2>/dev/tty'

这条命令拆开看：

nohup /bin/sh -p：借 nohup 的 SUID 身份启动一个保留权限（-p）的 sh；
-c '...'：nohup 默认会把 stdin 丢掉、把 stdout 重定向到 nohup.out，所以要在里面再起一个 sh -p，把标准输入、输出、错误都接回当前终端 /dev/tty，否则拿到的 shell 没法交互；
外层进程退出后，内层 shell 依然挂在终端上，于是提示符变成 #。

执行后验证身份：

bash 复制代码

whoami
# root

（截图里第一次把 whoami 打成了 whami，提示 not found，重敲一次就是 root 了。）

拿到 root 后进入 /root 读取最终 flag：

bash 复制代码

cd /root
ls
cat flag.txt

六.小结

这台机器的思路和常见 Web 靶场不太一样：真正的漏洞不在 WordPress，而在"把不该公开的文件放进了公开目录"。一个 WiFi 抓包文件泄漏了内部口令，口令又被复用到系统账号上；提权则完全依赖一个多余的 SUID 位。加固上对应三点：关闭 WebFS 一类文件服务器的目录浏览、不要把抓包/备份等敏感文件放在 Web 根目录、清理不必要的 SUID（尤其是 nohup 这种根本不需要特权的程序）。