IIS短文件名枚举漏洞

2017年，短洞安全研究员Soroush Dalili在一次渗透测试中，文件盯着IIS服务器的名枚响应头看了整整十分钟。他反复发送同一个HTTP请求，举漏只是短洞把文件名后缀从“.asp”改成“.aspx”，再改成“.ashx”，文件然后观察返回状态码的名枚细微差别——200、404、举漏400，短洞偶尔还有500。文件这些数字的名枚排列组合，最终拼凑出一个藏在Windows文件系统底层的举漏小秘密：IIS短文件名枚举漏洞。

这个漏洞的短洞本质，是文件Windows为了兼容老软件，给每个长文件名自动生成一个8.3格式的名枚短别名。比如“ReallyImportantDocument.aspx”会被截成“REALLY~1.ASP”。关键在于，IIS处理这些短文件名时，会像瞎子摸象一样——你只输入前几个字符，它就能通过通配符匹配判断出文件是否存在。攻击者根本不需要知道完整文件名，只需暴力枚举短名的前六位字符，就能把服务器上的文件目录摸个底朝天。

实操起来有多恐怖？我见过一个新手用Burp Suite的Intruder模块，对着一个IIS站点跑了不到五分钟，就列出了后台登录页、备份压缩包、甚至一个包含数据库连接字符串的.config文件。整个过程不需要任何认证，请求量也就几百个，防火墙根本不会触发告警。更讽刺的是，这个漏洞在2009年就被报告了，微软的官方建议是“禁用8.3名称创建”——但绝大多数Windows Server默认开启这个功能，而且很多管理员压根不知道自己的服务器上还住着这么个“房客”。

真正麻烦的是，这个漏洞没法靠打补丁根治。微软发布过修复程序，但只是让短文件名的访问返回统一状态码，可攻击者还能通过响应时间差异来判断——请求存在的短文件名时，IIS处理时间会多出几十毫秒。这招连修改注册表都防不住，除非你彻底禁用8.3名称生成，但那又会影响某些老软件的兼容性。于是很多运维人员选择“眼不见为净”，直到某天日志里出现大量连续的HEAD请求，才意识到服务器早就被人翻了个底朝天。

有个细节我印象特别深。某次攻防演练中，蓝队把Web应用防火墙的规则调得密不透风，却漏掉了IIS的OPTIONS方法。攻击者就是用这个方法配合短文件名枚举，找到了一台测试服务器上的“site_bak_2016.zip”。那个压缩包没设密码，里面躺着全套源码和数据库备份。事后复盘时发现，漏洞扫描器早就报过“IIS短文件名泄露”，但报告被当成低危漏洞搁置了——毕竟谁会想到，一个“信息泄露”级别的隐患，最后能演变成数据失窃的突破口呢？

如今云主机和容器化部署越来越普及，很多人觉得IIS时代已经过去了。但现实是，大量政企内网还在跑着Windows Server 2008 R2，上面挂着老旧的ASP.NET应用。这些系统就像城市地下那些没人记得的防空洞——平时看不见，真到需要躲藏时，连张地图都没有。短文件名枚举漏洞就是那把生锈的钥匙，不用多高深的技术，只要知道往哪个锁孔里捅。

写这篇文章的时候，我随手用脚本扫了一个政府门户网站，返回的响应头里清清楚楚地带着“X-AspNet-Version: 2.0.50727”。没往下测，但心里明白，那台服务器大概率还开着8.3短名生成。这不是某个特定单位的疏忽，而是整个行业对历史遗留问题的集体惰性。也许等这批物理机彻底退役，这个漏洞才会真正走进坟墓——但在此之前，它依然像暗河一样，静静流淌在无数个被遗忘的IIS站点下面。