是否应将渗透测试报告发送给MSRC?微软安全响应中心指南

本文探讨了渗透测试报告提交给微软安全响应中心(MSRC)的适用场景,重点分析了Lync Server 2013的暴力破解漏洞案例,并提供了包括密码策略、账户锁定、日志审计和Web应用过滤在内的多层防护方案。

是否应将渗透测试报告发送给MSRC?

每天,微软安全响应中心(MSRC)都会收到来自安全研究人员、技术/行业合作伙伴和客户的漏洞报告。我们欢迎这些报告,因为它们有助于我们提升产品和服务的安全性。包含概念验证、攻击细节或漏洞演示的高质量报告极具帮助性和可操作性。如果您向我们发送这些报告,我们表示感谢!

客户为评估和加固其环境,可能会请渗透测试人员探测其部署并报告发现。这些报告可帮助客户发现并纠正部署中的安全风险。

关键在于,渗透测试报告的发现需要在客户的组策略对象、缓解措施、工具和检测实施的背景下进行评估。发送给我们的渗透测试报告通常包含产品易受攻击的声明,但缺乏关于攻击向量或漏洞利用方式的具体细节。通常,客户可用的缓解措施无需更改产品代码即可修复已识别的安全风险。

让我们看一个Lync Server 2013部署的渗透测试报告示例结果。这一常见报告发现未提及已有的缓解措施。

哇——我的部署易受暴力破解攻击?

在此场景中,客户部署了具有拨入功能的Lync Server 2013。部署包括多个Web端点,允许用户加入或安排会议。客户请求渗透测试并收到报告,其中指出“通过Lync实例可能进行密码暴力破解”。

让我们更详细地看看这一点。

Lync Server 2013利用某些Web端点进行Web表单身份验证。如果这些端点未安全实施,可能为攻击者与Active Directory交互打开大门。分析客户部署的渗透测试人员经常识别此问题,因为它代表客户环境的风险。

端点将身份验证请求转发到以下SOAP服务 /WebTicket/WebTicketService.svc/Auth。该服务使用LogonUserW API将请求的凭据验证到AD。

在此场景中,暴露身份验证端点时,客户面临暴力破解攻击风险。

这不是一个无法解决的问题。在具有用户账户缓解措施(如密码锁定策略)的环境中,这将导致目标用户的临时拒绝服务(DoS),而不是让其账户被入侵。对用户来说很烦人(如果持续发生,可能是主动攻击的红旗),但不如账户被入侵严重。

通过公开暴露的端点缓解暴力破解AD攻击

我们倡导深度防御安全实践,考虑到这一点,以下是当此类端点公开暴露时加强防御的几种缓解措施。

实施强密码策略

实施强密码策略有助于防止使用易猜和常用密码的攻击。在线有数百万密码的字典,强密码在防止暴力破解方面大有帮助。微软关于密码策略(和个人计算机安全)的指南发布在此处 - https://www.microsoft.com/en-us/research/publication/password-guidance/ - 并基于保护Azure云时获得的研究和知识提供了一些很好的提示。

实施账户锁定策略

保护环境并利用强密码策略的第二步是实施账户锁定策略。如果攻击者知道用户名,他们就有了进行暴力破解攻击的立足点。锁定账户增加了基于时间的攻击复杂性,并为目标增加了可见性。想象尝试登录您自己的账户,并被告知它已被锁定。您的第一步是联系您的IT/支持组或使用自助解决方案解锁账户。如果这种情况持续发生,就会引发红旗。关于账户锁定策略的指南和信息可以在我们的博客中找到*-*https://blogs.technet.microsoft.com/secguide/2014/08/13/configuring-account-lockout/

记录(和审计)访问尝试

检测和防止此行为的另一步骤涉及事件记录和审计,这可以在多个位置完成。根据边缘或 perimeter 保护,Web应用程序过滤或防火墙级别的速率限制可以降低暴力破解攻击成功的机会。丢弃的登录尝试或数据包可以缓解来自单个IP或IP范围的攻击。

审计账户登录尝试

在任何用于身份验证的服务器上,组策略审计账户登录事件可以提供对任何密码猜测尝试的可见性。这是任何网络环境的最佳实践,不仅仅是那些需要身份验证的基于Web的端点。通过组策略审计保护Active Directory环境的指南可以在我们的指南中找到*-*https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/monitoring-active-directory-for-signs-of-compromise

使用Web应用程序过滤规则

当上述建议之一不可行时,可能需要替代缓解措施来降低环境中的风险。为验证潜在缓解措施的可行性,我们为Lync Server 2013设置了一个测试环境,使用IIS ARR(应用程序请求路由)反向代理来测试要求:

  • 外部禁用Windows身份验证
  • 外部允许匿名用户登录

在此环境中,以下“Skype for Business Server External Web Site”下的Web应用程序通过使用IIS重写规则在反向代理上返回错误代码403被阻止:

  • Abs
  • Autodiscover
  • Certprov
  • Dialin
  • Groupexpansion
  • HybridConfig
  • Mcx
  • PassiveAuth
  • PersistentChat
  • RgsCients
  • Scheduler
  • WebTicket/WebTicketService.svc/Auth

以下Web应用程序在反向代理中未被阻止:

  • Collabcontent
  • Datacollabweb
  • Fonts
  • Lwa
  • Meet
  • Ucwa

在此环境下 - 会议Web应用程序上的Windows身份验证被阻止,登录失败。匿名用户可以加入会议,并仍然使用以下模式工作:

  • 会议中的聊天消息
  • 白板
  • PPT共享
  • 投票
  • 问答
  • 文件传输
  • 桌面共享

每个客户都需要考虑外部用户所需的功能。在提供的示例中,这假设您不需要以下外部功能:

  • 拨入页面(共享拨入号码等)
  • Web调度程序
  • PersistentChat
  • Rgsclients
  • 混合PSTN(使用本地PSTN基础设施的Skype for Business)
  • 无移动客户端用户

作为参考,我们包含了一个阻止外部访问Dialin文件夹的示例规则。规则存储在ApplicationHost.config文件中,规则添加到configuration/system.webserver/rewrite/globalrules/部分。

1
2
3
4
5
6
7
8
<rule name="BlockDialin" patternSyntax="Wildcard" stopProcessing="true">
  <match url="*" />
  <conditions logicalGrouping="MatchAny" trackAllCaptures="false">
    <add input="{HTTP_HOST}" pattern="dialin.foo.bar.com" />
    <add input="{REQUEST_URI}" pattern="/dialin/*" />
  </conditions>
  <action type="CustomResponse" statusCode="403" statusReason="Access denied." statusDescription="Access denied." />
</rule>

关于IIS中Lync服务器的应用程序请求路由(ARR)的额外指南可以在我们的博客中找到*-* https://blogs.technet.microsoft.com/nexthop/2013/02/19/using-iis-arr-as-a-reverse-proxy-for-lync-server-2013/

渗透测试报告的最佳用途

建议将取决于环境的配置方式,最好在将结果分享到组织外部之前深入研究报告中可用的缓解措施。如果报告发现了一个没有缓解措施的未修补漏洞,请将报告和POC发送给我们。

更多信息,请访问我们的网站 www.microsoft.com/msrc

本文由微软安全中心团队成员–Christa Anderson、Saif ElSherei和Daniel Sommerfeld;以及来自IDC Skype Exchange R&D的Pardeep Karara和来自OS、Devices和Gaming Security的Caleb McGary共同撰写。

comments powered by Disqus
使用 Hugo 构建
主题 StackJimmy 设计