怎么進(jìn)行CVE-2020-17049 Kerberos Bronze Bit攻擊深入的分析

怎么進(jìn)行CVE-2020-17049 Kerberos Bronze Bit攻擊深入的分析，相信很多沒有經(jīng)驗(yàn)的人對(duì)此束手無策，為此本文總結(jié)了問題出現(xiàn)的原因和解決方法，通過這篇文章希望你能解決這個(gè)問題。

2020年11月10日，微軟發(fā)布補(bǔ)丁修復(fù)了Kerberos KDC 安全功能繞過漏洞(CVE-2020-17049，Kerberos Bronze Bit Attack)，漏洞等級(jí)為嚴(yán)重級(jí)別。2020年12月，國外安全廠商公開發(fā)布了該漏洞的驗(yàn)證腳本和詳細(xì)的技術(shù)分析并將其命名為Kerberos Bronze Bit Attack(青銅比特攻擊)，同時(shí)該漏洞的利用工具也在github上公開，導(dǎo)致該漏洞被廣泛利用的風(fēng)險(xiǎn)大大提升。

1、 漏洞背景

Kerberos協(xié)議用古希臘神話中看守地獄的三頭猛犬命名，所以Kerberos驗(yàn)證也就有三個(gè)參與者， 分別是訪問服務(wù)的Client、提供服務(wù)的Service和KDC（Key Distribution Center）密鑰分發(fā)中心。在KDC中存在兩個(gè)服務(wù)，分別是身份驗(yàn)證服務(wù)Authentication Service(簡稱AS)和票據(jù)授予服務(wù)Ticket-Granting Service(簡稱TGS)，在windows的域環(huán)境下KDC一般是在Domain Controller(簡稱DC)中的。Kerberos是基于對(duì)稱加密認(rèn)證的，Kerberos中的每個(gè)主體都具有一個(gè)密匙，該密匙只有主體本身和KDC知道。

1.1 Kerberos 協(xié)議介紹

當(dāng) Client 訪問 Server 上的某個(gè)服務(wù)時(shí)，首先要向AS 證明自己的身份，然后通過 AS 發(fā)放的 TGT 向 Server 發(fā)起認(rèn)證請(qǐng)求，這個(gè)過程分為三塊：

The Authentication Service Exchange：Client 與 AS 的交互；

The Ticket-Granting Service (TGS) Exchange：Client 與 TGS 的交互；

The Client/Server Authentication Exchange：Client 與 Server 的交互。

1.1.1 The Authentication Service Exchange

如上圖所示，Client使用用戶密匙對(duì)當(dāng)前時(shí)間戳進(jìn)行加密，并將其與用戶名一起放置在AS_REQ消息中，然后將AS_REQ消息發(fā)送到KDC。KDC通過用戶名檢索到用戶密匙，使用用戶密匙嘗試解密時(shí)間戳，若解密成功則證明該用戶的用戶密匙正確。驗(yàn)證成功后生成會(huì)話密匙，然后將會(huì)話密匙放入KRB_AS_REP消息中返回給Client。AS_REP的結(jié)構(gòu)示意圖如下所示：

AS_REP消息中包括用戶名、enc_part和TGT。enc_part是使用用戶密匙加密的，它包括服務(wù)名稱和標(biāo)志等字段以及KDC生成的會(huì)話密匙，Client可以使用用戶密匙解密后得到該會(huì)話密匙。TGT（Ticket-Granting Ticket，票據(jù)授予票據(jù)，也可以叫做黃金票據(jù)）是使用KDC密匙加密的，它包括標(biāo)志、請(qǐng)求服務(wù)的用戶名以及KDC生成的會(huì)話密匙等字段，返回TGT表示該用戶已經(jīng)被KDC成功認(rèn)證。

1.1.2 The Ticket-Granting Service (TGS) Exchange

如上圖所示，Client使用會(huì)話密匙對(duì)當(dāng)前時(shí)間戳進(jìn)行加密，并將其與請(qǐng)求的服務(wù)名、TGT一起放置在TGS_REQ消息中，然后將TGS_REQ消息發(fā)送到KDC。KDC在收到KRB_TGS_REQ后需要對(duì)TGT進(jìn)行驗(yàn)證，因此KDC通過自身密匙加密對(duì)TGT進(jìn)行解密，從解密的TGT得到會(huì)話密匙解密時(shí)間戳進(jìn)行驗(yàn)證，如果驗(yàn)證成功將返回TGS_REP消息。TGS_REP的結(jié)構(gòu)示意圖如下所示：

TGS_REP消息中包括用戶名、enc_part和ST。enc_part是使用會(huì)話密匙加密的，它包括請(qǐng)求的服務(wù)名和標(biāo)志等字段以及KDC生成的服務(wù)會(huì)話密匙，Client可以使用會(huì)話密匙解密后得到該服務(wù)會(huì)話密匙。ST（Service Ticket，服務(wù)票據(jù)，也可以叫做白銀票據(jù)）是使用服務(wù)密匙加密的，它包括標(biāo)志、請(qǐng)求服務(wù)的用戶名以及KDC生成的服務(wù)會(huì)話密匙等字段?？梢钥吹絊T的結(jié)構(gòu)和TGT很像，這是因?yàn)門GT可以看做是一種特殊的服務(wù)票據(jù)，它是TGS（Ticket-Granting Service，票據(jù)授予服務(wù)）的服務(wù)票據(jù)。下面來詳細(xì)介紹一下ST的結(jié)構(gòu)：

• 服務(wù)會(huì)話密匙：由KDC生成的服務(wù)會(huì)話密匙，Client和Service均可解密獲得。

• 標(biāo)志：Kerberos票據(jù)的標(biāo)志位包括可轉(zhuǎn)發(fā)、可更新、規(guī)范化、可更新OK等，其中可轉(zhuǎn)發(fā)（ForWardable）我們將在后續(xù)詳細(xì)討論。

• PAC： Privilege Attribute Certificate(特權(quán)屬性證書)，PAC 就是為了區(qū)別用戶的不同權(quán)限。這里的PAC分別使用了KDC的密匙和服務(wù)密匙進(jìn)行加密，防止被篡改。

1.1.3 The Client/Server Authentication Exchange

Client收到KRB_TGS_REP后使用會(huì)話密匙解密服務(wù)會(huì)話密匙，Client就可以直接和服務(wù)進(jìn)行交互，而無需使用KDC作為中間人了。

可以看到在驗(yàn)證完時(shí)間戳后，Service還會(huì)使用服務(wù)密匙解密PAC進(jìn)行驗(yàn)證，驗(yàn)證請(qǐng)求服務(wù)的用戶是否由權(quán)限訪問該服務(wù)。同時(shí)，Service也可以選擇將該P(yáng)AC發(fā)送至KDC進(jìn)行驗(yàn)證，KDC使用其密匙解密后驗(yàn)證該P(yáng)AC是否正確，如果是正確的則說明該P(yáng)AC沒有被篡改過。如果上述驗(yàn)證全部成功，則Service讓Client訪問其請(qǐng)求的資源，否則拒絕訪問。

1.2 Kerberos 委派

委派簡單來說就是A使用Kerberos身份驗(yàn)證訪問域中的服務(wù)B，而B再利用A的身份去請(qǐng)求域中的服務(wù)C。例如，當(dāng)client去訪問Server1上的HTTP服務(wù)，而HTTP服務(wù)需要請(qǐng)求server2的數(shù)據(jù)庫，但是Server1并不知道client是否有server2的數(shù)據(jù)庫訪問權(quán)限，這時(shí)HTTP服務(wù)會(huì)使用client的身份去訪問server2的數(shù)據(jù)庫，如果client有server2的數(shù)據(jù)庫訪問訪問權(quán)限就能訪問成功。

Kerberos中的委派分為非約束委派（Unconstraineddelegation）和約束委派（Constrained delegation）兩種方式，下面就這兩種方式分別進(jìn)行介紹。

1.2.1 非約束委派

用戶發(fā)送ST和TGT去訪問Service1，然后該服務(wù)可以使用用戶的TGT去向TGS請(qǐng)求其他服務(wù)的ST,然后模擬該用戶進(jìn)行操作。

可以看到由于非約束委派需要將用戶的TGT發(fā)送給Service1，那么Service就可以用該TGT模仿用戶是否獲得任何其他的ST，具有極大的不安全性。

1.2.2 約束委派

由于非約束委派的不安全性，微軟在windows2003中發(fā)布了約束委派的功能。在約束委派中client不會(huì)直接發(fā)送TGT給服務(wù)，而是對(duì)發(fā)送給service1的認(rèn)證信息做了限制，不允許service1代表User使用這個(gè)TGT去訪問其他服務(wù)。這個(gè)過程使用了一組名為S4U2Self（Service for User to Self）和S4U2Proxy（Service forUser to Proxy）的Kerberos協(xié)議擴(kuò)展。

S4U2Proxy：用戶通過域控制器請(qǐng)求訪問service1，域控驗(yàn)證并返回service1服務(wù)票據(jù)ST1，用戶發(fā)送此ST1給service1與service1認(rèn)證并建立連接。若該service1允許委派給service2，則service1能使用S4U2Proxy協(xié)議將用戶發(fā)送給自己的ST1 (此ST1必須是可轉(zhuǎn)發(fā)的)再轉(zhuǎn)發(fā)給域控制器認(rèn)證服務(wù)器，為用戶請(qǐng)求訪問service2的ST1，此后，service1便能使用新獲得的ST2模擬用戶訪問service2。如下圖所示：

S4U2Self (協(xié)議轉(zhuǎn)換)：上圖中Client是通過Kerberos協(xié)議與Service1進(jìn)行認(rèn)證的，而當(dāng)用戶以其他方式(如NTLM認(rèn)證，基于表單的認(rèn)證等方式)與Service1進(jìn)行認(rèn)證后，用戶是無法向Service1提供請(qǐng)求該服務(wù)的服務(wù)票據(jù)ST的，因而服務(wù)器也無法進(jìn)一步使用S4U2Proxy協(xié)議請(qǐng)求訪問Service2。S4U2Self協(xié)議便是解決該問題的方案，配置了TrustedToAuthForDelegation的服務(wù)向認(rèn)證服務(wù)器為用戶請(qǐng)求訪問自身的可轉(zhuǎn)發(fā)的服務(wù)票據(jù)，S4U2Self的示意圖如下圖所示：

通過S4U2Self  Service1便能夠獲得請(qǐng)求其自身服務(wù)的服務(wù)票據(jù)ST1，該ST1的Cname字段標(biāo)識(shí)為Client，此后，便可通過S4U2Proxy使用這張服務(wù)票據(jù)向域控制器請(qǐng)求訪問Service2的票據(jù)。

1.3 基于資源約束的委派

基于資源的約束委派(RBCD)是在Windows Server 2012中新加入的功能，與傳統(tǒng)的約束委派相比，它不再需要域管理員權(quán)限去設(shè)置相關(guān)屬性。RBCD把設(shè)置委派的權(quán)限賦予了機(jī)器自身，既機(jī)器通過修改msDS-AllowedToActOnBehalfOfOtherIdentity屬性來決定誰可以被委派來控制我。

2、漏洞分析及poc復(fù)現(xiàn)

2.1漏洞分析

在前面的內(nèi)容中，我們已經(jīng)介紹了Kerberos協(xié)議的認(rèn)證過程和Kerberos委派的相關(guān)知識(shí)，在介紹CVE-2020-17049 漏洞之前我們先來簡單介紹一下攻擊者如何利用約束委派進(jìn)行攻擊。

假設(shè)攻擊者已經(jīng)獲得了Service1的密碼hash值，且Service1和Service2之間存在委派信任關(guān)系（Service1配置為對(duì)Service2的約束委派或Service2接受來自Service1的基于資源約束的委派）。如果Service1允許進(jìn)行協(xié)議轉(zhuǎn)換（配置了TrustedToAuthForDelegation屬性），就可以利用impacket套件中的GetST.py腳本來獲得指定身份的Service2的服務(wù)票據(jù)ST2。具體攻擊流程如下圖所示：

利用服務(wù)票據(jù)ST2，攻擊者就能偽造成目標(biāo)用戶與Service2進(jìn)行交互。

由于委派攻擊的危害性，因此微軟官方提供了多種配置來降低委派攻擊的危害。首先可以通過禁止協(xié)議轉(zhuǎn)換（即關(guān)閉TrustedToAuthForDelegation屬性），如果下圖所示。

其次是可以在AD中配置域內(nèi)賬戶為“敏感賬戶，不能被委派”。

最后還可以將域內(nèi)賬戶添加到 “Protected Users”安全組內(nèi)，該組成員都不能通過委派進(jìn)行身份驗(yàn)證。

如果某域內(nèi)賬戶設(shè)置了上述配置至少一個(gè)，那么為該域內(nèi)賬戶申請(qǐng)服務(wù)票據(jù)時(shí)，該服務(wù)票據(jù)的“ForWardable”將始終設(shè)置為0。即Service1仍然能通過S4U2self 協(xié)議獲取該域內(nèi)賬戶的服務(wù)票據(jù)ST1，但由于該服務(wù)票據(jù)ST1的ForWardable標(biāo)志位0，那么就不能在S4U2 proxy中使用該服務(wù)票據(jù)ST1獲取其他服務(wù)票據(jù)，如下圖所示。

“ForWardable”設(shè)置為0時(shí)的TGS_REP的結(jié)構(gòu)示意圖如下圖所示。

仔細(xì)觀察上圖，可以發(fā)現(xiàn)在ST1是使用Service1密匙進(jìn)行加密的。這意味著Service1可以解密ST1后修改forwardable值，然后重新使用Service1密匙進(jìn)加密后發(fā)送給KDC ，forwardable標(biāo)志不在PAC中，所以KDC無法檢測到該值是否已經(jīng)被篡改。具體攻擊示意如下如所示：

繞過限制后，攻擊者就可以模擬目標(biāo)用戶與Service2進(jìn)行交互。

2.2POC復(fù)現(xiàn)

本節(jié)中復(fù)現(xiàn)所使用的環(huán)境為一臺(tái)Windows Server 2012的域控環(huán)境和兩臺(tái)Windows 10的普通域內(nèi)PC機(jī)器。

2.2.1 約束委派攻擊示例

首先我們需要在域控上對(duì)測試環(huán)境進(jìn)行配置，我們將Service1（域內(nèi)Windows102004機(jī)器）配置為對(duì)Service2（域內(nèi)Windows10機(jī)器）的約束委派（通過“僅使用Kerberos”選項(xiàng)來禁止協(xié)議轉(zhuǎn)換）。

同時(shí)將域內(nèi)的域管理員賬戶設(shè)置為“敏感賬戶，不能被委派”并將其添加至“Protected Users”安全組內(nèi)。

通過mimikatz或impacket 中的secretsdump.py等方式獲取域內(nèi)Service1（域內(nèi)Windows102004機(jī)器）的密碼hash。

嘗試直接使用getST.py 獲取Administrator訪問Service2（域內(nèi)Windows10機(jī)器）的服務(wù)票據(jù)ST2。

可以看到由于Administrator設(shè)置了保護(hù)，使用S4U2self獲得的服務(wù)票據(jù)ST1是不可轉(zhuǎn)發(fā)的，該票據(jù)無法在S4U2 proxy中使用，因此會(huì)導(dǎo)致出錯(cuò)。

接下來我們使用最新修改的getST.py 并添加-force-forwardable參數(shù)來對(duì)服務(wù)票據(jù)ST1進(jìn)行修改。

可以看到通過-force-forwardable參數(shù)我們將原本不可轉(zhuǎn)發(fā)的服務(wù)票據(jù)ST1修改成了可轉(zhuǎn)發(fā)的，然后用該服務(wù)票據(jù)ST1來申請(qǐng)?jiān)L問Service2的服務(wù)票據(jù)ST2。接下來就可以通過將服務(wù)票據(jù)ST2導(dǎo)入內(nèi)存就能以Administrator的身份來訪問Service2。

2.2.2 基于資源約束的委派攻擊示例

在約束委派的攻擊示例中，我們需要控制一個(gè)域內(nèi)的服務(wù)賬戶Service1且該服務(wù)賬戶配置了對(duì)目標(biāo)服務(wù)賬戶Service2的約束委派。在實(shí)際的滲透過程中是很難獲得以上條件，更多的情況是在某個(gè)站點(diǎn)上上傳了一個(gè)webshell，通過連接該webshell所獲得的權(quán)限一般都是比較小的。下面我來介紹一下如何在這種情況下利用資源約束委派和CVE-2020-17049漏洞在目標(biāo)機(jī)器上提權(quán)。

首先假設(shè)我們已經(jīng)連接到一臺(tái)域內(nèi)目標(biāo)機(jī)器的webshell，通過連接該webshell所獲得的權(quán)限為iis apppool\defaultapppool，該權(quán)限不在本地管理員中且只在當(dāng)前webshell所在目錄下有讀寫權(quán)限。

通過Webshell上傳我們的惡意程序exp.exe，并執(zhí)行該惡意程序。該惡意程序的作用在域內(nèi)是生成一個(gè)不存在機(jī)器賬戶evil1，并修改目標(biāo)機(jī)器Win10 的msDS-AllowedToActOnBehalfOfOtherIdentity屬性為evil1的SID,即配置Win10接受來自evil1的基于資源約束的委派。能夠通過iis apppool\defaultapppool修改Win10 的msDS-AllowedToActOnBehalfOfOtherIdentity是因?yàn)樵赪indows系統(tǒng)中，iis apppool\defaultapppool的出網(wǎng)身份為機(jī)器賬戶，而機(jī)器賬戶是擁有修改自身msDS-AllowedToActOnBehalfOfOtherIdentity屬性權(quán)限的。

嘗試直接使用機(jī)器賬戶密碼來運(yùn)行g(shù)etST.py提示服務(wù)票據(jù)ST1是不可轉(zhuǎn)發(fā)的，運(yùn)行S4U2 proxy失敗。

通過mimikatz獲取到evil1的密碼hash值。

重新利用getST.py 并添加-force-forwardable參數(shù)來對(duì)服務(wù)票據(jù)ST1進(jìn)行修改。

然后用該修改后的服務(wù)票據(jù)ST1來申請(qǐng)?jiān)L問Service2的服務(wù)票據(jù)ST2。接下來就可以通過將服務(wù)票據(jù)ST2導(dǎo)入內(nèi)存就能以Administrator的身份來訪問Service2。

?

看完上述內(nèi)容，你們掌握怎么進(jìn)行CVE-2020-17049 Kerberos Bronze Bit攻擊深入的分析的方法了嗎？如果還想學(xué)到更多技能或想了解更多相關(guān)內(nèi)容，歡迎關(guān)注億速云行業(yè)資訊頻道，感謝各位的閱讀！