0x01 為什么要理解windows 安全認證機制:

加深對后續各種漏洞利用的理解深度,還是那句話,要知其然,更要知其所以然,不廢話,咱們直接開始

0x02 windows認證協議主要有以下兩種:

基于ntlm的認證方式,主要用在早期的windows工作組環境中,認證的過程也相對比較簡單

另一種是基于Kerberos的認證方式,主要用在域環境中,下面就這兩種不同的認證方式做些簡要的通信流程說明

0x03 關于ntlm認證流程簡要說明,如下:

?

0x04 從圖中我們可以清晰的看到,ntlm在域中的認證過程主要分為以下幾步:

第一步,首先在client輸入username,password和domain,然后client會把password hash后的值先緩存到本地第二步,之后,client把username的明文發送給server(DC)第三步,DC會生成一個16字節的隨機數,即challenge(挑戰碼),再傳回給client第四步,當client收到challenge以后,會先復制一份出來,然后和緩存中的密碼hash再一同混合hash一次,混合后的值稱為response,之后client再將challenge,response及username一并都傳給server第五步,server端在收到client傳過來的這三個值以后會把它們都轉發給DC第六步,當DC接到過來的這三個值的以后,會根據username到域控的賬號數據庫(ntds.dit)里面找到該username對應的hash,然后把這個hash拿出來和傳過來的challenge值再混合hash第七步,將(6)中混合后的hash值跟傳來的response進行比較,相同則認證成功,反之,則失敗,當然,如果是本地登錄,所有驗證肯定也全部都直接在本地進行了

?

0x05 關于ntlm的一點小結:

????它是一種基于挑戰（challenge）/響應（response）消息交互模式的認證過程,從整個認證過程來看,安全確實不怎么到位,也就是說入侵者只需要拿到一個系統管理員的hash,直接給dc認證就好了,反正賬戶名和域名都知道,早期的pass the hash (psexec)確實就是通過這種方式來進行的,如果本地管理員的賬號密碼相同,其實不用密碼一樣可以被認證,我們所要做的就是不斷通過這種方式來嘗試拓展內網的其他機器,直到控制整個域,但后來的kb2871997,似乎改變了一些現狀,但也可能只是似乎

?

0x06 關于kerberos的一些概述:

????相對于ntlm而言,kerberos的認證方式就要復雜的多,因為它提供了一個集中式的認證方式,在整個認證過程中總共要涉及到三方:客戶端,服務端和KDC [Key Distribution Center 密鑰分發中心], 在Windows域環境中,KDC的角色由DC(Domain Controller[域控])來擔任,Kerberos是一種基于票據的認證方式,票據(Ticket)是用來安全的在認證服務器和用戶請求的服務之間傳遞用戶的身份,同時也會傳遞一些附加信息,用來保證使用Ticket的用戶必須是Ticket中指定的用戶,Ticket一旦生成,在生存時間內可以被Client多次使用來申請同一個Server的服務(票據竊取問題)

0x07 kerberos的大致工作流程:

????說到這里,我們大概也能明白,域中的客戶端要想訪問同域中的某個服務器資源時,需要首先購買該服務端認可的票據,也就是說,客戶端在訪問服務器之前需要預先買好票,等待服務驗票之后才能入場,但是這張票不能直接購買,還需要一張認購權證,也就是說客戶端在買票之前需要預先獲得一張認購權證,這張認購權證和進入服務器的入場券均有KDC發售,下面就以下圖來做簡要說明:

?

1)首先,客戶端(client)將域用戶的密碼hash一次并保存,然后,以此hash來作為客戶端和KDC之間的長期共享密鑰[kc](當然,在DC上也保存著同樣的一條hash)2)之后,客戶端(client)開始利用(1)中的域用戶密碼hash再把時間戳,clientid,TGS id等信息混合hash一次,然后向as(認證服務器 [Authentication Server])服務器進行請求3)as接到該請求后,利用長期共享密鑰(kc)進行解密,解密成功后,會返回給客戶端兩個票據(1)加密的K(c,tgs)(用于客戶端后續向KDC發起請求),TGS Name/ID,時間戳等,該票據由Kc加密(2)票據授予票據(Ticket Granting Ticket,簡稱TGT),該票據是給TGS的,票據的內容包括K(c,tgs),Client身份信息,域名,時間戳等,該票據由TGS的秘鑰加密,只有TGS能夠解密4)然后,客戶端會利用長期共享密鑰解密k(c,tgs),并利用該秘鑰加密生成一個Authenticator,內容包括:lifetime,時間戳,Client身份信息等,連同從AS獲取的TGT一并發送給TGS5)TGS利用自身的秘鑰解密TGT,獲取K(c,tgs),并用K(c,tgs)解密客戶端發送的Authenticator,對Client進行認證,如果Client通過了認證,TGS隨機生成一個Session Key K(c,s),并產生兩個票據(1)服務票據(Ts):這是給服務器的服務票據,由Server秘鑰Ks加密,內容包括：K(c,s),Client身份信息,Service ID,時間戳,lifetime等(2)客戶端票據(Tc)：該票據由K(c,tgs)加密,內容包括：K(c,s),Server身份信息等6)客戶端收到tgs的回應后,利用K(c,tgs)解密Tc,獲取K(c,s),Server身份信息等,并利用K(c,s)加密生成一個Authenticator發送給Server,內容包括:時間戳,Client ID等信息,連同Ts一并發送給Server7)Server端在收到Client的請求后,利用自身秘鑰Ks解密Ts,得到K(c,s),再利用K(c,s)解密Authenticator,對Client進行認證,如果認證通過,則表示KDC已經允許了此次通信,此時Sever無需與KDC通信,因為Ks為KDC和Sever之間的長期共享秘鑰,如果在有效時間內,則此次請求有效

?

0x08 關于kerberos利用方法:

1) 黃金票據(Golden Ticket)
????先假設這么一種情況,原先已拿到的域內所有的賬戶hash,包括krbtgt這個賬戶,由于有些原因導致域管權限丟失,但好在你還有一個普通域用戶權限,碰巧管理員在域內加固時忘記重置krbtgt密碼,基于此條件,我們還能利用該票據重新獲得域管理員權限,利用krbtgt的HASH值可以偽造生成任意的TGT(mimikatz),能夠繞過對任意用戶的賬號策略,讓用戶成為任意組的成員,可用于Kerberos認證的任何服務

2) 白銀票據(Silver Ticket)
????通過觀察Kerberos協議的認證過程不難發現,如果我們獲取了Server秘鑰Ks(服務器口令散列值),就可以跳過KDC的認證，直接偽造票據和目標Server通信

0x09 關于黃金票據和白銀票據的一些區別:

1)訪問權限不同

Golden Ticket: 偽造TGT,可以獲取任何Kerberos服務權限Silver Ticket: 偽造TGS,只能訪問指定的服務

2)加密方式不同

Golden Ticket 由Kerberos的Hash加密Silver Ticket 由服務賬號(通常為計算機賬戶)Hash加密

3)認證流程不同

Golden Ticket 的利用過程需要訪問域控,而Silver Ticket不需要

小結:

???這些其實都是域內滲透最基礎的知識,所以覺得大家還是非常有必要多花點兒時間,好好深刻體會一下,另外,微軟給我們的建議是,盡量們不要直接使用NTLM,而使用negotiate,如果使用的是negotiate,windows則會先判斷kerberos是否可用,如果可用就優先使用kerberos,否則才會使用NTLM,kerberos的安全性確實要比NTLM要高很多

?

轉載于:https://www.cnblogs.com/backlion/p/7856115.html

總結

以上是生活随笔為你收集整理的深入详解windows安全认证机制ntlmKerberos的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。