digitalworld.local: FALL靶场

digitalworld.local: FALL

来自 < digitalworld.local: FALL ~ VulnHub>

1，将两台虚拟机网络连接都改为NAT模式

2，攻击机上做namp局域网扫描发现靶机

nmap -sn 192.168.23.0/24

那么攻击机IP为192.168.23.182，靶场IP192.168.23.4

3，对靶机进行端口服务探测

nmap -sV -T4 -p- -A 192.168.23.4

|-----------|--------|-------------|------------------------|-----------------------------------------------------------------------------------------------|
| 端口/协议 | 状态 | 服务名称 | 版本/详细信息 | 备注 |
| 22/tcp | 开放 | SSH | OpenSSH 7.8 (协议 2.0) | 支持三种主机密钥类型：RSA(2048位)、ECDSA(256位)、ED25519(256位) |
| 80/tcp | 开放 | HTTP | Apache 2.4.39 (Fedora) | - 标题显示"Good Tech Inc's Fall Sales" - robots.txt含1个禁止条目使用OpenSSL 1.1.0i-fips模块 |
| 139/tcp | 开放 | NetBIOS-SSN | Samba smbd 3.X - 4.X | 工作组：SAMBA 系统时间显示为2025年（可能配置错误） |
| 443/tcp | 开放 | HTTPS | Apache 2.4.39 (Fedora) | - 使用自签名SSL证书(CN=localhost.localdomain) 证书有效期：2019-08-15至2020-08-19（已过期）检测到CMS Made Simple生成器 |
| 445/tcp | 开放 | NetBIOS-SSN | Samba smbd 4.8.10 | 工作组：SAMBA 计算机名：FALL |
| 3306/tcp | 开放 | MySQL | 未授权访问 | 可能存在安全风险 |
| 9090/tcp | 开放 | Cockpit Web | 版本162-188 | 强制HTTPS重定向未验证SSL证书有效性 |
| 111/tcp | 关闭 | rpcbind | - | 服务未运行 |
| 8000/tcp | 关闭 | HTTP-alt | - | 服务未运行 |
| 8080/tcp | 关闭 | HTTP-proxy | - | 服务未运行 |
| 8443/tcp | 关闭 | HTTPS-alt | - | 服务未运行 |

4，扫描一下smb服务

5，访问80端口存在的http服务

存在两个人名：qiu，patrick。再扫描爆破网站子目录

dirsearch -u http://192.168.23.4 -x 404,403

然后扫描识别网站指纹

whatweb -v http://192.168.23.4

访问扫描到的网站子目录

http://192.168.23.4/robots.txt

http://192.168.23.4/test.php

提示GET请求参数有问题，需要构造请求参数。模糊测试一下爆破出请求参数

ffuf -u http://192.168.23.4/test.php?FUZZ=../../../../../../etc/passwd -w /usr/share/wordlists/dirb/big.txt -fs 80

爆出来是file参数

http://192.168.23.4/test.php?file=../../../../../../etc/passwd

文件包含漏洞利用成功

在路径遍历（Path Traversal）攻击中，确定 ../ 的数量（即需要回溯多少层目录）是一个关键步骤，但具体数量取决于 目标应用的上下文路径 和 服务器的文件系统结构。以下是逐步分析：

1. 基本原理

../的作用：每个 ../ 表示向上一级目录。例如：
plaintext
/var/www/html/test.php # 当前文件路径
../../../../etc/passwd # 需要回溯 4 层到根目录，再进入 /etc/passwd
目标文件位置：假设目标文件是 /etc/passwd，位于系统的根目录下，你需要从当前路径回溯到根目录，再进入 /etc。

2. 为什么示例中使用6个../？

在示例命令中：

ffuf -u "http://192.168.23.4/test.php?FUZZ=../../../../../../etc/passwd" -w wordlist.txt -fs 80

使用 6 个 ../ 可能是基于以下假设：

默认 Web 目录结构：假设 test.php 位于类似 /var/www/html/ 的路径中。

/var/www/html/ 需要回溯 3 层到根目录：../../..
再附加 /etc/passwd，总共需要 3 + 1 = 4 个 ../（因为 /etc 在根目录下）。
但为什么示例用 6 个？ 可能是为了覆盖更深或更复杂的目录结构（如容器化环境、多层子目录）。

3. 如何科学确定../的数量？

方法 1：逐步测试不同层数

直接通过 ffuf 动态生成不同数量的../，观察响应差异：

# 生成 1-10 个 ../ 进行测试（FUZZ 替换为不同数量的 ../）
ffuf -u "http://192.168.23.4/test.php?FUZZ=etc/passwd" \
-w <(for i in {1..10}; do echo "../".repeat($i); done) \
-fs 80

解释：通过循环生成 1 到 10 个 ../，测试不同层数的有效性。

方法 2：观察错误响应

触发错误：如果使用的 ../ 不足，可能返回 404 Not Found 或空内容。
成功标志：如果成功读取 /etc/passwd，响应内容中会包含系统用户信息（如 root:x:0:0: 等字段）。

方法 3：结合已知路径推断

如果已知目标服务器的 Web 根目录（如 /var/www/html），计算到根目录需要多少层：
/var/www/html/ → 需要 3 个 ../ 到根目录
/opt/app/web/ → 需要 3 个 ../ 到根目录
在此基础上附加 /etc/passwd，共需要 3 + 1 = 4 个 ../。

4. 为什么有时需要更多../？

容器或虚拟环境：目标应用可能运行在嵌套目录中（如 Docker 容器、多层虚拟化）。
符号链接或重定向：服务器配置可能导致实际路径比预期更深。
冗余回溯：某些应用会过滤固定数量的 ../，冗余的 ../ 可以绕过过滤（如 ....// 或 ....\/）。

5. 自动化优化技巧

使用占位符模糊测试：直接让工具自动尝试不同层数：
# 使用 ffuf 的 "FUZZ" 占位符动态插入不同数量的 ../
ffuf -u "http://192.168.23.4/test.php?FUZZ=etc/passwd" -w <(printf "%s\n" "../" "../.." "../../.." "../../../.." etc.) -fs 80
结合响应长度过滤：通过 -fs 或 -fc 过滤掉固定长度的错误响应。

6. 其他注意事项

操作系统差异：

Linux：路径分隔符为 /，目标文件如 /etc/passwd。
Windows：路径分隔符为 \，可能需要 ..\ 或 URL 编码（如 ..%5c）。

编码绕过：

对 ../ 进行 URL 编码（如 %2e%2e%2f）或双重编码（如 %252e%252e%252f）。
使用非标准表示（如 ....//、..\/）。

WAF 绕过：

某些 Web 应用防火墙（WAF）会检测 ../，可尝试以下变种：
....//
..%252f
%2e%2e%2f

总结

核心逻辑 ：通过测试不同数量的 ../，找到能成功访问目标文件的最小层数。

推荐实践 ：使用 ffuf 动态生成层数，结合响应内容长度和关键词过滤结果。例如：
ffuf -u "http://192.168.23.4/test.php?FUZZ=etc/passwd" -w <(for i in {1..10}; do echo $(printf "../%.0s" {1..$ i}); done) -fs 80 -mr "root:x:0"