GPP密码泄露事件——我的天呐，安全防线就这样塌了？
哎,朋友们，今天咱们不聊那些高大上的空理论，就掰开揉碎，复盘一个让我半夜惊醒的真实案例——GPP密码泄露事件，说真的，写这篇文章的时候，我后背都还有点发凉，这哪是技术漏洞啊，这分明是人性的大意和管理的溃堤啊！如果你也管着服务器、握着核心权限，我求你花几分钟看完，真的，血泪教训。
事情是怎么发生的？我简直不敢相信我的眼睛！
事情是这样的,GPP（Group Policy Preferences，组策略首选项）这玩意儿，很多运维的老哥肯定不陌生，它本来是微软给我们行方便用的，比如批量修改本地管理员密码、映射驱动器之类的，方便的背后，藏着一个惊天的雷——如果配置不当，密码是以加密后的形式存储在SYSVOL共享文件夹里的，关键是，这个“加密”不是咱们理解的那种强加密，它用的是AES-256密钥，但密钥是公开硬编码在微软文档里的！
哎呀妈呀,我当时复盘的时候，整个人是懵的，你想想，一个域管理员为了方便，把几十台服务器的本地密码通过GPP下发，结果这个密码文件就静静躺在SYSVOL里，等着任何能读取域共享的家伙来捡漏，谁能想到啊？我平时总觉得内网是安全的，防火墙一拦，谁能进来？可偏偏，风险就藏在你的“信任”里。
那天晚上，我亲眼看着日志里，一个陌生IP通过域账户尝试登录，还成功改了策略。 我第一反应是：不可能！绝对不可能！我们密码设置得那么复杂！但事实就是，当攻击者拿到SYSVOL里的那个Groups.xml文件，执行一条gpp-decrypt命令，密码就跟明文一样躺在眼前，那一刻，我心跳快得跟打鼓似的，嘴巴里一直念叨：“完了完了，这得泄漏多少台机器啊？”
深挖细节：不是微软的锅，是我们自己的懒！
咱们得讲道理,这次案例复盘，我不能光骂微软，微软其实后来也意识到了这个问题，在MS14-025补丁里做了公告，甚至推出了Protected Policy Processing来缓解，但问题的根源在于，很多像我一样的运维人员，为了省事，直接沿用旧习惯，忽略了最佳实践。
我复盘自己当时的心路历程,就是三个字：太自信，总觉得“我这儿没事”、“攻击者没那么专业”、“内网很干净”，这种侥幸心理，说实话，比黑客的攻击更可怕，你想想，当你把一个密码，用那种存了两年的旧加密方式放在共享目录里，跟把钥匙放在门口的脚垫底下有什么区别？区别就是，你甚至没意识到脚垫底下有监控！
最让我捶胸顿足的是，我们当初没有做好最小权限划分！ 只要是个普通域用户，就能读取SYSVOL里的配置文件，这合理吗？合理个鬼！我后来才明白，权限收敛、定期审计、密码代填工具，这些才是王道！但当时呢？就图快，觉得用组策略一次搞定几十台机器，爽得不行，结果呢？一朝泄密，全线崩溃。
情绪平复后的反思：我们到底应该怎么防？
讲到这里,我心里其实已经从“震惊”转为“庆幸”和“后怕”，庆幸的是，发现的早，攻击者还没来得及横向扩散，后怕的是，如果再晚几天，整个域环境就变成人家的后花园了。
复盘总结，我给各位划重点，也是我自己掏心窝子的话：
第一,立刻禁用GPP密码放置功能！别管老系统有没有在用，一刀切，如果非要下发密码，请使用受保护的组策略（Protected Policy Processing）或LAPS（本地管理员密码解决方案），工具是现成的，别懒！
第二,权限审计必须常态化，你得时不时问问自己，谁在读我的SYSVOL？谁有域管理权限？这些权限是不是配错了？我当时就是没做这一步，才让漏洞躺了八个月，真的，想起来脸都红，丢人！
第三,监控和告警不能形同虚设，日志不是用来存着占硬盘的！你得看！我之前觉得日志太多，没人看，其实这就是最大的失职，我每天强制自己盯着关键事件ID（比如4732、4724），一朝被蛇咬，十年怕井绳啊！
唉，写到这里，心里那股郁闷劲儿才算过去。 安全这条路，真是如履薄冰，咱们不能总指望用新技术去堵老漏洞，更多的，是要修自己的心态和习惯，这次案例复盘，与其说在讲技术，不如说在讲人性——咱们的贪婪、懒惰和侥幸，才是安全最大的敌人。
我真心想跟所有看到这篇文章的同行说一句：别嫌我啰嗦，动手检查一下你的组策略管理，查查SYSVOL目录里有没有Groups.xml文件，如果有，赶紧删掉并撤销相关链接！ 多走一步，安全十分！
学习网络安全可以加QQ：3389553694（咱们一起交流踩坑经验，别再重蹈覆辙啦！）
