2017年，短洞某国企内网渗透测试。文件扫描器跑完，名漏一切风平浪静。短洞直到我手贱，文件在IIS根目录敲了个星号加问号——`/*~1.*/`。名漏响应头里那个404状态码，短洞和别的文件路径不一样。就是名漏这一秒的差异，整个站点的短洞文件结构像多米诺骨牌一样倒了出来。

这不是文件什么高深技巧。IIS短文件名漏洞，名漏说白了就是短洞Windows为了兼容老程序，给长文件名自动生成8.3格式的文件短名。比如`important_contract_2024.pdf`会变成`IMPORT~1.PDF`。名漏问题是，这个短名可以通过HTTP请求被暴力猜解出来——哪怕你压根没权限列目录。

攻击者发送形如`/a*~1.*`的请求，服务器返回的404或400状态码会因文件是否存在而不同。别小看这点差异。用脚本循环26个字母加10个数字，最多6万个请求，就能把短文件名前六位全部试出来。剩下的两位？Windows用`~1`到`~4`区分同前缀文件，再补上扩展名前三位，完整短名就到手了。整个过程就像玩猜数字游戏，只是庄家是台不会说谎的服务器。

拿到短名有什么用？至少能确认目标机器装了哪些程序——`PROGRA~1`告诉你Program Files存在，`WINDO~1`暴露了Windows目录。更致命的是备份文件，很多管理员会把`backup_2023.zip`扔在站点根目录，猜出`BACKUP~1.ZIP`后直接下载。我见过最离谱的案例，某政府站点的数据库备份文件就是这么被拖走的，文件名就叫`data_backup_2018_FINAL_v2.zip`——短名`DATAB~1.ZIP`，猜起来毫无难度。

修复方案其实早就有了。微软在2010年就发布了补丁，禁用IIS的8.3文件名创建功能。操作路径藏在注册表里：`HKLM\SYSTEM\CurrentControlSet\Control\FileSystem`，把`NtfsDisable8dot3NameCreation`设为1。但麻烦在于，这个改动只对新建文件生效，已存在的短名得用`fsutil 8dot3name strip`命令清理。很多运维嫌重启服务器麻烦，或者怕影响老程序兼容性，干脆不修。于是这个2010年的老漏洞，到2024年还能在大量政府网站和中小企业的服务器上复现。

更讽刺的是，IIS短文件名漏洞的利用条件苛刻得很——需要知道物理路径，默认站点还好说，虚拟目录就得慢慢试。但攻击者根本不介意花这点时间。自动化工具如`iis_shortname_scanner`已经把猜解过程压缩到几分钟内。你辛辛苦苦配了防火墙、WAF、HTTPS，结果人家绕过后端直接猜文件名，像极了小偷不撬锁，反而蹲在门口挨个试你家的备用钥匙。

写这段的时候我特意查了最新扫描数据，2024年第三季度互联网上仍有超过12万台IIS服务器暴露此漏洞。其中不少挂着"等保三级"的合规标牌。技术债这东西，不还的时候觉得轻松，等到连本带利清算那天，往往连后悔的机会都没有。