- Kerberos協議中的角色
- 關鍵名詞
- Kerberos協議的工作流程
- AS_REQ & AS_REP
- TGS_REQ & TGS_REP
- AP_REQ
- PAC
- 總結
Kerberos 是一種由麻省理工學院提出的一種網路身份驗證協議，它透過使用金鑰加密技術為客戶端/伺服器應用程式提供強身份驗證。
Kerberos協議中的角色
在Kerberos協議中主要是有三個角色：
-
訪問服務的客戶端 Client
-
提供服務的服務端 Server
-
金鑰分發中心KDC（Kerberos協議的核心組成）
KDC 服務會預設安裝在域控中，而Client和Server分別是域內的客戶和服務，在Kerberos中Client是否有許可權訪問Server端的服務，是由KDC發放的票據來決定的。
KDC中分成兩個部分：
-
身份驗證服務AS：驗證Client的身份，驗證透過之後，AS就會發放TGT票據給Client。
-
票據授予服務TGS：當Client獲取的TGT票據後，TGS會給Clinet換取訪問Server端的ST服務票據。
關鍵名詞
-
DC 域控制器 Domain Controller
-
KDC 金鑰分發中心 Key Distribution Center
-
AS 身份驗證服務 Authentication Service
-
TGS 票據授予服務 Ticket Granting Service
-
TGT 認證票據 Ticket Granting Ticket
-
ST 服務票據 Service Ticket
-
PAC 特權屬性證書 Privilege Attribute Certificate
-
AD 賬戶資料庫 Account Database（儲存所有Client的白名單）
-
krbtgt賬戶（KDC的服務賬戶）
Kerberos協議的工作流程
-
客戶端向KDC的AS認證服務請求TGT票據
-
客戶端透過AS認證後，KDC將會給客戶端發放TGT票據
-
客戶端帶上TGT票據，向TGS認證服務請求ST服務票據
-
客戶端透過TGS認證後，TGS將會給客戶端發放ST服務票據
-
客戶端使用ST服務票據向服務端請求服務
-
PAC校驗：服務端拿到PAC詢問KDC客戶端是否有許可權，KDC將客戶端的許可權資訊返回給服務端，判斷客戶端是否有許可權訪問該服務，並把結果返回給客戶端
舉個例子：
下面來具體地瞭解Kerberos工作流程，強烈建議使用 windows_protocol 專案開發的Kerberos發包工具來模擬Kerberos認證的過程，從而加強理解。
Kerberos發包工具地址：https://github.com/daikerSec/windows_protocol/tree/master/tools
AS_REQ & AS_REP
首先是客戶端與KDC中AS之間的認證，使用 AS_REQ & AS_REP 模組：
AS_REQ
AS_REQ指的是客戶端向KDC發起AS認證服務請求TGT票據，請求憑據是客戶端hash加密的時間戳。
這裡ENC_TIMESTAMP是預認證，就是用客戶端使用者hash加密時間戳，傳送給AS伺服器。在AS伺服器中有使用者hash，然後使用使用者hash進行解密，獲得時間戳。如果能解密，並且時間戳在一定的範圍內，則認證透過。
這裡PA_PAC_REQUEST是啟用PAC支援的擴充套件，PAC資訊將包含在AS_REP中。這裡的value對應的是include=true或者include=false（KDC根據include的值來判斷返回的票據中是否攜帶PAC）。
AS_REP
AS_REP指的是AS預認證透過，接著AS認證服務會返回用krbtgt hash加密的TGT票據和使用者hash加密的session key及其他資訊。
這裡ticket就是用於向TGS認證服務請求ST服務票據的認證，ticket中的這個enc-part是由krbtgt hash加密的，使用者不可讀取。
而在ticket下方的這個enc_part是使用使用者hash加密的一個session key，使用者解密後可以拿到這個session key作為下階段的認證金鑰。
TGT票據憑據裡面最核心的東西就是krbtgt hash加密的ticket和使用者hash加密的session key。
在AS_REP裡面的ticket中的enc-part是使用krbtgt hash加密的。所以如果我們擁有krbtgt的hash，就可以給我們自己簽發任意使用者的TGT票據，這個票據也被稱為黃金票據。
TGS_REQ & TGS_REP
當客戶端獲取TGT票據之後，可以去向KDC的TGS申請特定服務的訪問許可權，使用 TGS_REQ & TGS_REP 模組：
TGS_REQ
TGS_REQ指的是客戶端帶上從AS那裡獲得TGT票據，向TGS認證服務請求ST服務票據。
這裡ar-req這部分會攜帶AS_REP裡面獲取到的TGT票據。圖中可以看到ar-req中的ticket和AS_REP的ticket部分是完全一致的。TGS透過krbtgt的hash解密TGT票據，然後驗證客戶端的身份。
TGS_REP
TGS_REP指的是客戶端透過了TGS認證服務後，TGS將會給客戶端使用者發放ST服務票據。TGS生成的ST服務票據其中包括ticket和一個新的session key。
這裡ticket就是終端使用者用於請求特定服務AP_REQ的認證（ST票據），裡面的enc_part也是加密的，是使用要請求的服務的hash加密的，使用者不可讀取。
在ticket下方的enc-part這部分是可以解密的，金鑰就是上一輪AS_REP裡面返回TGT票據中的session key，解密以後的這個新session key同樣用來作為下階段的認證金鑰。
在TGS_REQ裡面是使用要請求的服務（host）的hash加密的。因此如果我們擁有服務的hash就可以自己製作一個ticket，既白銀票據。
AP_REQ
AP_REQ指的是最後客戶端使用者使用ST票據去訪問特定的服務。
客戶端首先將ST票據中解密後的session key快取，然後客戶端將ST服務票據和session key加密的時間戳一起傳送給服務端。
服務端使用自己的hash解密ST票據提取session key，然後使用session key驗證加密的時間戳，確認客戶端的身份並建立會話。
PAC
TGS_REP這裡其實存在一個隱患：在這一步中，不論使用者是否有許可權訪問服務，只要TGT解密無誤，都將返回ST服務票據。那麼任何一個使用者，只要hash正確，就可以請求域內任何一個服務的票據。
為了解決上面的這個問題，微軟引進了PAC（Privilege Attribute Certificate）即特權屬性證書，用來驗證使用者許可權和模擬使用者操作的憑證。
引進PAC之後的kerberos流程變成：
-
使用者向KDC發起AS_REQ，請求憑據是使用者hash加密的時間戳，KDC使用使用者hash進行解密，如果結果正確返回用krbtgt的hash加密的TGT票據，TGT票據裡面包含PAC，PAC包含使用者的sid，使用者所在的組。
-
使用者憑藉TGT票據向KDC發起針對特定服務的TGS_REQ請求，KDC使用krbtgt的hash進行解密，如果結果正確，就返回用服務hash加密的ST票據。
-
使用者拿著ST票據去請求服務，服務使用自己的hash解密TGS票據。如果解密正確，就拿著PAC去KDC那邊詢問使用者有沒有訪問許可權，域控解密PAC。獲取使用者的sid，以及所在的組，再判斷使用者是否有訪問服務的許可權。
總結
以上就是Kerberos工作流程的三個主要部分簡單分析，Kerberos還有很多細節內容值得學習，包括PAC，委派等，還有在認證的過程中引發的一系列安全問題，比如常聽到的黃金票據和白銀票據等。持續學習！
參考文章：
https://daiker.gitbook.io/windows-protocol/kerberos
https://xz.aliyun.com/t/8187?time__1311=n4%2BxuDgDBDyGKiKPe05DK3hrDcDAo42u%2BGirD&alichlgref=https%3A%2F%2Fxxe.icu%2F
https://xxe.icu/domain-security.html#域使用者名稱列舉
https://zhuanlan.zhihu.com/p/266491528
若有錯誤，歡迎指正！o(￣▽￣)ブ