轉自：http://www.freebuf.com/articles/system/45631.html
微軟的活動目錄默認使用Kerberos處理認證請求。在BlackHat 2014上神器Mimikatz的作者剖析了微軟實現的Kerberos協議中存在的安全缺陷，並通過神器Mimikatz新添功能“Golden Ticket”展示瞭如何利用這些安全缺陷，讓Kerberos把守的地獄之門爲大家敞開。
一、快速介紹
Kerberos 是Windows活動目錄中使用的客戶/服務器認證協議，爲通信雙方提供雙向身份認證。相互認證或請求服務的實體被稱爲委託人（principal）。參與的中央服務器被稱爲密鑰分發中心（簡稱KDC）。KDC有兩個服務組成：身份驗證服務（Authentication Server，簡稱AS）和票據授予服務（Ticket Granting Server，簡稱TGS）。在Windows域環境下，身份驗證服務和票據授予服務可同時運行在任何可寫域控服務器上。（PS:Kerberos其實是希臘神話中看守地獄大門的三頭猛犬的名字，這隻猛犬除了比一般的狗多出兩個頭外，還有噴火與噴硫酸的特異功能。）
1.相關術語
委託人（principal）是一個具有唯一標識的實體，可以是一臺計算機或一項服務，通過使用KDC頒發的票據來進行通信。委託人可以分爲兩類：用戶和服務，分別具有不同種類的標識符。用戶通過如“user@REALM”格式的用戶主體名稱（User Principal Name，簡稱UPN）來標識。記住REALM一定是大寫的。例如用戶“bob”在“bhusa.com”域中應該表示爲[email protected]。
服務主體名稱（Service Principal Name，簡稱SPN）是用於域中的服務和計算機賬戶。SPN的格式形如“serviceclass/host_port/serviceName”。例如， 主機“dc1.bhusa.com”上LDAP服務的SPN可能類似於“ldap/dc1.bhusa.com”， “ldap/dc1”和“ldap/dc1.bhusa.com/bhusa.com”。參考全限定主機名和僅主機名，一個服務可能註冊爲多個SPN。
同通常是執行DNS查詢來規範化主機名稱。這就解釋了DNS爲什麼是微軟Kerberos環境中的一個必要組件。查詢服務的“規範化”名稱，然後生成請求服務的SPN。
2.認證步驟
Kerberos認證過程概覽
用戶要訪問活動目錄中的一項服務需經過以下幾個步驟：
1.客戶端對用戶口令執行散列運算。此散列值（即用戶密鑰）成爲客戶端和KDC共享的長期密鑰（long term key）。
2.KRB_AS_REQ-客戶端加密一個時間戳，然後發送給身份驗證服務。
3.KRB_AS_REP-身份驗證服務會解密時間戳，若解密成功，表明了客戶端獲得某個特定用戶的口令（即驗證了用戶的身份）。AS向客戶端回覆兩條信息：
①短期會話密鑰，用於客戶端向KDC發起後續的請求，該消息經客戶端的長期密鑰加密。（此短期會話密鑰僅適用於該客戶端和KDC之間）
②票據授予票據（Ticket Granting Ticket，簡稱TGT），包含有關用戶名、域名、時間和組成員資格等信息。該消息經僅可知KDC的密鑰加密（在Windows環境中爲krbtgt賬戶的NT-Hash）。記住KDC不記錄狀態：客戶端每次請求訪問一項服務時，TGT都會被轉發。
客戶端和Kerberos的預認證過程
4.KRB_TGS_REQ-客戶端使用AS返回的會話密鑰構建訪問特定服務的請求。客戶端把TGT連同請求一起發送到票據授予服務。
5.KRB_TGS_REP-票據授予服務解密TGT和服務請求，然後如果請求被允許，票據授予服務向客戶端發送一個服務票據（Service Ticket，簡稱ST），包括兩個部分：
①遠程服務器的部分-包含請求用戶的組成員資格、時間戳、用於客戶端和遠程服務器之間通信的會話密鑰。使用遠程服務器和KDC共享的長期密鑰加密這部分消息。
②客戶端的部分-包含用於客戶端和遠程服務器之間通信的會話密鑰。使用步驟3中AS回覆的短期會話密鑰加密這部分消息。
6.KRB_AP_REQ-客戶端把服務票據中的服務器部分和請求一起發送到遠程服務器。遠程服務器將直接接受該服務器票據，並不需要和KDC直接通信，因爲該票據是用遠程服務器和KDC共享的長期密鑰加密過的。解密成功即表明KDC已經允許了此次通信。
Kerberos信任模型的核心是每個委託人（principal）和KDC的通信是在利用僅雙方可知的密鑰構建的安全通道中進行。當委託人（principal）之間需要通信的時候，它們再使用KDC生成的會話密鑰。
Kerberos也允許使用PKI和智能卡進行身份認證。用戶會被提示輸入一個智能卡的PIN碼，而不是口令。Windows使用PIN碼來訪問智能卡上的公鑰證書（public key certification）。利用智能卡的私鑰簽名該證書，併發送到KDC。KDC驗證證書上的簽名是否源於可信實體。然後KDC發送公鑰證書加密過的TGT。既然信息只能被智能卡的私鑰解密，用戶也就通過了域的身份認證。然而，對於使用智能卡進行身份認證的賬戶來說，密碼的散列值仍然存儲在域控服務器上。此外，智能卡只能對“交互式會話（interactive sessions）”提供保護。也就意味着智能卡認證僅能用於登錄域中的計算機。
二、Kerberos信任完全依賴於KDC密碼
Kerberos協議是無狀態的，因此密鑰分發中心和票據授予服務並沒記錄以前的交互信息。因此票據授予服務所需使用的全部信息都位於TGT票據中。因爲TGT使用KRBTGT的密碼加密過，理論上講網絡上只有兩方能夠解密TGT：頒發票據的KDC和接受票據並創建訪問網絡資源的服務票據的票據授予服務。這種情況讓KRBTGT成爲系統中最重要的密碼。最終結果是隻要TGT被krbtgt賬戶密碼正確地加密，TGT中的所有信息都是可信的。
FreeBuf小科普
krbtgt賬戶：每個域控制器都有一個“krbtgt”的用戶賬戶，是KDC的服務賬戶，用來創建票據授予服務（TGS）加密的密鑰。三、關於krbtgt賬戶和TGT的問題
1. 問題一：微軟對長期密鑰的散列值不加SALT
微軟實現的Kerberos版本對MIT原始版本中的一個關鍵函數做了修改，最終降低了底層的安全性。在MIT原始版本中，首先在明文口令中添加字符串[email protected]，然後經過散列運算生成長期密鑰。使用用戶名給密碼加鹽，能夠爲碰巧密碼相同的不同用戶生成不同的散列值。只要涉及到密鑰的操作，仍然需要使用實際的口令。
在微軟實現版本中，口令轉換成Unicode格式，再經過MD4運算生成沒有加鹽的密鑰。這種情況也被稱爲NT-Hash，和微軟十多年來存儲長度大於14字符的密碼的格式一樣。缺少salt意味着任何需要密鑰的操作能夠直接地使用密碼的散列版本，而不是使用實際的密碼。這聽上去像大家耳熟能詳的“pass-the-hash”攻擊的根本原因。
從一個攻擊者的角度出發，如果能夠提取該域的密碼散列值，也就可以利用KRBTGT散列值來僞造TGT。雖然提取散列值看似難以實現，然而實際上，大部分滲透人員認爲在普通的企業環境中這並不是一件困難的事情。我們會在白皮書下面的一個章節中作全面深入的解析。
利用思路
在微軟活動目錄中頒發的TGT是可移植的。由於Kerberos的無狀態特性，TGT中並沒有關於票據來源的標識信息。這意味着可以從某臺計算機上導出一個有效的TGT，然後導入到該環境中其他的計算機上。新導入的票據可以用於域的身份認證，並擁有票據中指定用戶的權限來訪問網絡資源。這種特別的攻擊方法被稱爲“pass-the-ticket”攻擊。
Pass-The-Tickets攻擊思路
2. 問題二：長期不變的密碼
krbtgt 密碼的另一個問題是：它是整個活動目錄中唯一的不會自動更新的密碼。查看幾個活躍網絡中KRBTGT賬戶的年齡，賬戶已有五年或更多沒更改密碼的情況並不少見。在下面的例子中，此krbtgt密碼是最後設置於2005年4月。
使用“net use”命令顯示krgtgt的壽命
krbtgt密碼僅在兩種情況下將會自動更新。
第一種情況：域功能級別（domain functional level，簡稱DFL）從NT5（2000/2003）升級到NT6（2008/2012）。作爲升級過程的一部分，KRBTGT賬戶的密碼獲得更改。每次域功能級別的升級都會面臨一些特有的挑戰，而這些挑戰很大程度上是由網絡其他部分上運行的軟件版本所引發的。考慮升級過程可能耗費幾個月甚至一年的時間，大部分公司不會輕易對現有網絡進行升級操作。
第二種情況：利用域的恢復數據來實施域的裸機恢復（bare metal recovery）。域的恢復數據是在域初始運行時備份的。作爲恢復過程的一部分，KRBTGT的密碼需要改變兩次。因爲這是一個災難恢復場景，並且需要域的恢復數據，而域的恢復數據很可能因爲時間久遠而被弄丟了。所以，該場景難以在現實世界中發生。
FreeBuf小科普
bare metal recovery (裸機恢復)：硬盤發生災難性故障後對計算機進行完全恢復。該過程包括通過一個完全恢復點還原操作系統、文件系統、分區、卷和數據。四、客戶端的有效性
由於Kerberos是無狀態的，TGT必須包含了同票據授予服務交互所需的全部信息。根據微軟實現的Kerberos協議擴展（MS-KILE），KDC負責設置TGT中相應的標誌位，而票據授予服務使用這些標誌位來頒發服務票據。默認情況下，TGT攜帶了有關用戶的組成員資格、票據所使用的加密類型以及票據的有效期等信息。此外，微軟使用TGT來加強域上傳統的和最新的身份認證策略。TGT包含一些傳統的值來限制賬戶，例如登錄時長、賬戶是否禁用、賬戶是否過期、密碼失效的時間戳。
“本質上，客戶端的有效性體現在TGT中的賬戶策略功能，因爲客戶端利用TGT向票據授予服務提出自己有什麼安全限制。”值得注意的是，Kerberos協議並沒明確規定一個“票據授予服務如何驗證賬戶是否被禁用”的機制，但是微軟引入功能來讓票據授予服務在頒發服務票據之前驗證TGT是否被禁用。在後面的部分會圍繞這個話題進行深入探討。
五、萬能票據（Golden Ticket）
綜上所述，微軟實現的Kerberos版本中存在的一系列問題所引發的後果是：Kerberos成爲了攻擊者實施Post-Exploitation的遊樂場。如果攻擊者能夠攻陷KDC和提取KRBTGT散列值。然後利用這些有限信息，攻擊者能夠爲委託人生成任意的TGT。Mimikatz工具把這種特性稱之爲“萬能票據”（golden ticket，直譯爲“黃金票據”，爲突出功能上的特點，意譯譯爲“萬能票據”）。萬能票據擁有一些有趣的屬性，會導致傳統企業域中一些嚴重的安全問題。
首先，萬能票據是全功能的TGT。也就意味着萬能票據可用於Kerberos認證的任何服務。票據授予服務盲目地相信TGT中的信息，然後處理TGT並頒發服務票據。內存中插入萬能票據並不需要提升權限。而且默認情況下，萬能票據的有效期是10年。
其次，萬能票據可以用來繞過當前Kerberos有關加密策略的要求。例如，可以使用DES或RC4加密算法創建一個TGT，即使該域明確支持AES，禁止使用DES或RC4。此情況會產生一個有趣的現象：TGT使用DES加密而服務票據使用AES加密。票據授予服務似乎並不擔心TGT，也不拒絕異常行爲，因爲沒有機制讓票據授予服務報告關於策略的錯誤。
再次，萬能票據並沒啓用任何高級賬戶策略的設置。微軟添加了一個功能來驗證服務票據的請求，以確保已禁用的TGT不能用於獲得服務票據。然而，該功能的實現存在問題。只有當TGT的壽命超過20分鐘時，票據授予服務纔會驗證TGT的有效性。如果TGT的壽命低於20分鐘，票據授予服務將直接頒發服務票據，而不去驗證TGT的有效性，默認情況下服務票據具有10小時的有效期。因爲攻擊者可以利用Mimikatz工具隨心所欲的產生票據，所以攻擊者只需清除舊的TGT，再替換爲壽命少於20分鐘的新票據，輕鬆突破20分鐘的限制條件。
最終，萬能票據可以被配置成任意用戶和任意組的成員。這也可以創建一個票據，票據中任何用戶都可以是任意組的成員。這可以用來繞過文件服務器或其他應用程序上基於用戶組的訪問限制。萬能票據中的用戶和SID不必在活動目錄中真實存在。也就意味着可以爲域中不存在的用戶創建TGT,並仍然可以在TGT生命週期內前20分鐘內從票據授予服務獲得服務票據。
歸根結底，在一個企業的活動目錄的環境中，如果KRBTGT賬戶的丟失，也就意味着環境中的信任關係完全喪失。考慮到攻擊者可以生成任意的Kerberos票據，能繞過對任意用戶的賬戶策略，能夠讓用戶成爲任意組的成員，所以攻擊者簡直可以橫行無阻。此外，鑑於KRBTGT賬戶極少更改散列值，攻擊者可以在較長的時間內使用這些僞造的票據。
六、攻擊演示
我們在此展示一些把NT-Hash升級到有關Kerberos票據的研究。假設攻擊者能夠獲得一個特定用戶名的NT-Hash，爲什麼不可以把NT-Hash轉換爲一個票據。
1. 準備條件
創建“萬能票據”的所需條件：
①krbtgt賬戶的NT-Hash：該散列值是用於Kerberos的祕密密鑰，僅位於域控服務器的活動目錄中。所以攻擊者必須攻陷域控服務器並提權至管理員權限；
②域賬戶名稱：通常是域管理員“domain admin”；
③域名；
④域SID：可以從域用戶的SID或通過sysinternal中psGetsid.exe獲得；
2.攻擊演示
在Windows中可以使用Mimikatz來實現。首先，我們把NT-HASH放入MSV1_0，Kerberos服務賬戶的相關信息如下圖所示：
使用Mimikatz插入NT-Hash
當散列值插入到內存中，我們擦除掉所有其他的密鑰，因爲這些密鑰可能干擾我們獲得指定的票據。留下的密鑰只有上圖中插入到鏡像的RC4密鑰。
插入NT-Hash後內存中的加密密鑰列表
然後我們嘗試使用Kerberos訪問一個服務。在此我們看到一個票據的請求。注意到支持的加密類型僅有RC4：
發出的AS-REQ當我們嘗試使用訪問網絡資源時
在此我們看到產生的TGT：
僅使用NT-Hash加密的TGT
這項技術在使用AES算法的Kerberos環境也是有效的。與預認證唯一的不同之處是使用AES密鑰加密時間戳而不是傳統的RC4（即NT-Hash）。
參考信息來源 Blackhat2014，本文綜合了作者會上的文章和PPT的內容，各有取捨；同時也查閱了Kerberos相關資料，加上自己的理解組織成文，儘量保留了作者本意；本文涉及的技術內容較多，既有Kerberos網絡協議，又有微軟關於密碼存儲技術，還涉及到域控技術，我有些技術涉及不夠深入，內容難免會出現一些錯誤，歡迎大家批評指正。後續會發布關於如何防範萬能票據的文章，敬請期待！
[譯自Rabbit_Run，喜歡文章請點贊鼓勵，轉載請註明來自FreeBuf.COM]
該頁面還有kerberos相關的介紹，值得關注。