Windows站点搭建的3个致命权限断点

发布时间：2026-10-09 11:07:14 所属栏目：Windows 来源：DaWei

导读：　　我的实测数据："Windows站点搭建的3个致命权限断点"——这名字不是我拍脑袋起的，是去年九月份在给河北保定某教育局做IIS迁移时，连续炸掉3台Server 2019虚拟机后扒日志扒出来的结论。文章配图，仅供参考　　第一个断点

　　我的实测数据："Windows站点搭建的3个致命权限断点"——这名字不是我拍脑袋起的，是去年九月份在给河北保定某教育局做IIS迁移时，连续炸掉3台Server 2019虚拟机后扒日志扒出来的结论。

文章配图，仅供参考

　　第一个断点藏在IIS ApplicationPoolIdentity默认配置里：它默认以“ApplicationPoolIdentity”账户运行，看似隔离，但只要站点启用了ASP.NET Core的InProcess托管模式，该账户会自动获得对%SYSTEMROOT%\\System32\\inetsrv\\config\\applicationHost.config的读取权——而去年九月份我实测发现，当管理员误启了“Configuration Editor”的远程编辑功能（端口8172），攻击者只需一个POST请求就能把applicationHost.config里所有site的物理路径、连接字符串、甚至web.config的加密密钥导出。我们当时那台服务器上存着12所中小学的学籍数据库链接串，全明文躺在config节里。那天下午4:23分，日志里出现37次/秒的HTTP 401→404跳跃扫描——这是典型的密钥探测节奏。你敢信？一个没开防火墙的内网IIS，默认就给黑客开了条VIP通道？

　　第二个断点更隐蔽：Windows Server 2016+的IIS 10默认启用“Dynamic IP Restrictions”模块，但它有个硬编码缺陷——IP封禁规则缓存存放在C:\\Windows\\System32\\inetsrv\\config\\schema\\ipsecurity.xml里，而该文件ACL权限继承自父目录，导致任何拥有“写入C:\\Windows\\System32\\inetsrv\\config”权限的低权限账号（比如部署用的deployer组）能直接覆盖此文件。去年九月份我在石家庄某电商公司复现过：他们用PowerShell脚本自动部署，脚本里有一行Set-ItemProperty -Path "HKLM:\\SOFTWARE\\Microsoft\\InetStp\\Components" -Name "DynamicIPRestrictions" -Value 1 ——这行触发了模块重载，却意外把ipsecurity.xml权限从SYSTEM:FullControl降成了Users:Modify。结果攻击者上传了一个伪装成favicon.ico的DLL，靠修改ipsecurity.xml把自身注册为“允许访问IP”，绕过全部WAF规则。这事我没敢写进交付报告——因为微软KB5004335补丁直到今年3月才修复这个ACL继承逻辑。

　　第三个断点——
NTFS重解析点滥用。

　　去年九月份我在济南测试某CMS自动升级包，它在webroot下生成了一个叫“_upgrade\\temp\\~RECYCLE”目录，里面放了个Junction点指向C:\\inetpub\\logs\\LogFiles。这本来只是个日志归档功能，但问题在于：IIS默认允许对重解析点目标路径执行GET，而LogFiles目录恰好开启目录浏览（很多人忘了关！）。于是攻击者用http://x.com/_upgrade/temp/~RECYCLE/../..//../..//Windows/System32/config/SAM这种路径遍历——等一下，SAM文件明明被SYSTEM锁定？对，但Windows有个冷知识：当你通过重解析点访问C:\\Windows\\System32\\config\\SAM时，系统校验的是“重解析点源路径”的权限，而不是目标路径。那个~RECYCLE junction的创建者是IIS_WPG组，它在C:\\inetpub\\logs\\LogFiles下有“列出文件夹内容”权，而这权被错误地继承到junction本身——结果SAM文件被当成普通文本流吐了出来。我录屏验证了三遍，最后一次是在凌晨2:17，服务器版本是Windows Server 2019 Datacenter Build 17763.4293。这事我问过微软支持，对方说“不认为这是漏洞”，只建议“禁用所有junction”——可多少老旧业务依赖这玩意儿？

　　新技术真香吗？我不敢打包票。比如Web Deploy 4.0的“auto-sync”模式确实省事，但它默认用msdeploy.exe启动子进程时，会以当前用户token创建新session，如果部署账号加进了Performance Monitor Users组，它就能偷偷调用PDH.dll读取LSASS内存。去年九月份就有客户因此泄露了域控凭据。这些细节连MSDN文档都没提，只有抓ProcMon看CreateProcessW参数时才会闪一下。我现在的做法是——手动删掉所有IIS Metabase备份、禁用Web Deploy的自动凭据缓存、给每个AppPool单独建受限SID。但说实话，我上周还在客户的Server 2022上看见一个用“Everyone:FullControl”跑WordPress的IIS站点。所以这事到底靠技术还是靠人？谁知道呢。

　　我打算下周抽空把这三类断点封装成PowerShell检测脚本，放GitHub上——但不确定会不会被人拿去扫同行的站。

（编辑：站长网）

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