taibeihacker
Moderator
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一併發送給TGS
5)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一併發送給Server
7)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不需要