频道栏目
首页 > 安全 > 网络安全 > 正文

浅析Kerberos 约束委派SPN的安全漏洞

2017-03-21 09:36:00      个评论      
收藏   我要投稿

浅析Kerberos 约束委派SPN的安全漏洞。在过去几年中,越来越多的安全研究人员开始研究Kerberos的安全性,最终发现了在支持该认证协议的网络环境中的很多有趣的攻击方式。

在本文章中,我将介绍我在Windows的Kerberos约束委派功能中的一些发现(这些安全问题仍然未解决)以及在考虑使用或测试此技术时可能会用到的服务主体名称(SPN)过滤特性。我也会分享一些你可以拿去测试用的代码。如果你想获取更多有关Kerberos技术的信息,你可以查看Kerberos的 RFC文档 或其他更高级的 相关教程 。

虽然我已经针对Kerberos的安全性做了一段时间的研究,但是促使我开始这项特殊的研究工作的原因是我拜读了Ben Campbell 的一篇文章——“ Trust? Years to earn, seconds to break ”,这是一篇非常不错的文章。在阅读Ben的文章时,他描述了一种比较实用的用于攻击Active Directory网络环境的姿势,即攻击者可以尝试获取具有TRUSTED_TO_AUTHENTICATE_FOR_DELEGATION特性的域帐户的凭据。他在文章中提到他无法使用我们CoreSecurity开发的 Impacket 库中的 secretsdump.py 工具完成其中的一个攻击步骤。 Impacket库在我们的一些产品中被广泛使用,也已经作为安全社区中的独立库和工具使用。由于是我开发的这个脚本(增加Kerberos支持),所以我想看看可能需要修复的问题。

好了,以上应该足够解释一些基本的内容了,让我们进入本文的主题吧:

Kerberos约束委派

试想一个如下图所示的名为FREEFLY.NET的网络域场景:

\

图1 – 我们在FREEFLY.NET域中的测试环境

一个正常用户(normaluser@freefly.net)访问Web服务器进行身份验证,然后该Web服务器从第三方服务器(名为fileserver.freefly.net)获取了一些内容。那么问题来了,Web服务器是如何验证文件服务器从而进行内容获取的?有以下几个选项:

使用一个普通的用户(可能是serviceuser@freefly.net)使用刚刚访问Web服务器进行身份验证的用户的身份即normaluser@freefly.net你所想到的任何其他方式:)

第二个选项对于在此场景链路的最后一跳(在这种情况下是文件服务器)中需要客户端用户的原始身份标识的情况看起来很有趣。这可能是出于审计目的或强制使用更好的授权权限所必需的。

为了在这种情况下能正常工作,serviceuser@freefly.net需要有特殊的权限,以允许它模拟客户端用户,然后代表该用户验证文件服务器。

总之,这就是Kerberos委派的目的。在Windows Server 2003之前,设置一个像上述这样的场景的唯一方法是给serviceuser@freefly.net“几乎”像任何用户对域中的“几乎”是任何服务器进行身份验证的能力(我说“几乎”是因为有一些限制它的方法,但大多数时候是没有使用的)。 Sean Metcalf在一篇 文章 中介绍了“无约束委派”功能的一些危险性。

因此,为了解决与无约束委派相关的问题,Microsoft引入了Kerberos约束委派,允许指定你所授予委派权限的帐户提供的服务是否允许提供委托凭证。这在服务帐户的委派选项卡中进行配置。在我们的例子中,应该有一个cifs / fileserver.freefly.net的条目:

\

图2 – 为serviceuser@freefly.net设置的约束委派

那么,问题又来了,如果由于任何原因导致serviceuser@freefly.net账户的凭据被泄露又会发生什么?例如,该帐户的登录凭证被破解的可能的方式之一是通过发起Kerberoast攻击(更多信息参见Tim Medin在DerbyCon上的 议题 ),当然也包括其他攻击方式。

理论上来讲,攻击者使用该帐户将能够作为任何用户但只能够针对服务cifs/fileserver.freefly.net进行认证。

上一篇:沙盒逃逸技术详解(二)
下一篇:针对利用DNS的TXT记录查询进行通信绕过杀软检测的木马分析
相关文章
图文推荐

关于我们 | 联系我们 | 广告服务 | 投资合作 | 版权申明 | 在线帮助 | 网站地图 | 作品发布 | Vip技术培训

版权所有: 红黑联盟--致力于做实用的IT技术学习网站