Web侦察与目录爆破：从IIS默认页面到关键SQL注入漏洞的渗透测试实战

本文章仅用于网络安全研究学习，请勿使用相关技术进行违法犯罪活动。

声明：本文搬运自互联网，如您是原作者，请联系我们。

又一天，又一个目标

在参与HackerOne的私有项目时，这不过是寻常的一天。如同大多数经验丰富的安全研究员一样，我首先使用 Subfinder 等工具，并启用所有可用的API密钥进行子域名收集。通过 httpx-toolkit 识别出活跃主机后，我获得了一份目标清单。此前，我已向这家公司成功报告过两起SQL注入攻击漏洞。

一项“平淡”的发现成为转折点

在快速浏览了前三个子域名后，我返回列表寻找更富挑战性的目标。回顾之前对所有子域名截取的屏幕快照时，我发现其中两个子域名显示的是默认的IIS页面。

对于大多数安全测试人员而言，默认页面往往意味着“无聊”而被直接跳过。然而，我突然想起曾在某篇文章中读到过一句箴言：

“没有人会花钱去托管一个空白或默认页面。”

向那位前辈致敬！这句话在我脑海中回响，促使我决定对这两个目标进行深入调查。

第一步：短名称扫描与初始碰壁

在进行目录模糊测试之前，我首先运行了 IIS短名称扫描器。扫描结果显示存在漏洞，这让我兴奋不已，但紧随其后的困惑是：我知道它存在漏洞，却不知如何利用。

我开始使用各类字典进行模糊测试。数小时过去，一无所获。

在感到沮丧之际，我在X平台（原Twitter）上简单发帖求助：“接下来该怎么办？”，并附上了扫描结果截图。

一位同行研究员回复道：“试试用GitHub上 @orwagodfather 的字典进行模糊测试。”

我决定尝试。于是运行了以下ffuf命令：

ffuf -u "https://target.com/FUZZ" -ac -fs 0 -w <(curl -s "https://raw.githubusercontent.com/orwagodfather/WordList/refs/heads/main/iis.txt")

五分钟后，返回了一个 200 OK 状态码。

这并非一个普通的空白200页面，其响应内容长度有所不同。访问该端点后，原本“乏味”的默认IIS页面背后，竟隐藏着一个小型的功能性网站。真正的挑战开始了。

功能测试与思维转变

我点击了网站上的每一个链接、按钮，测试了所有可见功能，但未发现明显漏洞，网站看起来相当安全。随后，我回想起安全研究员HX007一次关于攻破IIS网站的演讲。我重新查阅他的幻灯片，直到抓住一个关键点：“如果常规模糊测试失败，请尝试添加以下扩展名进行测试：xml、zip、txt、json、js、obj、asmx、xsl、dll……”

由于ffuf的扩展名模糊测试功能在我这里运行不太正常（它似乎只测试一个扩展名后就停止），我决定编写一个简单的Bash脚本来解决这个问题：

#!/bin/bash
Default_WORDLIST="/usr/share/seclists/Discovery/Web-Content/big.txt"
EXTENSIONS="xml dll svc zip 7z htm html json js aspx asmx ashx debug"

url=$1
wordlist="${2:-$Default_WORDLIST}"
hostname=$(echo $url | cut -d "/" -f3)

if [[ -z "$url" ]]; then
    echo "[+] No url specified"
    exit 1
elif [[ ! "$url" =~ ^https?://([a-zA-Z0-9_.-]+\.)+[a-z].* ]]; then
        echo "[+] Url is not correct"
        exit 1
fi

if [[ -f "$wordlist" && -s "$wordlist" ]]; then
    echo "[+] Fuzzing with wordlist: "$wordlist""
    for ext in ${EXTENSIONS[@]}; do
        echo -ne "[+] Fuzzing Ext: "$ext"\n"
        ffuf -u "$url/FUZZ.$ext" -w "$wordlist" -ac -o "$hostname-ffuf.txt" #-rate 40
    done
else
    echo "[+] The file you specified does't exist or empty"
    exit 1
fi

这次扩展名模糊测试的结果令人震惊：发现了 inspection.aspx、research.aspx（一个SOAP API端点），以及最关键的文件——build.xml。

黄金文件：build.xml

打开 build.xml 文件犹如获得了一张藏宝图。它泄露了大量敏感信息：

• 内部API端点
• 引用的DLL文件
• 隐藏的路由
• 基础设施细节

以下是 build.xml 文件中的一段代码示例：

<sources>
    <include name=".\*.cs"/>
    <include name=".\Admin\*.aspx.cs"/>
    <include name=".\Admin\*.cs"/>
    <include name=".\test\*.aspx.cs"/>
</sources>

这无疑是一起严重的信息泄露漏洞。但根据经验，如果仅以此上报，很可能被归类为“信息性”或低优先级漏洞。我需要证明其实际影响。

持续追踪与柳暗花明

分析文件后，我逐一测试了其中发现的端点。/test 端点仅重定向到一个无用的AWS测试页面。检查其他端点后，依然一无所获。

感到失望的我暂时合上了电脑。然而，一种直觉驱使我在第二天重新打开Burp Suite，仔细回放和审查所有的HTTP历史记录。正是这次复查，让我注意到了一个之前遗漏的请求，它包含了5个参数。其中一个名为 group 的参数引起了我的注意。

一个想法闪过：“这个参数值是否会传递到数据库进行查询？”

反正没有其他线索，我尝试注入了一个单引号 ' 进行测试。

Bingo！数据库报错了。

这是一个明显的基于错误的 SQL注入 漏洞。

漏洞确认与深度利用

我随后测试了基于时间的盲注Payload，确认漏洞真实存在。我使用了 Ghauri（一款优秀的SQL注入工具，因其支持基于XOR的Payload而在某些场景下优于sqlmap）成功利用该漏洞，从数据库中提取出了敏感信息。

此刻，我决定将之前发现的 build.xml 信息泄露漏洞一并上报。不出所料，该报告最初被标记为“信息性问题”（P5）并被关闭。分诊员要求提供实际影响的证据：“您是如何利用这些泄露的DLL和端点信息访问到敏感数据的？”

我试图直接演示访问但未能成功。随后，我在已提交的SQL注入漏洞报告中补充了一条关键评论：

“您将 build.xml 信息泄露报告标记为仅供参考，但我正是通过分析该文件中泄露的端点路径，才最终发现了这个严重的SQL注入漏洞。”

一天后，团队重新开启了信息泄露报告并予以修复，SQL注入漏洞则被单独归类处理。

核心经验总结

1. 不要忽视默认页面：它们往往因被遗忘而缺乏维护，可能隐藏着通往核心系统的路径。
2. 善用社区智慧：在X平台的求助获得了关键建议，这凸显了安全社区协作的价值。
3. 坚持就是胜利：在看似无果的测试后多进行一次尝试，往往就是发现漏洞的关键。
4. 完整记录HTTP流量：全面审查Burp Suite等工具记录的HTTP历史，可能发现肉眼浏览时忽略的细节。
5. 关联分析提升漏洞价值：将看似低危的信息泄露与后续发现的高危漏洞（如SQL注入攻击）关联起来，能有效证明前者的实际风险，推动问题解决。

渗透测试的思维模式

当你的直觉告诉你“再试最后一次”时，听从它。那多一次的参数测试、多一页的流量审查，常常是突破的关键。所有人忽略的基础设施、“枯燥”的默认IIS页面、看似“无法利用”的信息披露，共同构成了一条攻击链，最终导致了关键数据库的泄露。最有趣的目标，往往隐藏在最平庸的外表之下。

真正的安全防护，需要比自动化扫描器思考得更深。这正是一次完整的渗透测试思维与实践的体现，也提醒开发与运维团队，即使是最基础的服务器维护与配置也不容忽视。