当前Windows Server 2019和Windows 10 RS5安全基线存在的问题与解决方案

41yf1sh 系统安全 2018年10月24日发布
Favorite收藏

导语:本文将分析当前Windows Server 2019和Windows 10 RS5安全基线存在的一些问题,以及分享相对应的修复方案。

在撰写本文时,这些基线仍然处于“草案”状态。草案版本的基线可以在这里找到。

在Microsoft的建议中,仍然存在一些问题,并且可能需要继续进行修订。在本文中,我们按照现有版本进行分析,但对于凭据保护方面我做出了必要的修改。我将在后文中解释为什么必须对其进行修改。

1.png

问题1

当有用户进行错误类型的SMB共享时,我能够捕获多播的哈希值。

2.png

3.png

修复方案:

禁用组策略中的“多播名称解析”(Multicast Name Resolution),如下图所示。

4.png

问题2

仍然存在NBT-NS(Netbios)投毒(Poisioning)的问题。我无法使用与问题1中相同的方法捕获到任何哈希值。如果不在网络上使用,则应该将Netbios关闭。

5.png

修复方案:

通过组策略首选项,或者通过手动插入注册表的方式,创建以下注册表项。(Dword Value NodeType)

6.png

问题3

即使网络客户端和域成员都启用了SMB签名,我们也能够直接查看Responder的SMB共享,或者在网页上嵌入共享并使其隐藏,同时仍然转储哈希值。

7.png

8.png

9.png

10.png

尝试与Responder建立SMB连接的截图。

11.png

密码哈希值立即被转储,无需输入。

12.png

在Responder中执行以下命令。在这里,并非WPAD存在问题,而是SMBv2在转储HTLM哈希值过程中出现了问题。

13.png

修复方案:

限制传出的NTLM流量。在将规则设置为“Deny All”(全部拒绝)之前,我们应该首先对流量进行审计。审计将允许我们通过NTLM操作日志收集NTLM相关事件。至少应该针对特权访问工作站的事件进行审计。如果存在可以访问的远程系统,但该系统无法处理NTLM之外的任何其他内容(例如Kerberos),那么这样的设置将会带来问题。幸运的是,还有另一种设置,允许在服务器出现异常的情况下请求NTLM身份验证。

14.png

15.png

日志表明,访问Responder CIFS共享的行为被阻止。

16.png

下面是阻止时的提示,并且无法使用Responder捕获哈希值。

17.png

如果大家想要了解关于此设置的更多信息,建议阅读Microsoft官方文档

如果大家希望将NTLM限制在整个域内,建议参考这里方法。

问题4

关于WPAD,同样存在一些注意事项。从2.3.2版本开始,就启用了Responder的代理身份验证。我尝试对其进行强制身份验证,以实现无需交互,透明地获取凭据。然而,这一点不适用于Windows 10 RS5,但后者能够通过转到Responder IP来获得NTLM响应。

如问题3中所述,针对出站NTLM进行身份验证限制,是一个针对恶意WPAD代理服务器的有效对策,因为Responder将尝试使用NTLM身份验证来捕获凭据。

19.png

Windows 10 RS5(1809)在这方面存在一些问题,默认情况下,系统会启动自动代理发现。

20.png

此外,WinHTTP Web代理自动发现服务(WinHTTP Web Proxy Auto-Discovery Service)默认是运行的,其运行过程中需要依赖。

21.png

我建议关闭代理页面上的“自动检测设置”选项。如果必须要启用这个选项,那么我建议部署一个持续启用的VPN连接,并带有免费Wi-Fi热点,以防止无意中泄露密码哈希值。

如果后续再发现有其他需要注意的地方,或者各位读者提出了任何其他建议,我都会再对这篇文章进行更新。

本文翻译自:https://medium.com/@rootsecdev/an-in-depth-look-at-server-2019-and-windows-10-rs5-security-baselines-52508a986c16如若转载,请注明原文地址: http://www.4hou.com/system/14166.html
点赞 0
  • 分享至
取消

感谢您的支持,我会继续努力的!

扫码支持

打开微信扫一扫后点击右上角即可分享哟

发表评论