漏洞簡介

2022年5月10日，微軟發(fā)布補丁修復了一個 AD域權限提升漏洞（CVE-2022–26923）。該漏洞是由于在申請證書時對AD域中的計算機賬戶身份審核不夠嚴格，經(jīng)過身份驗證的攻擊者可以操縱他們擁有或管理的計算機帳戶的屬性，假冒DC從AD CS 服務器獲取DC證書，最終導致普通權限用戶提升至域管理員權限。這一漏洞最早由安全研究員Oliver Lyak在2021年12月14日報告給微軟，微軟在2022年5月的安全更新中對其進行了修補。

AD CS身份識別

默認情況下，CA允許域用戶注冊User模板證書，允許域計算機注冊Machine模板證書。兩個證書模板都允許客戶端身份驗證。這意味著頒發(fā)的證書可用于通過PKINIT Kerberos 擴展對KDC進行身份驗證。

通過對比User和DomainController兩個模板的msPKI-Certificate-Name-Flag屬性可以看到User模版包含SUBJECT_ALT_REQUIRE_UPN，DomainController包含 SUBJECT_ALT_REQUIRE_DNS。這兩個字段分別標識證書中的用戶和計算機的身份，用于CA識別證書的所有者。

如當我們使用User模板請求證書時，用戶帳戶的UPN將嵌入到證書中。在進行進行身份驗證時，KDC會嘗試將 UPN 從證書映射到用戶。

嘗試修改用戶的UPN屬性，如果能夠將該屬性修改為AD管理員賬號的UPN，則可以實現(xiàn)欺騙AD CS獲取AD管理員權限證書，但是實際上DC會對UPN檢查保持全林唯一。

雖然UPN無法假冒，但是不代表dnsHostName不可以假冒。在MS-ADTS（3.1.1.5.1.3 唯一性約束）文檔中并沒有標識dnsHostName屬性具有唯一性。實際上，通過下面的漏洞分析也可以發(fā)現(xiàn)實際這個屬性可以重復，這也是這個漏洞產(chǎn)生的主要原因。

漏洞分析復現(xiàn)

成功利用該漏洞需要滿足以下幾個必要條件：

• 攻擊者獲取到一個通過認證的普通域用戶憑據(jù)或計算機賬戶憑據(jù)
• AD 域內已配置了 AD CS 服務
• Machine模板證書可以自動申請

首先第一步需要獲得一個已知憑據(jù)的計算機賬戶，如果沒有可以使用普通賬戶通過Impacket創(chuàng)建一個新的計算機賬戶。

默認情況下每個普通用戶都擁有添加10個機器賬戶的權限，添加機器權限可以通過編輯組策略控制，在Windows Server 2012以下版本的DC可以通過用戶的屬性 MS-DS-Machine-Account-Quota設置可添加計算機賬戶的數(shù)量。

嘗試直接修改機器的dnsHostName，提示出現(xiàn)操作錯誤（無法更新屬性值），但是沒有提示唯一性錯誤，因此可以猜測該值可以修改為DC的dnsHostName，但是出于某種限制，如值的類型不對或者是有某種對象的值依賴于該值導致無法成功更新修改到AD。

觀察使用賬戶test3創(chuàng)建的主機，發(fā)現(xiàn)其ACL信息非常有意思。雖然是test3創(chuàng)建的計算機賬戶，但是機器賬戶的所有者卻是Domain Admins賬戶。機器賬戶的中幾條ACL信息非常有價值，分別是：

• 已驗證的到DNS主機名的寫入
• 已驗證的到服務主體名的寫入
• 已驗證的到計算機屬性的寫入

這證明創(chuàng)建計算機賬戶的用戶賬戶是有計算機賬戶的dnsHostName、servicePrincipalName和其他屬性的寫權限，因此修改dnsHostName屬性值在ACL權限上是可行的。

通過普通域用戶對其創(chuàng)建主機的dnsHostName進行修改，將值修改為一個不存在的主機名發(fā)現(xiàn)成功，因此實現(xiàn)本漏洞的關鍵是如何繞過限制進行修改。

在將dnsHostName從mc7.moin.com修改為xxx.moin.com時，發(fā)現(xiàn)該計算機賬戶的servicePricipalName屬性也發(fā)生了變化，其中的兩個字段包含了新的dnsHostName。可以推測這個屬性對dnsHost Name有依賴。

查看微軟的官方文檔https://docs.microsoft.com/en-us/windows/win32/adschema/r-validated-spn，發(fā)現(xiàn)官方對servicePrincipalName屬性的描述為“驗證寫入權限以啟用符合計算機 DNS 主機名的 SPN 屬性設置”，因此猜測是該屬性中對應的值中包含現(xiàn)有的dnsHostName，嘗試刪除servicePrincipalName中包含hostHostName的值，也可直接刪除servicePrincipalName屬性。

在刪除后，通過修改dnsHostName屬性值為DC的dnHostName，發(fā)現(xiàn)修改成功。

現(xiàn)在成功獲得一個dnsHostName與域控相同的機器賬戶，由于創(chuàng)建賬戶時指定了賬戶密碼，因此可以利用該賬戶欺騙AD CS獲取域控權限證書。

該漏洞的主要實現(xiàn)過程可以總結為以下幾步：

• 獲取一個已知密碼的計算機賬戶
• 刪除計算機賬戶的servicePrincipalName屬性或刪除其中與dnsHostName有關的值
• 修改dnsHostName為DC的dnsHostName

最后使用該機器賬戶向AD CS服務器申請模版為“Machine”的證書并保存的本地，此時獲取的實際是DC權限的證書。

使用該證書申請TGT,能夠成功獲取域控賬戶的NT Hash,說明證書有效。這說明成功的從普通域用戶權限提升到了域控權限。

查看AD CS服務器中的證書申請記錄，也可以看出AD CS認為認為頒發(fā)的證書為DC。

痕跡信息

在進行修改dnsHostName值時，會在域控產(chǎn)生事件ID為5136的目錄服務更改日志。其中的特征為將計算機對象的dNSHostName值修改為DC的名稱。

同時會產(chǎn)生事件ID為4742的計算機管理審核成功日志，日志信息中包含了被修改的計算機賬戶信息和修改后的dnsHostName信息。如若使用此漏洞后需要進行痕跡清理，這兩條日志最為關鍵。

總結

本次漏洞產(chǎn)生的主要原因是計算機賬戶關鍵屬性的ACL設置問題和AD CS檢查客戶端身份不嚴格導致，結合之前的samAccountName欺騙漏洞，AD域中涉及身份認證標識的問題不止一次，微軟在AD域中不用具有唯一性的自動編號字段SID而是其他字段作為身份認證標識在安全方面著實欠妥。

本次漏洞利用簡單，流量特征不明顯難以檢測，同時獲取的AD域證書有效時間長，因此對于AD域的提權和權限維持都有很高的利用價值。