IIS所有模块的有模漏洞，远比你想象的漏洞多

IIS 7.5上有个老漏洞，至今还在内网渗透里被反复利用。有模攻击者只需往URL末尾加个分号，漏洞就能绕过路径校验，有模直接读到web.config里的漏洞数据库连接字符串。这不是有模什么高深技巧，但微软修了三年才彻底堵上——期间无数站点被拖库。漏洞所以别迷信“默认安装很安全”这种鬼话，有模IIS的漏洞每个模块都是攻击面。

先看最基础的有模静态文件模块。它负责处理html、漏洞css、有模js，漏洞听起来人畜无害对吧？有模但2017年爆出的短文件名漏洞就藏在这里。IIS为了兼容旧程序，会生成8.3格式的短文件名，攻击者用通配符就能逐个猜出服务器上的所有文件。更恶心的是，这个漏洞在Windows Server 2008到2019全系存在，微软干脆不修了，只给了个禁用短文件名生成的PowerShell命令。你猜有多少管理员真去执行过？

ASP.NET模块是重灾区。ViewState机制本来用于保持页面状态，但若没配置MAC验证，攻击者就能伪造序列化数据，直接触发RCE。2019年那波利用ViewState反序列化打Exchange服务器的事件，至今还在被红队反复使用。还有个细节很多人不知道——IIS 6.0时代遗留的“.”和“%2e”路径解析问题，能让攻击者绕过认证访问aspx页面，直到IIS 7.5才彻底修复。十二年，整整十二年。

WebDAV模块更是个笑话。默认安装时它压根不启用，但只要管理员为了“方便远程维护”勾选一下，就等于给服务器开了个后门。2016年的IIS 6.0 WebDAV漏洞，允许任何人向服务器上传asp木马，利用难度低到初中生都能操作。微软的修复补丁还闹过乌龙——最初版本居然没解决核心问题，被安全社区嘲讽了整整一个月。

别忽略CGI模块。虽然现在用FastCGI居多，但老系统上跑的Perl脚本仍有大量残留。IIS对CGI请求的超时处理存在逻辑缺陷，攻击者发送一个永远不结束的请求，就能耗尽服务器线程池。更麻烦的是，CGI进程的权限继承机制混乱，经常出现IIS工作进程以SYSTEM权限运行的情况——这通常是管理员偷懒，直接给应用程序池分配了最高权限。

还有压缩模块。它用于gzip压缩响应内容，但2015年爆出的“HTTP压缩炸弹”漏洞，能让服务器在解压恶意请求时内存暴涨。攻击者只需发送一个几KB的压缩包，就能让IIS进程崩溃。微软的修复方式是限制压缩比，但代价是牺牲正常用户的响应速度——典型的拆东墙补西墙。

最讽刺的是自定义错误模块。它本意是隐藏服务器信息，但错误页面里泄露的堆栈跟踪、物理路径和.NET版本号，反而成了攻击者的情报来源。我在渗透测试中见过太多站点，直接返回“/var/www/html/”这种绝对路径——管理员压根没关掉详细错误信息。这不算漏洞，但比漏洞更致命。

说句实在话，IIS的模块架构设计于2000年代，那时根本没想到会有如此复杂的攻击手法。每个模块独立运行、独立授权，看似隔离良好，实则模块间的信任边界模糊。比如URL重写模块和静态文件模块的组合，就能绕过访问控制列表——这类“模块联动”漏洞，至今没有系统性修复方案。

所以别问“IIS有哪些漏洞”，该问“你的IIS暴露了多久”。安全补丁永远追不上攻击手法迭代，唯一靠谱的办法是定期做攻击面梳理，把用不上的模块全禁掉。毕竟，攻击者最爱的不是0day，而是那些躺了十年都没人管的旧配置。