文章总结: 本文讲述了一名安全研究人员如何从看似无害的默认IIS页面开始,通过目录扫描发现隐藏网站,进而找到敏感的build.xml文件,最终利用文件中暴露的内部端点信息发现严重SQL注入漏洞。文章强调了坚持探索、黑客社区价值以及如何将看似无害的信息泄露与实际漏洞联系起来,展示了安全测试中不应忽视任何细节的重要性。
综合评分: 89
文章分类: 渗透测试,漏洞分析,WEB安全,实战经验,应急响应
从默认 IIS 页面到关键 SQL 注入
hai dragon
安全狗的自我修养
2025年12月11日 15:13
湖南
官网:http://securitytech.cc/
#
为什么“无聊”的基础设施常常藏着最危险的秘密
The Setup:又是平常的一天,又是新的项目
这只是 HackerOne 私有项目中的普通一天。像所有老练的猎人一样,我先做信息收集,用 Subfinder(启用所有 API key)扫描子域。接着跑 httpx-toolkit 查存活主机,我得到了平时的目标列表。
之前我已经给这家公司报过两次 SQL 注入 了。
改变一切的“无聊”发现
在猎过三个子域后,我回到列表继续找可能比较有趣的点。我查看之前的截图,其中有两个子域显示的是 默认 IIS 页面。
按 Enter 或点击查看完整图片
示例默认 IIS 页面
多数猎人看到这种就直接跳过了。默认页面?无聊。
但我想起了一篇 writeup 里的话:
“没有人会花钱托管空白或默认页面。”
向那位写下这句话的黑客致敬——他们的话在我脑中回响,我决定深入看看。
第一步:短文件名扫描,以及完全失败的开始
在 fuzz 之前,我先跑了一个 IIS short name scanner。结果:存在漏洞。我从兴奋变成困惑——我知道它有漏洞,但不知道怎么利用。
我开始用各种字典进行 fuzz。
几个小时过去了——毫无结果。
沮丧之下,我在 X(原 Twitter)发了条简单的帖子:
“Now what”,并附上扫描截图。
按 Enter 或点击查看完整图片
一个猎人回复:“试试 GitHub 上 @orwagodfather 的字典。”
我想:也行吧。于是跑:
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 页面变成了一个隐藏在默认页面后的小网站。
游戏正式开始了。🔥
点击所有内容,但什么都没发现
我点了每个链接、按钮、功能——毫无发现。看起来很安全。
这时我想起我最喜欢的一位猎人的演讲——关于如何攻破 IIS。我重新打开他的幻灯片,其中关键一句话:
“如果 fuzz 失败,试试这些扩展:xml, zip, txt, json, js, obj, asmx, xsl, dll…”
例如:
ffuf -u "https://target.com/FUZZ.ext" -w wordlist.txt -ac -fs 0
但 FFUF 的 extension fuzz 对我不太正常——只测一个扩展就停……不知道为什么 🤷♂️
于是我写了一个快速的 bash 脚本来 brute force 扩展:
#!/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"
...
结果令人震惊:扫描到了
inspection.aspxresearch.aspx(SOAP API)- 最重要的:
build.xml
黄金文件:build.xml
打开 build.xml 就像发现藏宝图,它暴露了:
- 内部敏感 endpoint
- DLL 文件
- 隐藏 API
- 基础设施细节
片段示例:
<sources>
<includename=".\*.cs"/>
<includename=".\Admin\*.aspx.cs"/>
<includename=".\Admin\*.cs"/>
<includename=".\test\*.aspx.cs"/>
</sources>
这是典型的信息泄露,但我知道如果直接上报——十有八九是 informative(低危)。
我需要“影响力”。
追逐开始
从文件分析到的一堆 endpoint,我依次测试。
其中 /test 会重定向到 AWS 测试页——没用 😒
所有的 endpoint 都试遍——还是没有。
沮丧,我关上笔记本休息。😣
黑客的困境:什么时候该放弃?
第二天,我准备换一个子域。
但心里那句直觉在提醒我:
“再试一次,只要一次。”
我反驳自己:
“所有都看过了,浪费时间。”
但那个声音仍然存在。
我勉强打开 Burp,翻 HTTP 历史。
突然,我看到一个奇怪的请求 —— 有 5 个参数,之前漏掉了。
其中一个参数叫:group
我脑海闪过一个念头:
“这东西是不是进数据库?”
我随手注入一个 '
页面崩了,报数据库错误。
按 Enter 或点击查看完整图片
😎 基于报错的 SQL 注入
确认与利用
时间盲注 payload 一试——有效。
这是真·SQL 注入。
我用 Ghauri(比 sqlmap 强一点,尤其 XOR payload)成功拿到数据库数据。
信息泄露报告被嫌弃?没关系
休息时我想:“不如把 build.xml 信息泄露也报上去吧?”
报了。
果然:Informative(P5)。
审阅者问:
“你怎么证明可以访问这些 DLL 文件和敏感数据?”
我试了——做不到。
但转机来了:
在 SQL 注入报告里我备注:
“你们关闭了
build.xml报告,但我就是根据它找到这个 严重 SQL 注入 的。”
第二天:
信息泄露报告被重新打开并确认有效。
SQL 注入则单独 triage。
按 Enter 或点击查看完整图片
关键经验
- 默认页面并不无聊
——它们通常无人维护,漏洞最多。 - 黑客社区很重要
——X 上那条回复改变了整个猎杀过程。 - 坚持比天赋更重要
——最后的那一次尝试常常就是关键突破。 - 记录一切
——HTTP 历史救了这次行动。 - 关联多个弱点,能形成重大漏洞链
——信息泄露 + 业务端点 = SQL 注入。
黑客的思维方式
当直觉告诉你“再试一次”时,请听它的。
最后一试、最后一页、最后一个参数——往往金矿就在那。
每个人忽略的基础设施、
无聊的 IIS 页面、
“不可利用”的信息泄露……
组合起来却能导致一次重大数据库泄露。
- 公众号:安全狗的自我修养
- vx:2207344074
- http://gitee.com/haidragon
- http://github.com/haidragon
- bilibili:haidragonx
#
免责声明:
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景,旨在提升网络安全防护能力,具有明确的技术研究属性。
任何单位或个人未经授权,将本文内容用于攻击、破坏等非法用途的,由此引发的全部法律责任、民事赔偿及连带责任,均由行为人独立承担,本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布,若存在版权侵权或其他异议,请通过邮件联系处理,具体联系方式可点击页面上方的联系我。
本文转载自:安全狗的自我修养 hai dragon《从默认 IIS 页面到关键 SQL 注入》