🌟想系統化學習內網滲透？看看這個：[內網安全] 內網滲透 - 學習手冊-CSDN博客

0x01：Kerberos 協議簡介

Kerberos 是一種網絡認證協議，其設計目標是通過密鑰系統為客戶機 / 服務器應用程序提供強大的認證服務。該認證過程的實現不依賴于主機操作系統的認證，無需基于主機地址的信任，不要求網絡上所有主機的物理安全，并假定網絡上傳送的數據包可以被任意地讀取、修改和插入數據。在以上情況下，Kerberos 作為一種可信任的第三方認證服務，通過采用傳統密碼技術（如：共享密鑰）來執行認證服務。

打一個淺顯的例子，A 想要到 B 那里買東西，但是怕 B 收了錢不辦事。此時，我們需要一個第三方機構 C 做擔保，A 把錢給了 C，B 辦完事后去 C 那里拿錢。Kerberos 協議就完成了這么一個操作。

0x02：Kerberos 協議的組成角色

在古希臘神話故事中，Kerberos 是一只具有三顆頭顱的地獄惡犬，它守護在地獄之外，能夠識別所有路過的亡靈，防止活著的入侵者闖入地獄：

Kerberos 協議中也存在三個角色，分別是：

• 客戶端（Client）： 發送請求的一方。

• 服務端（Server）： 接收請求的乙方。

• 密鑰分發中心（Key Distribution Center，KDC）： 該部分由兩 AS 與 TGS 構成：

  • AS（Authentication Server）： 認證服務器，專門用來認證客戶端的身份并發放客戶端用于訪問 TGS 的 TGT（允許買票的票據 — 票據授予票據）

  • TGS（Ticket Granting Ticket）： 票據授予服務器，用來執行整個認證過程以及發放客戶端訪問服務端時所需的服務授予票據（Ticket）

0x03：Kerberos 認證的類比流程

Kerberos 協議還是有些復雜的，所以本部分中，筆者將通過兩個現實中的例子，讓讀者對 Kerberos 協議有一個大概的認識，為我們后面介紹 Kerberos 認證的完整流程打一個基礎。

0x0301：Kerberos 類比流程 — 第三方購物

假設現在 A 要買 “電腦”，它知道 B 在賣（通過電視宣傳啊），但是 AB 兩人都沒有見過面，現在 A 就在擔心，我要是把錢直接給 B 了，B 翻臉不認人了怎么辦，此時，A 就陷入了信任危機。

于是，A 想到了一個辦法，它找到第三方機構 C（某東），C 機構認識 A 和 B，那么 A 就將錢交給了 C 機構，C 機構轉告給 B 機構發貨，等到 A 確認收貨后，C 機構再把錢給 B。

上面這個例子，體現的是 Kerberos 的第三方認證特性，Kerberos 中的 KDC 在上面那里例子中就是充當 C 角色，A 就是 Client，B 就是 Server。但是上面這個例子并沒有體現 KDC 中 “AS” 和 ”TGS“ 的用處，我們來看看下面這個例子。

0x0302：Kerberos 類比流程 — 乘坐過山車

假設你帶著一家去做過山車，你不能直接去乘過山車，你得去售票處買票吧：

來到了售票處，你不光得有錢，你還得符合乘坐的標準吧（身高啥的），只有你都滿足要求了，你才能花錢買到過山車的票，然后乘坐過山車：

在上面的那個流程中 ”你“ 就是 Client 端，”過山車“ 就是你申請的服務 Server。售票處（測量身高的阿姨 + 售票）構成了 KDC，你來到了 KDC，KDC 中的 AS 首先得校驗你有沒有購票資格，你有資格購票后，售票處（TGS）才能給你發放票據（Ticket）。

0x0303：Kerberos 認證流程簡單概述

通過上面兩個例子，相信讀者對 Kerberos 已經有一個大致的認識了，這里筆者簡單描述一下它的整體認證流程：客戶端在訪問每個想要訪問的服務時，需要攜帶一個專門用于訪問該服務并且能夠證明自己身份的票據，當服務端收到了該票據他才能認定客戶端身份正確，向客戶端提供服務。

整個 Kerberos 認證流程可以簡化為兩大步：

1. 客戶端向 KDC 請求獲取想要訪問的目標服務的服務授予票據（Ticket）。

2. 客戶端拿著從 KDC 獲取的服務授予票據（Ticket）訪問相應的網絡服務。

0x04：Kerberos 認證的完整流程

在前面類比流程中，筆者并沒有詳細講 KDC 中 AS 和 TGS 的具體作用，那么在這里，筆者將詳細講解 Kerberos 認證的完整流程，并順帶介紹 AS 與 TGS 的作用。

0x0401：第一步 — 客戶端與 AS 進行通信

為了獲得能用來訪問服務端服務的票據，客戶端首先需要來到 KDC 獲得服務授予票據（Ticket）。由于客戶端是第一次訪問 KDC，此時 KDC 也不能確認該客戶端的身份，所以在第一次通信的時候 KDC 需要對客戶端身份進行認證，確認客戶端是一個可靠且擁有訪問 KDC 權限的客戶端。

第一步：Client 首先向 KDC 以明文方式發起請求，并在該次請求中攜帶了自己的用戶名，主機 IP 和當前時間戳。

第二步：KDC 中的 AS （AS 是 KDC 中專門用來認證客戶端身份的認證服務器）接收請求后去 Kerberos 認證數據庫中根據用戶名查找是否存在該用戶（注意：此時只會查找是否有相同用戶名的用戶，并不會判斷身份的可靠性）。

第三步：如果沒有該用戶名，則認證失敗，服務結束；如果存在用戶名，則 AS 認證中心便認為用戶存在，此時便會返回相應給客戶端，響應中包含兩部分內容：

• 第一部分內容被稱為（TGT），即 ”票據授予票據“。客戶端后續需要使用 TGT 去 TGS（票據授予中心）獲取訪問網絡服務所需的 Ticket（服務授予票據），TGT 中包含 Kerberos 數據庫中存在的該客戶端的 Name，IP，當前的時間戳，客戶端即將訪問的 TGS 的 Name，TGT 的有效時間以及一把用于客戶端和 TGS 間進行的 Session_Key（CT_SK）。整個 TGT 使用 TGS 密鑰加密，客戶端是解密不了的，由于密鑰從沒有在網絡中傳輸過，所以也不存在密鑰被劫持破解的情況。

• 第二部分內容是使用客戶端密鑰加密的，其中包括用于客戶端和 TGS 間通信的 Session_Key（CT_SK），客戶端即將訪問的 TGS 的 Name 以及 TGT 的有效時間，和一個當前的時間戳。該部分內容使用客戶端加密，所以客戶端在拿到該部分內容時可以通過自己的密鑰解密。如果是一個假的客戶端，那么他是不會擁有真正客戶端的密鑰的，因為該密鑰也沒在網絡中進行傳輸過。這也同時認證了客戶端的身份，如果是假客戶端會由于解密失敗而終止認證流程。

第一階段的整體流程如下圖所示：

0x0402：第二步 — 客戶端和 TGS 進行通信

經過了第一步，Client 收到了來自 KDC（準確來說是 AS）的響應，并獲取到了其中兩部分的內容。此時客戶端會用自己的密鑰將第二部分內容解密，獲取時間戳、自己將要訪問的 TGS 的信息以及用于與 TGS 通信的密鑰 CT_SK。Client 在獲取上述信息后，會先根據時間戳判斷該時間戳與自己發送請求時的時間之間的差值是否大于 5 分鐘，如果大于五分鐘則認為該 AS 是偽造的，認證失敗。如果時間戳合理，客戶端就會準備向 TGS 發起請求。客戶端和 TGS 通信流程如下：

Client（客戶端）行為：

1. 客戶端使用 CT_SK 加密將自己的客戶端信息發送給 KDC，其中包括客戶端名，IP，時間戳。

2. 客戶端將自己想要訪問的 Server 服務以明文的方式發送給 KDC。

3. 客戶端將使用 TGS 密鑰加密的 TGT 也原封不動的攜帶給 KDC。

KDC 中的 TGS（票據授予服務器）行為：

1. TGS 收到了來自客戶端的請求。首先根據客戶端明文傳輸過來的 Server 服務 IP 查看當前 Kerberos 系統中是否存在可以被用戶訪問的對應服務。如果不存在，認證失敗，如果存在，繼續下一步。

2. TGS 使用自己的密鑰將 TGT 中的內容進行解密，此時他看到了經過 AS 認證過后并記錄的用戶信息，CT_SK 以及時間戳信息，它會先根據時間戳判斷此次通信是否真實可靠沒有超出時延。

3. 如果時延正常，則 TGS 會使用 CT_SK 對客戶端的第一部分內容進行解密（使用 CT_SK 加密的客戶端信息），取出其中的用戶信息和 TGT 中的用戶信息進行比對，如果全部相同則認為客戶端身份正確，可以進行下一步。

4. 此時，KDC（準確來說是 TGS）將返回一個 Ticket，該 Ticket 由兩個部分組成：

   1. 第一部分，用于客戶端訪問網絡服務的使用 Server 密碼加密的 ST（Server Ticket），其中包括客戶端的 Name，IP，需要訪問的網絡服務的地址 Server IP，ST 的有效時間，時間戳以及用于客戶端和服務端之間通信的 CS_SK（Session Key）。

   2. 第二部分，使用 CT_SK 加密的內容，其中包括 CS_SK 和時間戳，還有 ST 的有效時間。由于在第一次通信過程中，AS 已將 CT_SK 通過客戶端密碼加密交給了客戶端，且客戶端解密并緩存了 CT_SK，所以該部分內容在客戶端接收到時是可以自己解密的。

第二階段整體流程如下圖所示：

0x0403：第三步 — 客戶端和服務端進行通信

經過前面兩步，此時客戶端收到了來自 TGS 的響應，并使用緩存在本地的 CT_SK 解密出了第二部分的內容（第一部分內容中的 ST 是由 Server 密碼加密，客戶端無法解密）。客戶端在檢驗第二部分時間戳無誤后取出其中的 CS_SK 準備向服務端發起最后的請求：

Client（客戶端）行為：

客戶端使用 CS_SK 將自己的主機信息和時間戳進行加密作為交給服務端的第一部分內容，然后將 ST（服務授予票據）作為第二部分內容都發送給服務端。

?Server（服務端）行為：

服務端收到來自客戶端的請求，使用自己的密鑰，將客戶端發送來的 ST 部分進行解密，核對時間戳后將其中的 CS_SK 取出，使用 CS_SK 將客戶端發來的第一部分內容進行解密，從而獲得經過 TGS 認證過后的客戶端信息，此時他將這部分信息和客戶端第二部分內容帶來的信息進行比對，最終確認客戶端就是經過了 KDC 認證的具有真實身份的客戶端，是他可以提供服務的客戶端。

此時服務端會返回一段使用 CT_SK 加密的表示接收請求的響應給客戶端，在客戶端收到請求后，使用緩存在本地的 CS_SK 解密后也確認了服務端的身份。（其實服務端在通信過程中還會使用數字證書證明自己身份）。

至此，第三次通信完成，此時也代表整個 Kerberos 認證的完成，通信的雙方都確認了對方的身份，此時便可以放心的進行整個網絡通信了。第三階段流程如下：

0x0404：Kerberos 認證完整流程圖