文章总结： 本文记录从默认IIS页面发现关键SQL注入漏洞的过程。作者通过短名称扫描发现漏洞，特定字典模糊测试找到隐藏网站，扩展名扫描获取敏感build.xml文件，最终在test页面参数中发现并利用SQL注入。文章强调坚持和深入挖掘的重要性，展示了将默认页面转化为高严重性漏洞的方法。 综合评分： 93 文章分类： 渗透测试,WEB安全,漏洞分析,实战经验,漏洞POC

0096.从默认 IIS 页面到关键 SQL 注入

Ahmad Mugh33ra

Rsec

2025年12月14日 12:27 贵州

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

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

类型：SQL注入

又一天，又一个节目：

在 HackerOne 的私有项目中，这不过是又一天。像任何经验丰富的黑客一样，我首先使用 Subfinder 之类的工具进行侦察，并启用所有 API 密钥来收集子域名。运行 httpx-toolkit 识别出活跃主机后，我得到了常用的目标列表。之前我已经向这家公司报告过两次 SQL 注入攻击。

一项“平淡无奇”的发现，却改变了一切：

在搜索了三个子域名之后，我回到列表寻找更有趣的目标。我查看了之前截取的所有子域名的屏幕截图，发现其中两个子域名显示的是：默认的 IIS 页面。

示例：默认 IIS 页面

大多数猎人都会直接略过这些页面。默认页面？无聊透顶。但我突然想起之前在一篇文章里读到的一句至理名言：

“没有人会托管空白或默认页面，因为托管需要花钱。”

向那位黑客致敬！他们的话语在我脑海中回荡，我决定进一步调查。

#

第一步：短名称扫描器和初始失败：

在进行模糊测试之前，我先运行了一个 IIS 短名称扫描器。结果如何？存在漏洞。我的兴奋很快变成了困惑——我知道它存在漏洞，但我完全不知道该如何利用它。

我开始使用各种词表进行模糊测试。几个小时过去了，一无所获。

我感到很沮丧，于是在 X（以前称为 Twitter）上发了一条简单的帖子：

“接下来怎么办？”并附上扫描结果截图。

短名称扫描结果

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

我耸了耸肩。为什么不呢？于是我运行了 ffuf：

ffuf&nbsp;-u&nbsp;"https://target.com/FUZZ"&nbsp;-ac -fs&nbsp;0&nbsp;-w <(curl -s&nbsp;"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 -u "https://target.com/FUZZ.ext" -w wordlist.txt -ac -fs 0

由于 FFUF 的扩展模糊测试对我来说不太正常（它只会测试一个扩展然后停止），我也不知道为什么🤷‍♂️，所以我写了一个简单的 bash 脚本来解决这个问题。

#!/bin/bashDefault_WORDLIST="/usr/share/seclists/Discovery/Web-Content/big.txt"EXTENSIONS="xml dll svc zip 7z htm html json js aspx asmx ashx debug"url=$1wordlist="${2:-$Default_WORDLIST}"hostname=$(echo $url | cut -d "/" -f3)if [[ -z "$url" ]]; then    echo "[+] No url specified"    exit 1elif [[ ! "$url" =~ ^https?://([a-zA-Z0-9_.-]+\.)+[a-z].* ]]; then        echo "[+] Url is not correct"        exit 1fiif [[ -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    doneelse    echo "[+] The file you specified does't exist or empty"    exit 1fi

结果令人震惊： inspection.aspx 、 research.aspx （SOAP API 端点），以及最重要的 build.xml

黄金文件：build.xml：

打开 build.xml 就像找到了一张藏宝图。它揭示了：

• 敏感的内部端点
• DLL 文件
• 隐藏的 API 路由
• 基础设施详情

以下是 Build.xml 文件中的一段代码：

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

这显然是一起信息泄露事件，但我根据经验知道：如果按原样上报，很可能会被标记为“信息性”低优先级。我需要产生影响。

追逐开始了：

分析文件后，我发现了几个端点。我测试了其中一个端点 /test ，结果它重定向到了一个 AWS 测试页面（毫无用处）😒。我检查了文件中的每个端点，一无所获。

失望之余，我合上笔记本电脑，休息了一会儿。😣

黑客思维 ：

第二天，我决定迁移到另一个子域名。但我脑海中有个声音在说： “再试一次吧，就一次。”

我反驳道： “我已经检查过所有东西了，为什么还要浪费时间呢？”

但那个声音一直萦绕不去。

于是，我打开了 Burp Suite，开始从测试页面开始滚动查看 HTTP 历史记录。这时，我发现其中一个请求看起来很奇怪，它有 5 个我之前漏掉的参数。其中一个参数引起了我的注意： group 。

我脑子里飞快地想着：🧠 “如果这条信息通过数据库会怎么样？”

反正也没什么可失去的，我插入了一句引言： '

糟糕！数据库出错了。

😎 基于错误的 SQL 注入

确认与利用：

我测试了基于时间的有效载荷。它们奏效了。这是真正的 SQL 注入。

我使用了 Ghauri（我最喜欢的 SQL 注入工具，它比 sqlmap 略胜一筹，因为它支持基于 XOR 的有效载荷），并成功利用了该漏洞，从数据库中提取了敏感数据。

在那段休息时间里，我想： “为什么不把build.xml信息泄露事件报告出来呢？”

我照做了。不出所料：被标记为“信息性问题”（P5）并关闭。分诊员要求提供影响证明： “您是如何访问这些 DLL 文件和敏感数据的？”

我尝试演示直接访问，但失败了。

然后我突然意识到了这一点。我在 SQL 注入报告中添加了一条注释：

“你把build.xml报告标记为仅供参考，但我通过获取该文件中的端点发现了这个严重的 SQL 注入漏洞。”

一天后：他们重新开启了信息泄露报告并解决了问题。SQL 注入漏洞则单独进行了分类处理。

真正重要的教训：

1. 默认页面并不无聊。它们常常被遗忘、无人维护，而且充满了秘密。
2. 社区知识就是财富！X 的回复拯救了这场追捕。
3. 坚持比天赋更重要。一无所获和发现关键漏洞之间的区别，往往仅仅在于多尝试一次。
4. 记录所有 HTTP 历史记录，这才解决了这个问题。
5. 将各个环节联系起来，可以将低严重性问题转化为高优先级修复。

#

黑客的思维模式：

当你的黑客直觉告诉你“再试最后一次”时，一定要听从。那最后一次尝试，那多翻阅的历史记录，那最后测试的一个参数，往往就隐藏着宝贵的经验。

所有人都忽略的基础设施、“枯燥乏味”的 IIS 页面、“无法利用”的信息披露，它们共同构成了一条链条，最终导致了关键数据库的泄露。

如果你喜欢这篇文章，请关注我的旅程：

• X（推特）： @mugh33ra
• LinkedIn： @mugh33ra

祝您狩猎愉快，并记住：

比自动扫描仪更深入地挖掘，黄金通常就埋在地下。👌

最有趣的目标往往隐藏在最平庸的外表之下。✌️

查看原文：《0096.从默认 IIS 页面到关键 SQL 注入》