iis短文件名漏洞检查工具

一个8.3格式的短洞检遗留问题，让IIS服务器把内部文件结构半遮半掩地暴露了二十年。文件检查工具的名漏核心就一句话：发送特定HTTP请求，看响应差异，查工判断是短洞检否存在短文件名泄露。

原理不复杂。文件Windows为长文件名自动生成兼容DOS的名漏短名，比如important-config.php变成IMPORT~1.PHP。查工IIS处理带通配符的短洞检请求时，如果文件存在，文件返回状态码不同——用*~1.*这类畸形路径去探测，名漏响应时间或状态码会出卖真相。查工攻击者拿字典逐字符爆破，短洞检就能还原出服务器上的文件真实文件名。

检查工具干的名漏事，就是把这种爆破过程自动化。它发送精心构造的请求，对比正常请求与畸形请求的HTTP状态码（404 vs 400）或响应长度差异，然后报告哪些路径存在短文件名。市面上现成工具不少，iis_shortname_scanner和shortscan是常用选择。前者用Python写成，直接发原始socket请求；后者更轻快，适合批量扫网段。

实际测试中我发现一个坑：IIS 6.0和IIS 7.5的响应模式不一样。老版本对GET /a*~1.*返回404，新版本可能返回400或直接403。工具如果没适配版本，容易误报。所以靠谱的检查器得内置多种探测模式，或者允许手动指定IIS版本。另外，Windows Server 2008 R2之后默认关闭了短文件名生成，但存量系统未必打了补丁——检查前先确认目标是否真的存在该漏洞，不然白忙活。

使用工具时别只盯着“存在/不存在”的结果。试着用-v参数开启详细输出，观察每个探测请求的响应码。有时服务器会间歇性返回正常页面，那是WAF在干扰，需要调整请求频率或加随机User-Agent。我见过有人拿工具扫一台开了CDN的站点，结果全扫到缓存节点上，误判成漏洞不存在，教训是扫之前先确认IP是源站。

修复手段反而简单：禁用短文件名功能，或重命名文件让它们不生成短名。但检查工具的价值在于发现那些“以为关了其实没关”的服务器。毕竟很多管理员改了注册表却忘了重启IIS，或者某些第三方组件偷偷重新开启了该功能。

最后说句实在话，这个漏洞危害有限，泄露的只是文件名而非内容。但文件名往往包含敏感信息——backup_2024_old.sql这种命名直接告诉攻击者该尝试哪些路径。检查工具花十分钟跑一遍，比事后排查省心得多。