iis短文件名漏洞检测

发表于 2026-10-17 02:25:11 来源：烟消火灭网

扫描器在目标站点的短洞检URL后头加上`/::$INDEX_ALLOCATION`，响应码是文件200还是404？这问题看着简单，却是名漏IIS短文件名漏洞检测里最让人头疼的坑。短文件名漏洞的短洞检本质，是文件Windows的8.3命名规则在作祟。IIS把长文件名自动截断成6位字符加波浪号加数字的名漏短格式，比如`importantfile.asp`变成`import~1.asp`。短洞检攻击者只要用通配符`*`配合HTTP方法，文件就能逐个字符猜出服务器上的名漏真实文件名。这漏洞从IIS 6.0时代就存在，短洞检到现在IIS 8.5、文件10.0上依然能复现，名漏微软的短洞检修复补丁打了又打，但短文件名生成机制是文件系统级的，IIS层面根本堵不死。名漏检测这漏洞，最土的办法是直接发畸形请求。用`GET /a*~1*/.aspx`这类带星号的路径，如果服务器返回404，说明存在短文件名；如果返回400或403，说明补丁生效了。但这里有个坑——IIS对不同扩展名的处理逻辑不一样，`.asp`和`.aspx`的响应行为完全不同。我见过不少扫描器在`.asp`站点上测出漏洞，换到`.aspx`就误报，纯粹因为没搞清楚IIS的请求处理管线。更隐蔽的是大小写和编码差异。Windows文件系统不区分大小写，但IIS的URL路由却区分。你发`/A*~1*`和`/a*~1*`，响应可能一个200一个404，这取决于目标站点的URL重写规则。还有编码问题，有些扫描器喜欢用`%2a`代替`*`，但IIS在某些版本下会对URL编码做二次解码，导致通配符失效，检测结果就成了假阴性。实际操作中，我习惯用两个请求交叉验证。先发`/l*~1*/.aspx`，再发`/l*~1*/.asp`，如果前者返回404而后者返回400，基本能确定存在短文件名。但别急着下结论——还得排除静态文件干扰。IIS对静态资源（比如`.jpg`、`.css`）的处理走的是StaticFileModule，对动态脚本走的是IsapiModule，两条路径对畸形请求的容错完全不同。所以检测前先摸清目标站点的文件类型分布，否则很容易把静态文件的404误判成漏洞。还有个细节容易被忽略：短文件名漏洞不只影响根目录。子目录下的文件同样存在短名称，但很多扫描器只测根路径。比如`/admin/backup_2024.sql`，短文件名可能是`/admin/backu~1.sql`，你得在每个子目录里都发一遍探测请求。手动测太慢，我写了个脚本，递归遍历目录树，每个节点发三个不同扩展名的探测包，半小时能把一个中等站点的短文件名全挖出来。真正让我觉得这漏洞麻烦的，是它和WebDAV的交互。如果站点开了WebDAV，`PROPFIND`方法能直接列出短文件名，压根不用猜。但WebDAV默认关闭，很多管理员以为关了就没风险，实际上只要IIS的短文件名生成没禁用，攻击者照样能通过`OPTIONS`方法结合`Translate: f`头来探测。这种间接利用方式，比直接发通配符请求隐蔽得多，常规WAF根本拦不住。说到底，检测这漏洞不难，难的是准确判断影响范围。我见过一个金融站，IIS 7.5，测出短文件名存在，但实际文件都是随机命名，攻击者猜出来也没用。反过来，一个内部系统，文件名全是`report_2024_final_v3.xlsx`这种规律性强的，短文件名一泄露，等于把目录结构全暴露了。所以检测报告里光写“存在漏洞”太敷衍，得标明哪些文件能被实际猜到，危害等级才说得清楚。

喜欢57 讨厌77

随机为您推荐

热门文章

文章排行