- 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( ̄▽ ̄)ブ