觀點

CVE-2022-26923:Active Directory網域權限提升漏洞修補分析

2022 / 05 / 20
投稿文/ 創泓科技
CVE-2022-26923:Active Directory網域權限提升漏洞修補分析
Tenable安全應變團隊發布微軟五月第二週的漏洞修補文章中詳細說明了本月微軟修復的多個嚴重漏洞,其中就有Active Directory網域權限提升漏洞(CVE-2022-26923 )允許較低權限用戶在安裝了Active Directory認證服務(AD CS)的服務環境中,從一般權限用戶提升至網路管理員權限。
 
該漏洞在5月11日被研究人員Oliver Lyak發現並公開了漏洞及技術相關細節後,引發安全從業人員的廣泛關注並被相關從業人員快速整理出開漏洞的環境。

雖然預設情形下不會為Active Directory環境安裝AD認證服務,但根據企業環境中的實際案例,該認證仍然被廣泛部署,並且錯誤的認證服務配置則有滿巨大的安全風險存在。

漏洞分析

CVE-2022-26923 漏洞影響所有Windows Server版本中的AD網域控制服務。攻擊者可以利用該漏洞在有安裝AD認證服務的環境中仿冒另一個主機並代表該帳戶發送認證,進而導致主機帳戶還有網域控制權限被接管,這的確是有效為攻擊者提供了一個完整的網域環境。

Tenable還原了基本的程序,這種特權提升過程對於攻擊者來說花的工非常小,這意味著攻擊者可以利用此漏洞所需要的技術知識不用特別高,基本步驟如下:
  • 找到擁有AD認證服務的任意Windows版本服務器
  • 獲得已洩露的較低權限AD用戶憑證(Domain User即可)
  • 使用這些憑證在網域中註冊新主機/機器人帳戶(Machine Account)
  • 將主機對象的dNSHostName屬性更改為特權主機(例如網域控制器)的主機名屬性
  • 刪除SPN屬性值,繞過竄改後的屬性值衝突
  • 使用默認範本請求主機認證
  • 使用收到的樣版執行Kerberos身份認證,現在作為特權機器帳戶,而並非是我們的假機器帳戶

客戶端認證

系統註冊認證用戶樣版,在網路中有很多範例,對於CVE-2022-26923 和 AD認證服務,利用白皮書中發現的錯誤配置,主要關注的是客戶端身份驗證案例。

客戶端身份驗證允許認證的所有使用者用它來驗證他們自己在AD中的身份驗證。例如,客戶端認證用於針對Web應用程序進行身份驗證。身份驗證需經過Kerberos進行驗證。如果我們有一個具有客戶端身份驗證EKU的有效認證,我們可以與AD認證服務和密鑰分發中心交換,以請求一個Kerberos TGT,然而可以將其用於進一步的身份驗證。

如果有有效的認證,攻擊可以利用它來生成一個TGT模擬另一個用戶或系統。本質上來說,我們希望能夠修改認證請求的SAN屬性以指向具有執行權限提升的更多關於人事物相關的其他權限。

預設認證樣版

預設安裝情況下,當AD認證服務安裝在環境中,兩個認證樣版可用在支持客戶端身份驗證的請求:
  • 用戶認證樣版-屬於網域用戶中任何用戶都可以請求此認證樣版
  • 機器認證樣版-屬於區域主機中的任何主機都可以請求此驗證認證樣版
預設安裝情況下,用戶樣版不易受到攻擊。當根據用戶樣版請求認證時,用戶帳戶的用戶主體名稱(UPN)將坎入可用於識別SAN。由於UPN必須是唯一的,而且無法修改,因此無法利用此樣版。此外,由於無法更改認證簽名請求SAN值,無法通過指定期UPN來模擬其他用戶。

但是主機帳戶沒有UPN。機器樣版不使用UPN進行身份驗證,而是使用DNS名稱進行識別和身份驗證。當通過機器樣版為機器請求認證時,AD認證服務將DNS名稱坎入到SAN中,然後用於身份驗證。

預設網域用戶權限

預設情況下,任何AD帳戶用戶最多可以在網域中註冊10台主機。這通常是在企業組織中用於允許用戶攜帶自己的設備(BYOD)並將其註冊以在網域中使用。這本身並不是一個真正的漏洞,一旦CVE-2022-26923漏洞結合該配置,會導致提升權限攻擊路徑。

當在AD中註冊新的主機時,用戶被分配到該主機的所有權者,這提供了對與該主機關聯的AD對像某些權限。這裡有兩個權限特別會導致問題:
  • 驗證寫入DNS主機名-此權限允許使用者更新與主機關聯的AD對象的DNS主機名
  • ​驗證寫入服務主機名稱(SPN)-此權限允許使用者更新與主機關聯的AD對象的SPN
Kerberos身份驗證使用SPN將服務實際案例與服務登錄帳號有相互關聯。默認情況下,主機AD對象接收與其名稱相關聯的SPN,已允許Kerberos身份驗證,主機需要該身份驗證,才能針對AD執行特定請求。SPN必須是唯一的,這意味著不允許兩個AD對象擁有相同的SPN。

這可以被認為就像更改DNS主機名一樣簡單,但是如果您更改DNS主機名,Microsoft則會自動更新SPN屬性。由於他的唯一性,如果嘗試通過DNS主機名屬性模擬另一台主機,我們將收到錯誤的訊息。但如果同樣更改了SPN,攻擊者可以繞過這個限制。

如果只有這兩個權限之一,就不會有漏洞。然後擁有這兩個權限的組合允許攻擊者執行權限提升。

PoC概念驗證

由於CVE-2022-26923漏洞的利用詳情已被研究員Oliver公開,多家資安安全機構也發文表示已出現此漏洞,時間的演進,我們將會在未來漸漸發現出大量關於此漏洞的攻擊手法。

解決方案及配套措施

對於CVE-2022–26923被套及保護措施,強烈建議企業將執行中的AD認證服務器和網域控制器更新到微軟5月10日發布的最新版本。

通過Tenable.ad 網域控制安全風險可視化解決方案,很容易化被動為主動,主動防禦此漏洞風險並能實現針對此漏洞偵測的攻擊手法,在未來產生實質攻擊之前阻斷其攻擊途徑。

預防階段T.ad可以幫助客戶識別AD網域控制中的配置風險,給出根本對應的緩解措施解決方案。

預設安裝情況下,任何用戶(無論是否擁有特權)都可以將一台或多台主機加入到網域。這樣做將觸發在Active Directory中創建新的主機帳戶操作。本次漏洞也利用到了這一配置特性。Tenable.ad通過風險暴露指標,幫用戶直接解決漏洞利用的先決條件,修復了AD不安全配置,從而做到主動防禦。

在攻擊鏈的第二步,攻擊者需要就是竄改其DNS主機名,這時候T.ad可以動態監控當前網域中所有機器的DNS主機名是否發生變更,同理也可以追蹤SPN屬性值的變化。如果有任何變動,在第一時間會回饋調查原因。
 

這個漏洞最根本的問題是AD認證服務的不安全配置導致的,所謂的“配置錯誤”認證樣版,是以多個會導致安全問題的參數為基礎的樣版,但只有根據上下文,對於每個參數的用途,才能區分修改哪些參數進而移除風險。
 

如上所述,此漏洞反應所有使用AD認證服務的企業,因此它的嚴重性不言而喻。為確保企業免受這個漏洞的攻擊,以下是需要採取的主要步驟:
  • 盡快將針對此漏洞的微軟補丁應用到所有網域控制服務器
  • 評估所有擁有著“write to DNS hostname”的權限帳戶,收回已有權限並判斷此權限是否帶來了非法變更
  • 將ms-DS-MachineAccountQuota屬性設置為0,這雖然不會解決問題,但是這樣做大幅度提高駭客攻擊的成本
  • 根據企業的需求,調整認證樣版的權限和批准
  • 使用T.ad產品的客戶可以真正在早期階段預防和時刻的動態檢測報警來防止此漏洞發生,能幫助客戶在被攻擊利用前先發現AD中不安全的配置、緩解風險是我們對於AD安全的願望之一,不斷提升駭客利用成本是我們的初衷,真正將風險可視化,做到主動出擊,提前加固預防。
  • 如果攻擊者嘗試利用成功,T.ad會向安全團隊提供詳細的警報,使調查更為容易並提供快速響應所需要的所有訊息。
識別受影響的系統
Tenable 漏洞研發團隊也已經發布了用於識別該漏洞的漏洞檢查plugin,Nessus和T.sc,請更新至最新的漏洞應用程式。

本文為投稿文章,不代表社方立場。