您的位置:首頁 > 菜鳥學(xué)院 > 深入解讀MS14-068漏洞:微軟精心策劃的后門?

深入解讀MS14-068漏洞:微軟精心策劃的后門?

來源:互聯(lián)網(wǎng) | 時(shí)間:2015-01-22 14:18:44 | 閱讀:70 |    | 分享到:


0×0 背景


    微軟(2014-11-18)發(fā)布了一個(gè)緊急補(bǔ)丁,修復(fù)了一個(gè)影響全部版本W(wǎng)indows服務(wù)器的嚴(yán)重漏洞。今天發(fā)布的MS14-068漏洞補(bǔ)丁用于解決Microsoft Windows Kerberos KDC漏洞(CVE-2014-6324),該漏洞允許黑客提升任意普通用戶權(quán)限成為域管理員(Domain Admin)身份。也就是說,你在一臺普通域用戶的機(jī)器上利用這個(gè)漏洞,那么這個(gè)域用戶就變成域管理員權(quán)限,然后,該域用戶就可以控制整個(gè)域的所有機(jī)器了。

那么,問題來了,該漏洞的威力真的有這么大嗎?

網(wǎng)上出現(xiàn)了Github上爆出的該漏洞的Python利用程序,Python Kerberos Exploitation Kit,也就是PyKek,當(dāng)然,其它站點(diǎn)也都開始了轉(zhuǎn)發(fā)。經(jīng)過測試,Win7的普通域用戶運(yùn)行該漏洞程序確實(shí)能夠成為域管理員權(quán)限。但網(wǎng)上大家的測試都是在域用戶的本地賬戶中才能測試成功。

為什么Windows關(guān)于MS14-068的公告板中并沒有提出這一點(diǎn)?按道理來說,越是有限制的漏洞利用對軟件開發(fā)人員越是有利的,漏洞利用的機(jī)會越少,他們受到的譴責(zé)就會越少。

那么,問題又來了,真的只能用域用戶的本地賬戶漏洞才能利用成功嗎?

自從Freebuf發(fā)布該漏洞預(yù)警后,再也沒看到另有分析文章出現(xiàn),甚至也沒有POC,這讓我為心目中偉大的Freebuf捉急哇,心情低落到極點(diǎn),所以,自己決心從頭開始研究該漏洞。

這樣的話,問題又來了,作為不懂Kerberos協(xié)議的小白,這個(gè)漏洞到底是怎么產(chǎn)生的?

帶著種種疑問,我開始了分析之旅,時(shí)隔半月,分析完成后,沒想到卻發(fā)現(xiàn)了一個(gè)天大的秘密,我從下面幾點(diǎn)向大家分析一下關(guān)于這個(gè)漏洞的方方面面,來揭示這個(gè)筆者認(rèn)為有人精心策劃的漏洞。

0×1 Python版PoC的測試?yán)?/span>

首先網(wǎng)上的Python版PyKek,搭建域環(huán)境、Python環(huán)境,對該漏洞進(jìn)行了測試:

(1)測試環(huán)境

目的:將普通域用戶權(quán)限提升為域控權(quán)限(漏洞利用后,net
use swg.server.comc$可以直接訪問域控的網(wǎng)絡(luò)資源)

深入解讀MS14-068漏洞:微軟精心策劃的后門?

(2)測試步驟

A.利用域賬戶domainuser/Dom12345登錄普通域機(jī)器Win7,獲得該域賬戶的域SID:

深入解讀MS14-068漏洞:微軟精心策劃的后門?

B.以本地賬戶test/123456登錄普通域機(jī)器Win7,運(yùn)行PyKek漏洞利用程序:

深入解讀MS14-068漏洞:微軟精心策劃的后門?

此時(shí)在C:Userstest文件件會產(chǎn)生MIT格式的TGT文件[email protected]

C.利用mimikatz工具將得到的[email protected]寫入內(nèi)存,創(chuàng)建緩存證書:

深入解讀MS14-068漏洞:微軟精心策劃的后門?

利用klist命令能夠看到mimikatz創(chuàng)建緩存證書前后的區(qū)別。

創(chuàng)建緩存證書之前:

深入解讀MS14-068漏洞:微軟精心策劃的后門?

創(chuàng)建緩存之后:

深入解讀MS14-068漏洞:微軟精心策劃的后門?

D. 在普通域機(jī)器Win7的本地賬戶中執(zhí)行:

深入解讀MS14-068漏洞:微軟精心策劃的后門?

你會驚奇地發(fā)現(xiàn),不用提供Win2003域控的賬號密碼就直接可以連接到其C盤,也就是說,現(xiàn)在可以訪問Win2003域控機(jī)器C盤:

深入解讀MS14-068漏洞:微軟精心策劃的后門?

正如宣稱的那樣,漏洞成功利用后,域用戶在不知道域控密碼的情況下,可以隨意訪問域控上的資源,怪不得大家都說,有了這個(gè)漏洞,再也不用狂掃密碼了。

這是網(wǎng)上普遍轉(zhuǎn)發(fā)的一種漏洞利用姿勢,需要注意的是,域SID是以域用戶登錄Win7域機(jī)器獲得的,而漏洞利用則是在該域機(jī)器的本地賬戶下才能測試成功。如果搭建了測試環(huán)境,你會發(fā)現(xiàn),“先用域賬戶獲得SID,然后不得不再登錄本地賬戶測試漏洞”這一過程是多么繁(dan)瑣(teng)。

當(dāng)然,后面會討論為什么在域賬戶下無法利用成功,并提出一種繞過方法。

漏洞利用就是這樣的,接下來我們分析一下這個(gè)漏洞到底是怎樣產(chǎn)生的。

0×2 關(guān)于Kerberos協(xié)議

在談MS14-068漏洞之前,有必要先了解一下Kerberos協(xié)議。

Kerberos協(xié)議是一種基于第三方可信主機(jī)的計(jì)算機(jī)網(wǎng)絡(luò)協(xié)議,它允許兩個(gè)實(shí)體之間在非安全網(wǎng)絡(luò)環(huán)境(可能被竊聽、被重放攻擊)下以一種安全的方式證明自己的身份。

下面我們從Kerberos是如何設(shè)計(jì)出來的來學(xué)習(xí)該協(xié)議的原理。

這個(gè)協(xié)議解決的根本問題,假設(shè)A和B共有一個(gè)秘密,在一個(gè)非安全網(wǎng)絡(luò)環(huán)境中,A怎樣才能向B證明自己就是A。

最簡單的方式就是,A直接將秘密發(fā)送給B,由B來判斷這個(gè)秘密的真?zhèn)。但在非安全網(wǎng)絡(luò)環(huán)境中,秘密可能會被竊聽或中間人攻擊,所以這種方式不可取。

接下來考慮的是,A用秘密作為密鑰加密一段文字生成一段密文,然后將文字本身和密文一起發(fā)給B,B接收后用秘密解密密文得到文字,然后和接收的文字對比,如果兩者一致,那么也能證明秘密的正確性,從而也能驗(yàn)證A的身份。

但如果該認(rèn)證請求被竊聽,攻擊者能得到加密后密文和加密前的明文,只要時(shí)間允許,總能推導(dǎo)出密鑰的數(shù)值,也就是秘密肯定會被竊取。所以密碼界有個(gè)規(guī)定,長期存在的密鑰不適合在網(wǎng)絡(luò)中傳輸,否則總會有被竊取的風(fēng)險(xiǎn)。

不使用長期存在的密鑰,那使用短期存在的密鑰進(jìn)行驗(yàn)證應(yīng)該是沒問題的,關(guān)鍵是,誰來提供這個(gè)短期存在密鑰給A和B?于是就出現(xiàn)了第三方可信機(jī)構(gòu)KeyDistribution Center,KDC。

在請求認(rèn)證之前,Client-A先去向KDC申請本次向Server-B認(rèn)證需要的SessionKey,由KDC將SessionKey分發(fā)給Client-A和Server-B,最后Client-A就可以利用這個(gè)SessionKey向Server-B進(jìn)行認(rèn)證了。為了SessionKey不被竊取,該SessioKey用A和B自身的密碼分別加密:

深入解讀MS14-068漏洞:微軟精心策劃的后門?

這里會有兩個(gè)問題:

(1)A向KDC申請SessionKey,它可能很快就收到SessionKey,但B可能因?yàn)榫W(wǎng)絡(luò)環(huán)境原因,很晚或者根本收不到SessionKey,這樣就導(dǎo)致認(rèn)證無法進(jìn)行,解決辦法就是,KDC將兩份加密的SessionKey都發(fā)給A,由A在向B發(fā)出認(rèn)證請求時(shí)將原本屬于Server-B的SessionKey一同發(fā)送給Server-B

(2)A提出SessionKey的申請時(shí),KDC憑什么就生成了SessionKey給了A,也就是說,KDC缺乏對A的認(rèn)證,所以在分發(fā)SessionKey之前,KDC需要增加對A的認(rèn)證,解決辦法就是,將KDC機(jī)構(gòu)分成兩部分:

ASAuthentication Service,用于KDCA的認(rèn)證 TGSTicket Granting Ticket,用于KDCAB分發(fā)Session Key

另外,還有一點(diǎn)需要注意的是,為了對短期有效的SessionKey進(jìn)行驗(yàn)證,Kerberos協(xié)議要求系統(tǒng)內(nèi)的所有主機(jī)基于時(shí)間同步,所以Client-A向Server-B進(jìn)行認(rèn)證就不用SessionKey加密一段密文后還得發(fā)送一段明文過去,直接用SessionKey加密當(dāng)前時(shí)間即可。

到此為止,整個(gè)Kerberos協(xié)議大體框架已經(jīng)出來了:

深入解讀MS14-068漏洞:微軟精心策劃的后門?

需要注意的是,這里涉及到兩個(gè)SessionKey的申請,一個(gè)是SessionKeya-kdc,另一個(gè)是SessionKeya-b,這是因?yàn)榛趧偛诺娜秸J(rèn)證以及盡量使用短期有效密鑰的思想,本協(xié)議變成了兩次三方認(rèn)證:

(1)AS作為Client-A與TGS之間的第三方,需要完成對A進(jìn)行認(rèn)證,同時(shí)為Client-A向TGS提出SessionKeya-b請求提供一個(gè)SessionKeya-kdc,根據(jù)剛才的分析,為了防止TGS無法收到SessionKey,如圖第②步,原本需要發(fā)往TGS的SessionKeya-kdc(被KDC密碼加密為TGT)會一同發(fā)往Client-A,由Client-A在第③步中轉(zhuǎn)交給TGS

(2)TGS作為Client-A與Server-B之間的第三方,需要為A和B分別提供SessionKeya-b,為了防止Server-B無法收到SessionKey,如圖第④步,原本需要發(fā)往Server-B的SessionKeya-b(被Server-B密碼加密為service Ticket)會一同發(fā)往Client-A,由Client-A在第⑤步中轉(zhuǎn)交給Server-B

上述過程也就是Kerberos協(xié)議的基本框架,基于微軟對Kerberos的介紹,上面其實(shí)對應(yīng)的是下面微軟提供的Kerberos協(xié)議流程:

深入解讀MS14-068漏洞:微軟精心策劃的后門?

或者你也可以認(rèn)為,是網(wǎng)上解釋MS14-068漏洞時(shí)用的這張示意圖:

深入解讀MS14-068漏洞:微軟精心策劃的后門?

具體來說,Kerberos協(xié)議分為以下步驟(第六步可選):

第①步:KRB_AS_REQ:Client-A發(fā)送Authenticator向KDC的AS服務(wù)認(rèn)證自己的身份(通過提供自身密碼加密的一個(gè)時(shí)間戳TimeStamp)

第②步:KRB_AS_REP:AS通過KDC數(shù)據(jù)庫中存儲的Client-A密碼的副本,解密收到的Authenticator,如果解密出的TimeStamp符合要求,則AS服務(wù)認(rèn)為Client-A就是所謂的Client-A。認(rèn)證成功后,AS服務(wù)生成一個(gè)短期有效的SessionKeya-kdc,將該Key使用A的密碼副本加密成密文1,另外將Key連同時(shí)間戳標(biāo)志(控制該SessionKey的有效時(shí)間)通過TGS服務(wù)的密碼也就是KDC的密碼加密為密文2(稱為TGT),將這兩個(gè)密文組合成KRB_AS_REP返回給Client-A

第③步:KRB_TGS_REQ:Client-A在接收到KRB_AS_REP后,首先使用自身密碼解密密文1得到SessionKeya-kdc,此時(shí)需要注意的是,密文2(TGT)是被KDC的密碼加密的,所以Client-A無法解密,這也是Kerberos協(xié)議設(shè)計(jì)的精妙之處,既解決了Server端(TGS相對于Client-A也稱之為Server端)無法及時(shí)接收SessionKey的問題,又不怕Client-A對該TGT的偽造,因?yàn)镃lient-A不知道Server端的密碼

得到SessionKeya-kdc后,Client-A利用其加密時(shí)間戳生成Authenticator用于向TGS申請Client-A與Client-B進(jìn)行認(rèn)證所需的SessionKeya-b,連同剛才KRB_AS_REP接收的TGT一同組合成KRB_TGS_REQ發(fā)送給TGS

第④步:KRB_TGS_REP:TGS在接收到KRB_TGS_REP之后,利用KDC密碼解密TGT獲得本來就該發(fā)送給自己的SessionKeya-kdc,然后用其解密KRB_TGS_REQ中的Authenticator得到Client-A發(fā)送過來的時(shí)間戳,如果時(shí)間戳符合要求,則生成一個(gè)短期有效的SessionKeya-b,注意此時(shí)利用SessionKeya-kdc將SessionKeya-b加密為密文1,然后利用Server-B的密碼將SessionKeya-b加密為密文2(稱為ServiceTicket),兩個(gè)密文一同構(gòu)成KRB_TGS_REP返回給Client-A

第⑤步:KRB_AP_REQ:Client-A在接收到KRB_TGS_REP之后,首先使用緩存的SessionKeya-kdc將密文1中的SessionKeya-b解密出來,然后利用其加密時(shí)間戳生成Authenticator用于向B進(jìn)行對自身的驗(yàn)證,另外,和剛才TGT一樣,密文2也就是ServiceTicket是用Server-B的密碼加密的,所以Client-A無法解密,也就無法偽造,這也同樣解決了在三方認(rèn)證中作為Server端的B無法及時(shí)接收SessionKey的問題,又不怕Client-A對ServiceTicket的偽造

第⑥步:KRB_AP_REP:Server-B受到KRB_AP_REQ之后,利用自身密碼解密ServiceTicket,得到SessionKeya-b,然后用SessionKeya-b解密Authenticator得到時(shí)間戳,驗(yàn)證A的身份

這就是整個(gè)Kerberos協(xié)議的基本流程。

0×3 PAC與Kerberos的關(guān)系

上面是標(biāo)準(zhǔn)Kerberos協(xié)議的基本流程,MIT也實(shí)現(xiàn)了一套標(biāo)準(zhǔn)的Kerberos協(xié)議,而微軟在Windows平臺上的Kerberos并沒有采用MIT的實(shí)現(xiàn),而是對Kerberos協(xié)議進(jìn)行了一些擴(kuò)充,其中最重要的擴(kuò)充就是增加了認(rèn)證過程中的權(quán)限認(rèn)證,也就是在協(xié)議中增加了PAC(Privilege
Attribute Certificate),特權(quán)屬性證書。

為什么會增加這些呢?可以這樣理解,當(dāng)用戶Client-A與Server-B完成認(rèn)證,只是向Server-B證明了Client-A就是所謂的Client-A,但此時(shí)Client-A如果需要訪問Server-B上的網(wǎng)絡(luò)資源,但Server-B現(xiàn)在其實(shí)并不知道Client-A是否有訪問自身網(wǎng)絡(luò)資源的權(quán)限(Kerberos協(xié)議中并沒有規(guī)定權(quán)限問題)

難不成此時(shí)Server-B必須再向KDC驗(yàn)證Client-A是否有訪問網(wǎng)絡(luò)資源的權(quán)限?當(dāng)然不是,微軟實(shí)現(xiàn)Kerberos認(rèn)證協(xié)議的同時(shí)巧妙地引入了PAC解決了這個(gè)問題。(至少M(fèi)S14-068漏洞之前大家是這樣認(rèn)為的)

在一個(gè)域中,如何才能知道某個(gè)域用戶所擁有的權(quán)限呢?自然是需要提供User的SID和所在組Group的SID。必須了解的一個(gè)前提是,KDC、A和B三者中,B只信任KDC所提供的關(guān)于A到底是什么權(quán)限,所以在一個(gè)域初始時(shí),KDC上擁有A和B的權(quán)限。現(xiàn)在需要解決的是,KDC必須告訴B關(guān)于A的權(quán)限,這樣B驗(yàn)證A的權(quán)限后才能決定讓不讓A訪問自身的網(wǎng)絡(luò)資源。

為了最終使得Server-B能知道Client-A所具有的權(quán)限,微軟在KRB_AS_REP中的TGT中增加了Client-A的PAC(特權(quán)屬性證書),也就是Client-A的權(quán)限,包括Client-A的User的SID、Group的SID:

深入解讀MS14-068漏洞:微軟精心策劃的后門?

可以看到被KDC加密的TGT中,不僅包括了被加密的Session
Keya-kdc,還包括KRB_AS_REQ中申請者(Client-A)的權(quán)限屬性證書,為了防止該特權(quán)證書被篡改(即使被KDC加密,Client-A無法輕易解密,但誰也無法保證絕對的安全),在PAC的尾部增加了兩個(gè)校驗(yàn)Server Signature和KDC Signature:

這兩個(gè)校驗(yàn)一個(gè)是Server Signature,另一個(gè)是KDC Signature,對于Client-A與AS服務(wù)來說,Server代表的是TGS服務(wù),KDC代表的是AS服務(wù)(AS作為Client-A與TGS的第三方信任機(jī)構(gòu)),而AS服務(wù)與TGS服務(wù)具有相同的krgtgt賬號,所以這兩個(gè)校驗(yàn)都是krgtgt賬號的密碼生成的,當(dāng)然,整個(gè)TGT也是用KDC的密碼也就是krgtgt賬號密碼加密的,它們?nèi)卟煌氖,用的算法和加密?nèi)容有所不同。

微軟是這樣打算的,無論如何也要把PAC從KDC傳送到Server-B,為了在Kerberos認(rèn)證過程中實(shí)現(xiàn),微軟選擇了如下做法:

將PAC放在TGT中加密后從AS服務(wù)經(jīng)Client-A中轉(zhuǎn)給TGS服務(wù),再放在由TGS服務(wù)返回的Service
Ticket中加密后經(jīng)Client-A中轉(zhuǎn)給Server-B

深入解讀MS14-068漏洞:微軟精心策劃的后門?

需要注意的是,在KRB_TGS_REQ階段,攜帶PAC的TGT被TGS服務(wù)接收后,認(rèn)證A的合法性后(解密Authenticator符合要求)會將PAC解密出來,驗(yàn)證尾部兩個(gè)簽名的合法性,如果合法則認(rèn)為PAC沒有被篡改,于是重新在PAC的尾部更換了另外兩個(gè)簽名,一個(gè)是Server Signature,這次是以Server-B的密碼副本生成的簽名(因?yàn)閷τ贑lient-A和Server-B,這次的第三方機(jī)構(gòu)是TGS服務(wù)),另外一個(gè)是KDC Signature,這次不再使用KDC的長期有效的Key,而是使用在AS階段生成的短期有效的SessionKeya-b,(網(wǎng)上說的是第二個(gè)簽名仍舊是KDC Key,但如果用KDC中krgtgt賬號密碼生成簽名,最后轉(zhuǎn)發(fā)給Server-B后,由于沒有krbtgt的密碼而無法驗(yàn)證第二個(gè)簽名的正確性,所以這里用SessionKeya-b生成簽名才是合理的,或許這里理解錯(cuò)了,敬請指出)最終成為New Signed PAC被拷貝在ServericeTicket中被加密起來。

最終繞過來繞過去,KDC上所擁有的關(guān)于Client-A的權(quán)限證書PAC終于發(fā)給了Server-B,Server-B在對Client-A進(jìn)行認(rèn)證的同時(shí),同時(shí)也能判斷Client-A有沒有訪問網(wǎng)絡(luò)資源的權(quán)限。

到這里PAC與Kerberos協(xié)議的關(guān)系也就明朗了。

0×4 從Pykek源碼分析MS14-068漏洞

現(xiàn)在切入正題,開始研究MS14-068漏洞的產(chǎn)生。

首先看一下微軟關(guān)于MS14-068公告板:

This security update resolves a privately reported vulnerability in Microsoft Windows Kerberos KDC th

at could allow an attacker to elevate unprivileged domain user account privileges to those of the dom

ain administrator account.An attacker could use these elevated privileges to compromise any comput

er in the domain, including domain controllers.An attacker must have valid domain credentials to expl

oit this vulnerability.

The affected component is available remotely to users who have standard user accounts withdomain c

redentials;this is not the case for users with local account credentialsonly.

仔細(xì)看看,其實(shí)這個(gè)公告板就是說了這個(gè)洞的危害,可以把沒有域控權(quán)限的普通域用戶提權(quán)為域控權(quán)限。另外,網(wǎng)上也有兩種對該漏洞產(chǎn)生原因的說法:

從客戶端解釋:

當(dāng)用戶進(jìn)行登錄身份驗(yàn)證服務(wù),服務(wù)會驗(yàn)證PAC中的簽名,并使用PAC中的數(shù)據(jù)為用戶創(chuàng)建一個(gè)登錄令牌。譬如說,如果PAC能夠攜帶有效的簽名表明“Secpulse”是“域管理”安全組的成員,那么創(chuàng)建的登錄令牌就將Secpulse當(dāng)作“域管理”組中成員。這樣的Kerberos認(rèn)證存在問題,攻擊者可以偽造身份,從域用戶提升到域管理權(quán)限。

從服務(wù)端解釋:

微博@jacktang310 程序員在實(shí)現(xiàn)KDC服務(wù)器的PAC signature時(shí)沒有嚴(yán)格控制使用checksum的算法,在原來的設(shè)計(jì)中要用到HMAC系列的checksum算法,也就是必須要有key的參與,但實(shí)現(xiàn)的時(shí)候允許所有的checksum算法都可以,包括MD5,這樣客戶端就可以偽造PAC的包了。

從上面的說法來看,該漏洞利用是通過客戶端來偽造高權(quán)限的PAC產(chǎn)生的,但根據(jù)前面對PAC與Kerberos關(guān)系的分析,貌似沒有破綻來說明客戶端有機(jī)會偽造PAC,那到底是怎么回事呢?帶著這個(gè)疑惑,我開始分析了Github上很火的PyKek攻擊包源碼。

首先,在0×1小節(jié)POC代碼測試步驟C中,使用Pykek攻擊包期間利用Wireshark抓包如下:

深入解讀MS14-068漏洞:微軟精心策劃的后門?

mimikatz在內(nèi)存新建緩存證書后,net
use過程中的抓包如下:

深入解讀MS14-068漏洞:微軟精心策劃的后門?

看到抓包結(jié)果,我立即產(chǎn)生了兩個(gè)疑惑:

(1)傳說中Kerberos協(xié)議中的KRB_AP_REQ和KRB_AP_REP過程哪里去了? (2)為什么會產(chǎn)生兩次TGS_REQ和TGS_REP過程??

第一個(gè)問題的原因很好解決,查閱資料得知,由于Kerberos協(xié)議是一種認(rèn)證網(wǎng)絡(luò)協(xié)議,它通常是其它網(wǎng)絡(luò)有關(guān)協(xié)議的前提,比如說SMB、FTP等,在SMB等協(xié)議的實(shí)現(xiàn)中SMB第一個(gè)請求包實(shí)際上會包含KRB_AP_REQ,這也就是協(xié)議整合吧,我們通過打開第一個(gè)SMB請求的數(shù)據(jù)包就可發(fā)現(xiàn):

深入解讀MS14-068漏洞:微軟精心策劃的后門?

而第二個(gè)問題,到底為什么會產(chǎn)生兩次TGS_REQ和TGS_REP過程,這個(gè)疑惑基本是我在全部分析完整個(gè)漏洞才搞懂的,但它卻影響了我整個(gè)分析過程,下面一點(diǎn)點(diǎn)向大家解釋。

既然網(wǎng)上都說,本次漏洞利用是通過客戶端偽造高權(quán)限PAC產(chǎn)生的,那PyKek工具產(chǎn)生的AS_REQ、AS_REP和TGS_REQ、TGS_REP過程中肯定有端倪,下面我們從PyKek源碼仔細(xì)分析一下

深入解讀MS14-068漏洞:微軟精心策劃的后門?

可以看到,真?zhèn)漏洞利用過程經(jīng)歷了以下幾步:

深入解讀MS14-068漏洞:微軟精心策劃的后門?

不知道你是否注意,接收AS_REP后,能解密得到TGT,但接收TGS_REP后,卻同樣接收的是TGT,這是怎么回事?原理上不是說TGS_REP之后,Client端接收的是ServiceTicket嗎?其實(shí)這就是該漏洞的根源,下面根據(jù)源碼逐步分析一下具體過程。

0×4.1 構(gòu)造AS_REQ

首先看一下AS_REQ的構(gòu)造過程,這里是代碼主體:

深入解讀MS14-068漏洞:微軟精心策劃的后門?

上面對于AS_REQ的構(gòu)造,主要用current_time和Key構(gòu)造了用于提交給AS服務(wù)驗(yàn)證的Authenticator,另外,卻增加了一個(gè)include-PAC標(biāo)志,通過查看源代碼,發(fā)現(xiàn)該include-PAC標(biāo)志被設(shè)置為了false:

深入解讀MS14-068漏洞:微軟精心策劃的后門?

查閱資料得知,微軟在實(shí)現(xiàn)PAC的過程中,特意增加了一個(gè)include-PAC標(biāo)志,通常情況下,AS_REQ請求中如果該標(biāo)志被設(shè)置為true,只要AS服務(wù)對Client-A通過認(rèn)證,那么會在返回的AS_REP數(shù)據(jù)包中的TGT中加入PAC信息;而如果在AS_REQ請求時(shí),include-PAC標(biāo)志被設(shè)置為false,那么AS_REP返回的TGT中就不會包含PAC信息。

這一點(diǎn),我們在剛才Wireshark抓包中顯示AS_REQ數(shù)據(jù)包和AS_REP數(shù)據(jù)包的大小就可以看出來(通常攜帶PAC信息的AS_REP數(shù)據(jù)包可以達(dá)到上千字節(jié))。

0×4.2 接收AS_REP

將AS_REQ發(fā)送給KDC后,KDC按照協(xié)議規(guī)定將會返回兩個(gè)東西:利用user_key加密的Session
Keya-kdc和被KDC密碼加密的TGT(不包含PAC信息)。下面我們看一下PyKek是如何接收AS_REP并解密的:

深入解讀MS14-068漏洞:微軟精心策劃的后門?

具體對session_key的解密也和之前的原理類似:

深入解讀MS14-068漏洞:微軟精心策劃的后門?

根據(jù)上面的接收過程,并參考Wireshark對AS_REP的截圖更形象地理解整個(gè)解密過程:

深入解讀MS14-068漏洞:微軟精心策劃的后門?

0×4.3 構(gòu)造PAC及TGS_REQ

之后,PyKek就開始了最重要的一步:構(gòu)造PAC并放入TGS_REQ中。下面是整個(gè)過程:

深入解讀MS14-068漏洞:微軟精心策劃的后門?

分別看一下兩個(gè)過程。

0×4.3.1 構(gòu)造PAC

深入解讀MS14-068漏洞:微軟精心策劃的后門?

由于前面我們學(xué)習(xí)了PAC的整個(gè)結(jié)構(gòu),所以不難看出來該地方構(gòu)造的PAC由三部分組成:

1. User SID & Group SID 2. Chksum of Server_key 3. Chksum of Kdc_key

通過深入跟蹤源碼,可以看出,User
SID & Group SID的構(gòu)造中,其實(shí)是將該域用戶的SID截?cái),留取前面的部分?

深入解讀MS14-068漏洞:微軟精心策劃的后門?

然后構(gòu)造高權(quán)限的User
SID & Group SID:

深入解讀MS14-068漏洞:微軟精心策劃的后門?

對于后面兩個(gè)chksum的構(gòu)造:

深入解讀MS14-068漏洞:微軟精心策劃的后門?

由前面的定義可知:

深入解讀MS14-068漏洞:微軟精心策劃的后門?

可以很容易看出,這里直接用不需要Key的MD5構(gòu)造的簽名。也就是說什么什么意思呢,只要用戶構(gòu)造了前面的data(User
SID & Group SID),只需對data進(jìn)行MD5運(yùn)算,生成一個(gè)32位的MD5值即可。

服務(wù)端對于MD5簽名又是如何驗(yàn)證的呢?它只需要將前面的data取出來,進(jìn)行MD5運(yùn)算,如果得到的MD5值,與后面的簽名一致,則認(rèn)為該簽名合法。

但是,到這里,可能會有疑問,關(guān)于PAC尾部的簽名,不是說需要server_key和kdc_key的參與嗎?這就是微軟犯的第一個(gè)錯(cuò)誤:

在KDC機(jī)構(gòu)對PAC進(jìn)行驗(yàn)證時(shí),對于PAC尾部的簽名算法,雖然原理上規(guī)定必須是帶有Key的簽名算法才可以,但微軟在實(shí)現(xiàn)上,卻允許任意簽名算法,只要客戶端指定任意簽名算法,KDC服務(wù)器就會使用指定的算法進(jìn)行簽名驗(yàn)證。

所以PyKek在客戶端的攻擊代碼中很巧妙地利用了這個(gè)漏洞,規(guī)定使用不需要Key的MD5進(jìn)行簽名,只要簽名構(gòu)造的User
SID & Group SID權(quán)限信息在傳輸過程中不改變,那么服務(wù)端肯定能驗(yàn)證通過。

那肯定有人還有疑問,PAC不是被放在TGT中嗎?但根據(jù)include-PAC標(biāo)志設(shè)置為false后,AS_REP解密得到的TGT是不攜帶PAC信息的,難不成要把構(gòu)造的PAC放在TGT中?但TGT是被KDC密碼加密的,客戶端根本無法解密。

這就是微軟犯的第二個(gè)錯(cuò)誤:

PAC沒有被放在TGT中,而是放在了TGS_REQ數(shù)據(jù)包的其它地方。但可笑的是,KDC在實(shí)現(xiàn)上竟然允許這樣的構(gòu)造,也就是說,KDC能夠正確解析出沒有放在其它地方的PAC信息。

下面我們通過TGS_REQ的構(gòu)造過程來看一下這個(gè)錯(cuò)誤。

0×4.3.2 構(gòu)造TGS_REQ

調(diào)用:

深入解讀MS14-068漏洞:微軟精心策劃的后門?

定義:

深入解讀MS14-068漏洞:微軟精心策劃的后門?

通過上面的構(gòu)造過程,結(jié)合Wireshark對TGS_REQ的截圖:

深入解讀MS14-068漏洞:微軟精心策劃的后門?

可以得知,PAC被放在了TGS_REQ數(shù)據(jù)包中的REQ_BODY中,被subkey加密了,而TGT被放在REQ_BODY前面的PADATA中,這也就是說,TGT中沒有攜帶PAC信息,并且可以注意到,TGS_REQ中也設(shè)置了include-PAC標(biāo)志信息為false。

另外得知,PAC信息被subkey加密,我們看一下subkey的來源:

深入解讀MS14-068漏洞:微軟精心策劃的后門?

subkey竟然是Client端生成的一個(gè)隨機(jī)數(shù)!

PyKek為了使得KDC能夠解密獲取被加密在REQ_BODY中的PAC信息,也一并把這個(gè)生成的subkey隨機(jī)數(shù)放在TGS_REQ數(shù)據(jù)包中的Authenticator發(fā)給了KDC服務(wù)器。

在KDC接收TGS_REQ后,可笑的是,它可以把PAC信息給解密出來了,并且由于微軟犯的第一個(gè)錯(cuò)誤:允許任意加密算法的簽名,很明顯,該P(yáng)AC信息會被驗(yàn)證為合法的PAC信息。

也就是說,微軟所犯第二個(gè)錯(cuò)誤觸發(fā)的兩個(gè)關(guān)鍵:

(1)在TGS_REQ的REQ_BODY中放上被加密的PAC信息,并把加密用到的Subkey放到Authenticator中

(2)TGS_REQ數(shù)據(jù)包中的include-PAC標(biāo)志被設(shè)置為false

只要按照上面的要求構(gòu)造TGS_REQ數(shù)據(jù)包,KDC就會“錯(cuò)誤地”將PAC信息解密并驗(yàn)證簽名正確性,但你以為這樣就完了嗎?接下來,還有更令人吃驚的事情會發(fā)生。

0×4.4 接收TGS_REP

深入解讀MS14-068漏洞:微軟精心策劃的后門?

下面是具體解密的實(shí)現(xiàn)過程:

深入解讀MS14-068漏洞:微軟精心策劃的后門?

根據(jù)Kerberos協(xié)議原理可知,在返回的TGS_REP中,TGS服務(wù)會返回給Clinet-A兩個(gè)東西:被SessionKeya-kdc加密的SessionKeya-b,另外一個(gè)是Service
Ticket,但從上面解密的過程中,Client-A解密獲取SessionKeya-b竟然用的是Subkey,而我們知道,subkey是一個(gè)客戶端隨意生成的隨機(jī)數(shù),這到底是怎么回事?

起初,我也很是疑惑,甚至都想放棄,因?yàn)閷?shí)在分析不下去了,自己分析的過程和協(xié)議原理竟然有著這么多不同,我也懷疑過PyKek作者是不是寫錯(cuò)了,但通過無數(shù)次的查找資料,終于在國外一個(gè)安全博客上找到了說法,這也是微軟犯的第三個(gè)令人吃驚的錯(cuò)誤:

只要TGS_REQ按照剛才那兩個(gè)要求設(shè)置,KDC服務(wù)器會做出令人吃驚的事情:它不僅會從Authenticator中取出來subkey把PAC信息解密并利用客戶端設(shè)定的簽名算法驗(yàn)證簽名,同時(shí)將另外的TGT進(jìn)行解密得到SessionKeya-kdc;

在驗(yàn)證成功后,把解密的PAC信息的尾部,重新采用自身Server_key和KDC_key生成一個(gè)帶Key的簽名,把SessionKeya-kdc用subkey加密,從而組合成了一個(gè)新的TGT返回給Client-A

沒錯(cuò),是重新生成一個(gè)TGT,而不是ServiceTicket。

如果你對前面對協(xié)議的介紹,很容易知道,TGT原本是通過AS_REP過程返回給Client-A的,而現(xiàn)在“毀人三觀”的事情發(fā)生了,在TGS_REP過程中,KDC竟然返回個(gè)Client-A一個(gè)TGT。

到這里就明白了,PyKek攻擊包中TGS_REP過程接收的其實(shí)是TGT,SessionKey為SessionKeya-kdc。

最終,這個(gè)TGT和SessionKeya-kdc制作成了[email protected]文件。

而接下來觀察mimikatz工具創(chuàng)建的內(nèi)存證書,也可以驗(yàn)證上述微軟所犯的第三個(gè)錯(cuò)誤:

深入解讀MS14-068漏洞:微軟精心策劃的后門?

利用TGS_REP接收的Ticket和Session
Key創(chuàng)建的內(nèi)存證書,其Server為krbtgt/SERVER.COM,再根據(jù)我們隊(duì)兩次三方認(rèn)證的理解,很容易就知道這是AS_REQ和AS_REP過程中才會將Server端認(rèn)定為krbtgt,也就是說,接收的Ticket實(shí)質(zhì)為TGT。

這樣就能理解為啥net use時(shí),會再多一次TGS_REQ和TGS_REP過程了,因?yàn)槁┒蠢眠^程中的TGS_REQ和TGS_REP所完成的并不是申請ServiceTicket,而是通過“畸形”TGS_REQ請求申請的另外一個(gè)偽造后又增加了PAC信息的TGT,所以在net use之前必須再進(jìn)行一次TGS_REQ與TGS_REP過程,利用緩存的TGT證書,申請用于net use(其Server為cifs)的ServiceTicket,這里從net use成功后,klist命令增加的內(nèi)存證書中可以驗(yàn)證這一現(xiàn)象:

深入解讀MS14-068漏洞:微軟精心策劃的后門?

對于緩存證書,這里根據(jù)微軟的說明,可以補(bǔ)充一點(diǎn)背景知識:

Credentials Cache The credentials cache is managed by the Kerberos SSP, which runs in the LSA's security context. When

ever tickets and keys need to be obtained or renewed, the LSA calls the Kerberos SSP to accomplish th

e task.From the client's point of view, a TGT is just another ticket. Before the client attempts to connect

 to any service, the client first checks the user credentials cache for a service ticket to that service. If it 

does not have one, it checks the cache again for a TGT. If it finds a TGT, the LSA fetches the correspond

ing logon session key from the cache, uses this key to prepare an authenticator, and sends both the aut

henticator and the TGT to the KDC, along with a request for a service ticket for the service. In other words, gaining admission to the KDC is no different from gaining admission to any other servi

ce in the domain—it requires a session key, an authenticator, and a ticket (in this case, a TGT).

也就是說,net use之前,系統(tǒng)會從Credentials
Cache中查看是否有ServiceTicket,如果沒有則尋找TGT,找到后就發(fā)送給KDC申請ServiceTicket。

到這里,整個(gè)漏洞的原因就清晰了。

0×5 鐵證如山:這是誰的精心策劃

下面我們總結(jié)一下通過上面的分析找到的微軟所犯的三個(gè)錯(cuò)誤:

第一個(gè)錯(cuò)誤:

在KDC機(jī)構(gòu)對PAC進(jìn)行驗(yàn)證時(shí),對于PAC尾部的簽名算法,雖然原理上規(guī)定必須是帶有Key的簽名算法才可以,但微軟在實(shí)現(xiàn)上,卻允許任意簽名算法,只要客戶端指定任意簽名算法,KDC服務(wù)器就會使用指定的算法進(jìn)行簽名驗(yàn)證。

第二個(gè)錯(cuò)誤:

PAC沒有被放在TGT中,而是放在了TGS_REQ數(shù)據(jù)包的其它地方。但可笑的是,KDC在實(shí)現(xiàn)上竟然允許這樣的構(gòu)造,也就是說,KDC能夠正確解析出沒有放在其它地方的PAC信息。

第三個(gè)錯(cuò)誤:

只要TGS_REQ按照剛才漏洞要求設(shè)置,KDC服務(wù)器會做出令人吃驚的事情:它不僅會從Authenticator中取出來subkey把PAC信息解密并利用客戶端設(shè)定的簽名算法驗(yàn)證簽名,同時(shí)將另外的TGT進(jìn)行解密得到SessionKeya-kdc;

在驗(yàn)證成功后,把解密的PAC信息的尾部,重新采用自身Server_key和KDC_key生成一個(gè)帶Key的簽名,把SessionKeya-kdc用subkey加密,從而組合成了一個(gè)新的TGT返回給Client-A

在我分析出來這些之后,我感到深深地震驚,這個(gè)漏洞的產(chǎn)生真實(shí)太不可思議了,明明PAC需要放在TGT中,而微軟添加了一個(gè)include-PAC標(biāo)志設(shè)置為false兩次后,就能導(dǎo)致PAC可以放在其它地方;明明是需要key的簽名,微軟卻允許任意簽名算法,包括不帶key的;明明是TGS_REP返回的是ServiceTicket,微軟卻根Kerberos協(xié)議開了天大的玩笑,返回了一個(gè)TGT。

我只想說,這(TMD)得需要多么大的疏忽,才能讓微軟的員工犯下如此“巧妙的”錯(cuò)誤,而且這個(gè)漏洞的觸發(fā)真的是(TMD)太需要技巧了。

到這里,我只能以一個(gè)疑問結(jié)束我的震驚:這是誰的精心策劃?答案留給讀者思考吧。

0×6 干貨:如何突破“本地賬戶才能漏洞利用”的限制

按照網(wǎng)上的測試,該漏洞一般用域用戶的本地賬戶會利用成功。

但如果做過這個(gè)漏洞測試的童鞋肯定明白,首先必須登錄域用戶得到其在域中的SID(如果大家知道如何在本地賬戶下得到域用戶的SID,請告知我!@#¥%……&*)

然后再登錄本地賬戶測試漏洞,這是一件多么蛋疼的事情,于是,基于這個(gè)問題,我開始分析為什么在域用戶下該漏洞無法利用成功。

當(dāng)然,我在域用戶下也測試過這個(gè)漏洞,當(dāng)然,起初是不成功的。但利用PyKek是可以生成[email protected],并且mimikatz也可以將該文件寫進(jìn)緩存證書,也就是說TGT在域用戶下可以被寫入內(nèi)存作為緩存證書。那問題出在哪里呢?net
use命令肯定沒問題,最終我把問題定位在了緩存證書上。

為什么這樣說呢?是因?yàn)榕既坏囊淮螠y試中,我發(fā)現(xiàn)了一個(gè)奇怪的現(xiàn)象:

在本地賬戶中沒有使用mimikatz向內(nèi)存注入緩存證書之前,其內(nèi)存中的緩存證書個(gè)數(shù)為0,而用mimikatz注入之后,變成1個(gè),net
use之后,變?yōu)?個(gè)。

也就是說,net
use后會產(chǎn)生一個(gè)ServiceTicket被放進(jìn)內(nèi)存中。這點(diǎn)沒有什么變化。

而當(dāng)我在域用戶下做類似測試時(shí),卻驚奇地發(fā)現(xiàn):

在域用戶中沒有使用mimikatz向內(nèi)存注入緩存證書之前,其內(nèi)存中的緩存證書個(gè)數(shù)是4個(gè),如下面:

深入解讀MS14-068漏洞:微軟精心策劃的后門?

而當(dāng)我使用mimikatz注入緩存證書以后,變?yōu)椋?

深入解讀MS14-068漏洞:微軟精心策劃的后門?

可以發(fā)現(xiàn),之后TGT改變了,后面的三個(gè)緩存證書沒有改變(第二個(gè)就是net
use所使用的Service
Ticket)

這里我突然又想到了緩存證書的作用:

net
use之前,系統(tǒng)會從Credentials
Cache中查看是否有ServiceTicket,如果沒有則尋找TGT,找到后就發(fā)送給KDC申請ServiceTicket。

也就是說,mimikatz工具注入后,改變的是TGT,但net
use使用的ServiceTicket沒有被修改,還是域用戶登錄時(shí)生成的普通域用戶權(quán)限的ServiceTicket,而根據(jù)對本地賬戶中測試的了解,起初內(nèi)存中是沒有net
use的ServiceTicket對應(yīng)的緩存證書的,而是注入后,net
use重新生成的緩存證書。

那關(guān)鍵就來了,有沒有辦法在域用戶環(huán)境中清除net
use需要用到的普通域用戶權(quán)限的ServiceTicket對應(yīng)的緩存證書,然后注入漏洞利用生成的高權(quán)限TGT,最后由net
use重新生成一個(gè)高權(quán)限的ServiceTicket對應(yīng)的緩存證書(本地賬戶漏洞利用過程就是這樣的)?

于是,我懷著好奇的心理,閱讀了列舉緩存證書的命令klist,果然發(fā)現(xiàn):

深入解讀MS14-068漏洞:微軟精心策劃的后門?

果然發(fā)現(xiàn)purge這個(gè)單詞,經(jīng)Google翻譯,為“清除”之意,心中竊喜,于是在域用戶下使用該命令:

深入解讀MS14-068漏洞:微軟精心策劃的后門?

果然,緩存證書被清空了,那接下來就好辦了,再次利用mimikatz注入高權(quán)限TGT的緩存證書,然后執(zhí)行:

深入解讀MS14-068漏洞:微軟精心策劃的后門?

你會發(fā)現(xiàn),在域用戶下,該漏洞也是可以利用的!


好特網(wǎng)發(fā)布此文僅為傳遞信息,不代表好特網(wǎng)認(rèn)同期限觀點(diǎn)或證實(shí)其描述。

相關(guān)視頻攻略

更多

掃二維碼進(jìn)入好特網(wǎng)手機(jī)版本!

掃二維碼進(jìn)入好特網(wǎng)微信公眾號!

本站所有軟件,都由網(wǎng)友上傳,如有侵犯你的版權(quán),請發(fā)郵件[email protected]

湘ICP備2022002427號-10 湘公網(wǎng)安備:43070202000427號© 2013~2025 haote.com 好特網(wǎng)