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不需要

小結:

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