漏洞簡介

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

公司主營業(yè)務(wù)：成都網(wǎng)站建設(shè)、網(wǎng)站建設(shè)、移動網(wǎng)站開發(fā)等業(yè)務(wù)。幫助企業(yè)客戶真正實現(xiàn)互聯(lián)網(wǎng)宣傳，提高企業(yè)的競爭能力。成都創(chuàng)新互聯(lián)是一支青春激揚、勤奮敬業(yè)、活力青春激揚、勤奮敬業(yè)、活力澎湃、和諧高效的團(tuán)隊。公司秉承以“開放、自由、嚴(yán)謹(jǐn)、自律”為核心的企業(yè)文化，感謝他們對我們的高要求，感謝他們從不同領(lǐng)域給我們帶來的挑戰(zhàn)，讓我們激情的團(tuán)隊有機(jī)會用頭腦與智慧不斷的給客戶帶來驚喜。成都創(chuàng)新互聯(lián)推出錦屏免費做網(wǎng)站回饋大家。

AD CS身份識別

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

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

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

嘗試修改用戶的UPN屬性，如果能夠?qū)⒃搶傩孕薷臑锳D管理員賬號的UPN，則可以實現(xiàn)欺騙AD CS獲取AD管理員權(quán)限證書，但是實際上DC會對UPN檢查保持全林唯一。

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

漏洞分析復(fù)現(xiàn)

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

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

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

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

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

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

• 已驗證的到DNS主機(jī)名的寫入
• 已驗證的到服務(wù)主體名的寫入
• 已驗證的到計算機(jī)屬性的寫入

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

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

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

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

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

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

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

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

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

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

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

痕跡信息

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

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

總結(jié)

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

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

當(dāng)前標(biāo)題：CVE-2022–26923漏洞分析
當(dāng)前網(wǎng)址：http://uogjgqi.cn/article/djgodji.html