针对Azure AD Kerberos 的反弹票据和碘化银攻击

Azure 活动目录（Azure AD）Kerberos 是kerberos身份验证协议的云版本，是专门为在Azure云平 台上工作而构建的。

在云计算之前的时代，Kerberos（以及之前的NTLM）是企业环境中大多数到所有身份验证的核心协议。然而，随着不断地向云化迁移，尤其是随着SaaS应用程序、云工作负荷和传统的基础设施的混合使用 ，改变了这一点。如今，SaaS应用程序的常见做法是向基于云的身份提供商进行身份验证，比如 Azure AD。而本地工作负载仍然对具有Kerberos等传统协议的AD进行身份验证。

因此，像Azure虚拟桌面和Azure文件等云基础设施的认证虽然本身不属于本地AD域，但依然依赖相关技术。
新的Azure AD Kerberos 认证协议设计旨在克服这种依赖性，将云工作负荷引流到Azure AD云原生认证基础设施，因此在云Azure资源和本地Windows协议以及应用（例如SMB、RDP、RPC等等）之间引入一个光滑的集成。 通过这种方式，组织可以整合所有的云资源的身份认证，无论是SaaS应用还是Azure Ad中的基础设施的工作负荷。

然而，Azure AD Kerberos仍然与它的前辈本地Kerberos有很多相似之处。在这篇白皮书中，我们分享已经进行的研究，来判断现有的针对传统kerberos协议的攻击技术是否适用于新的修改后的Azure AD Kerberos。研究结论是存在两种新的攻击技术。第一种是调整后的臭名昭著的PTT攻击，我们称之为反弹票据。第二种是调整后的银票攻击，我们称之为银碘化攻击。这篇白皮书详细介绍了两种攻击细节和缓解措施。

本着负责的态度，我们在披露前已经与微软MSRC团队沟通了这两种技术，非常感谢其花费时间精力来确认和审批允许我们公开。

Kerberos 回顾

Kerberos是一种现代的值得推荐的企业认证协议，它包括三个独立的保护过程（就像三头狗 Cerberus），它们共同提供一个安全通道来传输身份验证消息。该协议基于票据交换，每个过程都为确认身份验证不同阶段提供了保证。密钥分发中心（KDC）管理身份验证过程，监督给认证客户票据的分发、用户口令的验证和服务票据的分发。一般情况下，KDC基于对称密钥密码体制完成其加解密过程，但也可以选择使用非对称密体制 。

下面是Kerberos的三个过程实现：

获取TGT（AS过程）

这是Kerberos认证的第一阶段，客户端需要提供一个有效的口令来接受一个可以验证其完整性的票据（TGT）。这个TGT (Ticket granting ticket) 是由由认证服务加密的，并且是唯一可以验证一张给定的TGT票据完整性的验证者。在TGT票据还附加了一个Session Key，Session Key是TGS服务加密过程中使用的。该Session Key经用户口令加密，因此用户可以解密消息获得Session Key，进行下一步TGS请求的验证。

获得ST（TGS过程）

在Kerberos身份验证的第二阶段中，用户向KDC请求TGS服务。这类型的票据将用于特定的服务。在活动目录中，已注册的服务称为服务主体名称（SPN），其约定惯例格式为：服务类/主机。要验证一个ST，需要一个共享的密钥——服务器的私钥。在Windows机器中，此密钥被保存在注册表中的Security Hive中。在其他平台和第三方应用程序中，微软提供导出一对（SPN和服务器的私钥）称之为Keytab。TGS 票据用服务器的私钥加密并包含一个保存着关于客户端的授权数据这特权属性证书（PAC）。这个信息无法被编辑或修改，因为只有服务器知道其自己的私钥。

服务申请（AP过程）

身份认证的最后一个阶段是Application Request（AP）阶段。客户端通过预定协议（例如HTTP、SMB、RPC、RDP等）直接发送AP-REQ到服务器，这里面包含ST，在服务侧，ST经过KDC分发的服务端私钥解密。通过这种方式，服务端可以验证客户端票据来自于正确的KDC。解密成功后，服务器通过审核PAC来确定客户端是否被授权访问服务并做出应答。

Kerberos 认证过程

Azure AD Kerberos 简介

Kerbeos通过两个服务完成其身份认证过程：

  • Authentication Service（AS）：负责验证用户口令；
  • Ticket Granting Service（TGS）：负责向不同的域资源授予身份验证票据，并向服务器提供关于用户的详细信息。
    Azure AD Kerberos 一样如此，但也有几点主要的修改：

黑客帝国-墨菲斯：选择你的命运？ 红色药丸（云） 蓝色药丸（本地）

客户端到KDC的通信加密

在Azure AD Kerberos中，KDC（包括AS和TGS）转到了云上，因此，客户端无法通过明文信道与KDC交互。因此，Azure AD 利用 KDC Proxy Kerberos Extension（MS-KKDCP）在一个TLS隧道中传输Kerberos Message。

KDC Proxy Cloud Domain Mapping

当你注册到了Azure AD， Windows 划定一个域（windows.net）到KERBEROS.MICROSOFTONLINE.COM 中，基于这种划分，当用户尝试访问资源时，就需要windows.net域中的Kerberos认证。KDC Proxy协议就是Azure-Based KDC用来提供在KERBEROS.MICROSOFTONLINE.COM中的ST的协议。

KerbTopLevelNames字段用于在云资源到云KDC之间进行映射

解耦身份认证与TGS服务

微软拆分了AS服务和TGS服务，所以现下，云TGT可以与在登录到Azure AD时获得的主刷新令牌（the Primary Refresh Token，PRT）一起检索。当到 login.microsoonline.com//oauth2/token 的post请求与一个头部字段字段tgt=true一起发送时，Azure AD 会响应一个TGT。这个响应包含一个加密的二进制块，其中有PRT和krbtgt. TGS过程由客户端发起一个KDC Procy定义的TGS请求（login.microsoonline.com//Kerberos）以及TGT，就像传统的Kerberos请求一样。

使用Kerberos Proxy的TGS 请求

最后，Azure Files等兼容资源接受Kerberos 的AP-REQ(Application request)发送已取得的ST。

看起来，Azure AD Kerberos在安全性上投入了大量的思考和努力。第一个安全增强是AS和TGS端点的分离，通过一个更强大的安全机制来保护krbtgt密钥，避免金票攻击。第二个安全增强是使用KDC代理和基于TLS的加密通信层在web上传输认证信息。然而，Azure AD Kerberos 相比于本地版本是否对常见的漏洞和攻击技术做了更好的防护呢？让我们进一步探索。

攻击Azure AD Kerberos协议

我们介绍两种我们发现的新的攻击技术，这两种技术利用了这些修改中的弱点，我们称之为反弹票据攻击和碘化银攻击。

反弹票据攻击

PTT攻击回顾

Kerberos的一个主要的安全问题是其在lsass进程中缓存的票据（ in-memory ticket caching），这个机制在Azure AD Kerberos中并没有得到修复。一旦对手获取了Windows机器的控制权，他们可以从内存中得到TGT，然后使用这个TGT来请求任意他们希望获得的Kerberos ST。这种攻击被称为PTT。

PTT攻击

反弹票据

我们称Azure AD Kerberos中的PTT攻击为Bounce the Ticket攻击，他们确实非常相似。首先我们从内存中提取TGT用来访问云上TGS而非本地TGS。我们获得的票据可以用来访问云上的依赖于Azure AD Kerberos的资源。

在混合环境中，本地AD和Azure AD Kerberos domain 均被使用着，一个攻击者可以利用反弹票据攻击来从本地环境跨到Azure AD管理的云环境中。

Rubeus 攻击实践

尽管该攻击非常像本地PTT攻击，但依然略有不同，需要改变现有的攻击工具来使得攻击更加容易。我们选择Rubeus，一个由GhostPack编写用来进行Kerberos交互和滥用的工具。下面的改动使得Rubeus更适应Azure AD Kerberos：

  • 将Realm修改为KERBEROS.MICROSOFTONLINE.COM来适应云环境；
  • 加密的PAC username field 修改为包含完整的UPN（跟在original domain name后）
  • 修改登录服务器为login.microsoftonline.com
...
}
kvi.LogonServer = new Ndr._RPC_UNICODE_STRING("login.microsoftonline.com");
if (!String.IsNullOrEmpty(displayName))
{
...

LogonServer 修改

幸运的事，Rubeus 已经支持KDC Proxy扩展了，因为其本身也不是一个新的扩展，而且经常用来服务应用通过WEB查询Kerberos这一过程。

尝试使用Rubeus进行攻击：

  • 使用mimikatz或者其他的攻击工具导出内存中的云TGT票据
mimikatz# Privilege::debug
mimikatz# sekurlsa::ticket /export

mimikatz 使用

  • 使用导出的票据向云KDC请求ST，并将ST注入lsass进程
Rubeus.exe asktgs /ticket:ticket.kirbi /service:cifs/AzFilesShare.file.core.windows.net 
/proxyurl:https:/ /login.microsoonline.com/tenantID/kerberos /enctype:AES256 /ptt
  • 直接访问目标服务
  • 成功

反弹票据（Bounce-the-Ticket BTT）攻击

碘化银攻击

我们继续介绍一种攻击技术：本地白银票据攻击允许攻击者利用一个窃取的服务器Key来伪造票据，该票据可以以任意权限访问服务器。

银票回顾

在经典的本地银票攻击中，攻击者首先获取一个服务器的Kerberos Key（机器账户的Hash）这个Key可以通过很多技术方式获取，例如Kerberoasting. 一旦攻击者获得了这个Key，就可以伪造ST。因为在Kerberos中ST是由Server Key加密的，所以攻击者可以利用该Key伪造该服务器的ST。举例，一个攻击者可以生成一个攻击者压根没有改username的认证信息的身份或一个提升了攻击者控制的账号的初始权限的身份所对应的票据，这就导致了攻击者可以以管理员身份访问目标服务。

银票攻击

碘化银攻击技术

碘化银攻击技术与本地银票攻击类似，但也有一些不同。这种技术适应云化的主要挑战是在Azure AD Kerberos中，服务器的密钥是由Azure使用加密强随机数生成器生成的。这意味我们不能依赖于过去的基于弱密钥的攻击，例如Kerberoasting攻击。我们必须通过其他方式获取Server Key。获取服务器密钥的特定方式因受到攻击的应用程序而有所不同。对于这个演示，我们分析了Azure文件中的一个安全缺陷。
为了使得本地银票攻击技术适应云环境，我们修改了Rubeus 的银票生成方法，且将所需领域到修改到匹配KERBEROS.MICROSOFTONLINE.COM，还有修改了LogonServer，还有就是使用获得的Key伪造我们自己的碘化银票据。

利用碘化银攻击技术攻击Azure Files

Azure Files介绍及其如何使用Azure AD Kerberos

Azure Files 是一个基于云的serverless文件共享服务，相当于云化的SMB文件共享。该共享可以以不同的方式使用。在我们的上下文中，最感兴趣的是从Azure虚拟桌面访问Azure Files。因为这种访问可以使用SMB与Kerberos认证协议，通过Azure AD Kerberos来完成。

对Azure Files的碘化银权限提升攻击

Azure文件共享被配置在Azure Portal中，在Azure AD Kerberos 的预览版中，用户被要求通过powershell命令配置一个存储账户Key，该Key扮演者着Kerberos 存储私钥的角色。

Azure AD Kerberos 预览版文档

在GA版本中，不再需要该命令，而是在配置Azure Files时自动完成配置。

该密钥也可以稍后使用以下powershell命令提取：

$kerbKey1 = Get-AzStorageAccountKey -ResourceGroupName $resourceGroupName -Name 
$storageAccountName -ListKerbKey | Where-Object { $_.KeyName -like "kerb1" }

这两条命令同时适用于预览版和GA版本。

显然，攻击者并不一定需要拥有对该资源的权限来运行Get-azstorageAccountKey命令，只需要成为以下组之一的成员即可：

  • Owner
  • Contributor
  • Avere Contributor (Microsoft.Storage/storageAccounts/)
  • DevTest Labs User
  • Disk Snapshot Contributor
  • Log Analytics Contributor
  • Logic App Contributor
  • Reader and Data Access
  • Storage Account Contributor (Microsoft.Storage/storageAccounts/)
  • Storage Account Key Operator Service
  • Virtual Machine Contributor

这些组也不一定与拥有访问资源本身中的数据的权限有关，比如DevTest Labs用户。

IAM截图

所以为了获得权限提升，我们需要做的是：

  • 获取以上组中一个弱认证的用户；
  • 使用该用户权限通过powershell命令在Azure Files中提取Kerberos Server Key；
  • 使用Rubeus工具结合我们获取的Server Ticket伪造到Azure Files的ST；
  • 控制Azure Files中的目标信息。

最后，我们将修改了Rubeus 的银票生成方法，且将所需领域到修改到匹配KERBEROS.MICROSOFTONLINE.COM，还有修改了LogonServer，还有就是使用获得的Key伪造我们自己的碘化银票据。

碘化银攻击

缓解措施

鉴于当前还没有补丁来修复导致这些攻击的问题，我们推荐下列环节措施：

  • 检查并监视对Azure访问控制（IAM）的任何更改以及共享的访问控制权限，以验证仅被授权的用户具有对Microso.ClassicStorage/storageAccounts/listKeys/action - Kerberos key 提取操作的权限。
  • 为避免反弹票据攻击，可以减少计算机允许存储的云TGTs到最低数量限度（最小化权限），可以通过限制"Allow retrieving the Azure AD Kerberos Ticket Granting Ticket during logon"组策略到使用Azure AD Kerberos安全组.
posted @ 2023-02-03 15:01  斑林鸽的代码世界  阅读(203)  评论(0)  编辑  收藏  举报