Windows站点搭建的3个致命安全断点

　　“Windows站点搭建的3个致命安全断点”——这标题不是我拍脑袋想的，是去年九月份在河北保定某政务云迁移项目里被红队现场打穿后，翻着IIS日志和PowerShell执行历史硬抠出来的结论。当时对方用的是CVE-2023-24932变种，绕过默认AppPool隔离，直接把C:\\inetpub\\wwwroot下的web.config给拖走了——而我们居然还开着目录浏览功能。

　　第一个断点藏在IIS Application Initialization模块的自动启动逻辑里。去年九月份实测：只要启用了“预加载”且配置了自定义warm-up URL（比如/api/health），IIS会以ApplicationPoolIdentity身份发起HTTP请求——这个身份默认有SeImpersonatePrivilege权限，而warm-up脚本若调用Invoke-RestMethod或curl.exe，就会把当前令牌带进子进程。我们在石家庄某银行测试环境发现，warm-up URL指向一个未鉴权的/internal/debug.php，结果它返回了一段base64编码的PowerShell，被IIS自动解码并执行，顺手把整个AppPool的内存dump了出来。这事我反复复现了7次，每次都是相同路径。你说巧不巧？

　　第二个断点在Windows证书存储机制和Let's Encrypt自动化脚本的交界处。acme.ps1这类脚本常以SYSTEM身份运行，但很多团队习惯把certutil -repairstore命令写在Post-hook里，结果它偷偷把私钥导出成PFX文件存到%SYSTEMROOT%\\Temp——而默认该目录Everyone可读。我在去年九月份帮唐山一家制造企业做渗透复查时，在C:\\Windows\\Temp\\le_renew_20230914.pfx里找到了他们的全站TLS私钥。更离谱的是，他们用了ACME v1协议，响应包里明文回传keyAuthorization字段……这哪是自动化，这是裸奔。

　　第三个断点最隐蔽：NTFS ACL继承链上的“空隙”。当用New-WebSite cmdlet创建站点时，如果没手动-ciminstance设置-Force，IIS Manager会跳过父目录ACL同步。我们实测发现，C:\\inetpub\\custerr目录默认继承自C:\\inetpub，但其中en-US子目录的ACL竟比父级少了一条“IIS_IUSRS:RX”，导致错误页面返回500时，ASP.NET Core会抛出FileLoadException——而异常堆栈里赫然包含物理路径“C:\\inetpub\\custerr\\en-US\\500.htm”。去年九月份廊坊某医保系统就因此泄露了绝对路径结构，攻击者直接用…/…/…/windows/win.ini探针确认了服务器版本。这事儿连微软官方KB888888都没提过——它只说“确保继承”，但没说“cmdlet不保”。

　　新技术让这些断点变得更致命。IIS 10.0+的Application Initialization、ACME v2集成、Schannel TLS 1.3强制启用——它们本身没错，但组合起来就像三把没上膛的枪，每把都卡在保险栓失效的位置。我坚持认为，“Windows站点搭建的3个致命安全断点”优点就在“新技术”——因为旧方案至少你还能靠经验踩坑，而新方案连坑长什么样都不知道。

文章配图，仅供参考

（编辑：站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!