IIS漏洞：别以为打了补丁就万事大吉

2017年那场经典的IIS 6.0 WebDAV漏洞风暴，至今还让不少老运维心有余悸。攻击者只需构造一个恶意请求，往服务器上扔一个.txt文件，就能直接拿到SYSTEM权限——不是普通用户，是系统最高权限。当时我亲眼看着一台台Windows Server 2003像多米诺骨牌一样倒下，补丁打了，反弹Shell照样进来。为什么？因为很多人根本没搞明白，IIS漏洞从来不是单一问题，而是一整套配置错误、版本遗留和代码缺陷的连锁反应。

先说最容易被忽视的：IIS短文件名泄露。这玩意儿从IIS 6.0时代就存在，到了IIS 8.5依然没根治。攻击者利用8.3短文件名规则，发送类似/a*~1.*/.aspx的请求，服务器响应头里就会泄露目录下是否存在匹配文件。我做过测试，只要目标站开了ASP.NET，用Burp Suite跑几百个请求，就能把服务器上的敏感文件猜个七七八八——比如web.config备份、.bak数据库文件。这漏洞不致命，但它是信息收集的黄金通道。可惜很多站长连URLScan都没装，更别提禁用短文件名了。

再说个实战里高频踩坑的：IIS + PHP的解析漏洞。拿IIS 7.5举例，如果你在FastCGI模式下运行PHP，请求/test.jpg/1.php，服务器会直接把这个路径交给PHP处理——结果是什么？图片马直接执行。这招在2019年仍然有效，我见过一个政府网站就是这么被打穿的，对方只上传了一个带PHP代码的图片，然后访问图片路径加个/x.php，WebShell就到手了。你问官方补丁？微软和PHP团队互相踢皮球，最后靠的是管理员手动修改handler映射才堵住。说到底，IIS默认配置太宽松，它信任开发者，但开发者往往不信任它。

还有一类漏洞纯粹是工程失误。比如IIS 6.0的.asp文件权限继承问题——默认安装下，IUSR_机器名账户对网站根目录有写权限。很多程序员为了方便，把上传目录直接放在根目录下，结果攻击者上传一个.asp文件，直接执行。这哪是漏洞？这是把钥匙挂在门口还贴了张纸条。更讽刺的是，这类问题在2023年的渗透测试里依然高频出现。我去年帮某电商做安全评估，发现他们IIS 10.0服务器上，upload目录居然允许脚本执行，一问才知道，是外包团队为了省事把整个站点目录的权限都设成了“完全控制”。

你可能会说，那我把IIS升级到最新版总行了吧？别急。IIS 10.0的HTTP/2实现也有坑——RST_STREAM帧处理不当可导致进程崩溃，攻击者发几个畸形帧就能让W3SVC服务挂掉。微软在2021年3月修复了它，但如果你没开启自动更新，服务器照样裸奔。而且别忘了，IIS漏洞利用往往和Windows本身的安全机制纠缠在一起。比如MS15-034，那是HTTP.sys的整数溢出漏洞，影响所有IIS版本，攻击者发送一个带特殊Range头的请求，就能让系统蓝屏或执行任意代码。你说这算IIS漏洞还是Windows漏洞？边界模糊得很。

所以我的看法是：别迷信“补丁齐全=安全”。IIS真正的安全隐患，一半在代码，一半在运维习惯。你得定期做两件事——第一，用IISCrypto这类工具检查协议和加密套件配置，把不安全的TLS版本全禁掉；第二，对每个站点做最小权限映射，上传目录务必关闭脚本执行权限。另外，开启日志审计，重点盯OPTIONS、PROPFIND这类非正常请求，攻击者往往先用它们探路。说到底，IIS不是玩具，它默认配置是为易用性设计的，不是为安全设计的。你不管它，它就漏给你看。