溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
怎么進行CVE-2020-17049 Kerberos Bronze Bit攻擊深入的分析，相信很多沒有經驗的人對此束手無策，為此本文總結了問題出現的原因和解決方法，通過這篇文章希望你能解決這個問題。
2020年11月10日，微軟發布補丁修復了Kerberos KDC 安全功能繞過漏洞(CVE-2020-17049，Kerberos Bronze Bit Attack)，漏洞等級為嚴重級別。2020年12月，國外安全廠商公開發布了該漏洞的驗證腳本和詳細的技術分析并將其命名為Kerberos Bronze Bit Attack(青銅比特攻擊)，同時該漏洞的利用工具也在github上公開，導致該漏洞被廣泛利用的風險大大提升。
Kerberos協議用古希臘神話中看守地獄的三頭猛犬命名，所以Kerberos驗證也就有三個參與者， 分別是訪問服務的Client、提供服務的Service和KDC（Key Distribution Center）密鑰分發中心。在KDC中存在兩個服務，分別是身份驗證服務Authentication Service(簡稱AS)和票據授予服務Ticket-Granting Service(簡稱TGS)，在windows的域環境下KDC一般是在Domain Controller(簡稱DC)中的。Kerberos是基于對稱加密認證的，Kerberos中的每個主體都具有一個密匙，該密匙只有主體本身和KDC知道。
當 Client 訪問 Server 上的某個服務時，首先要向AS 證明自己的身份，然后通過 AS 發放的 TGT 向 Server 發起認證請求，這個過程分為三塊：
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使用用戶密匙對當前時間戳進行加密，并將其與用戶名一起放置在AS_REQ消息中，然后將AS_REQ消息發送到KDC。KDC通過用戶名檢索到用戶密匙，使用用戶密匙嘗試解密時間戳，若解密成功則證明該用戶的用戶密匙正確。驗證成功后生成會話密匙，然后將會話密匙放入KRB_AS_REP消息中返回給Client。AS_REP的結構示意圖如下所示：
AS_REP消息中包括用戶名、enc_part和TGT。enc_part是使用用戶密匙加密的，它包括服務名稱和標志等字段以及KDC生成的會話密匙，Client可以使用用戶密匙解密后得到該會話密匙。TGT（Ticket-Granting Ticket，票據授予票據，也可以叫做黃金票據）是使用KDC密匙加密的，它包括標志、請求服務的用戶名以及KDC生成的會話密匙等字段，返回TGT表示該用戶已經被KDC成功認證。
1.1.2 The Ticket-Granting Service (TGS) Exchange
如上圖所示，Client使用會話密匙對當前時間戳進行加密，并將其與請求的服務名、TGT一起放置在TGS_REQ消息中，然后將TGS_REQ消息發送到KDC。KDC在收到KRB_TGS_REQ后需要對TGT進行驗證，因此KDC通過自身密匙加密對TGT進行解密，從解密的TGT得到會話密匙解密時間戳進行驗證，如果驗證成功將返回TGS_REP消息。TGS_REP的結構示意圖如下所示：
TGS_REP消息中包括用戶名、enc_part和ST。enc_part是使用會話密匙加密的，它包括請求的服務名和標志等字段以及KDC生成的服務會話密匙，Client可以使用會話密匙解密后得到該服務會話密匙。ST（Service Ticket，服務票據，也可以叫做白銀票據）是使用服務密匙加密的，它包括標志、請求服務的用戶名以及KDC生成的服務會話密匙等字段。可以看到ST的結構和TGT很像，這是因為TGT可以看做是一種特殊的服務票據，它是TGS（Ticket-Granting Service，票據授予服務）的服務票據。下面來詳細介紹一下ST的結構：
服務會話密匙：由KDC生成的服務會話密匙，Client和Service均可解密獲得。
標志：Kerberos票據的標志位包括可轉發、可更新、規范化、可更新OK等，其中可轉發（ForWardable）我們將在后續詳細討論。
PAC： Privilege Attribute Certificate(特權屬性證書)，PAC 就是為了區別用戶的不同權限。這里的PAC分別使用了KDC的密匙和服務密匙進行加密，防止被篡改。
1.1.3 The Client/Server Authentication Exchange
Client收到KRB_TGS_REP后使用會話密匙解密服務會話密匙，Client就可以直接和服務進行交互，而無需使用KDC作為中間人了。
可以看到在驗證完時間戳后，Service還會使用服務密匙解密PAC進行驗證，驗證請求服務的用戶是否由權限訪問該服務。同時，Service也可以選擇將該PAC發送至KDC進行驗證，KDC使用其密匙解密后驗證該PAC是否正確，如果是正確的則說明該PAC沒有被篡改過。如果上述驗證全部成功，則Service讓Client訪問其請求的資源，否則拒絕訪問。
委派簡單來說就是A使用Kerberos身份驗證訪問域中的服務B，而B再利用A的身份去請求域中的服務C。例如，當client去訪問Server1上的HTTP服務，而HTTP服務需要請求server2的數據庫，但是Server1并不知道client是否有server2的數據庫訪問權限，這時HTTP服務會使用client的身份去訪問server2的數據庫，如果client有server2的數據庫訪問訪問權限就能訪問成功。
Kerberos中的委派分為非約束委派（Unconstraineddelegation）和約束委派（Constrained delegation）兩種方式，下面就這兩種方式分別進行介紹。
1.2.1 非約束委派
用戶發送ST和TGT去訪問Service1，然后該服務可以使用用戶的TGT去向TGS請求其他服務的ST,然后模擬該用戶進行操作。
可以看到由于非約束委派需要將用戶的TGT發送給Service1，那么Service就可以用該TGT模仿用戶是否獲得任何其他的ST，具有極大的不安全性。
1.2.2 約束委派
由于非約束委派的不安全性，微軟在windows2003中發布了約束委派的功能。在約束委派中client不會直接發送TGT給服務，而是對發送給service1的認證信息做了限制，不允許service1代表User使用這個TGT去訪問其他服務。這個過程使用了一組名為S4U2Self（Service for User to Self）和S4U2Proxy（Service forUser to Proxy）的Kerberos協議擴展。
S4U2Proxy：用戶通過域控制器請求訪問service1，域控驗證并返回service1服務票據ST1，用戶發送此ST1給service1與service1認證并建立連接。若該service1允許委派給service2，則service1能使用S4U2Proxy協議將用戶發送給自己的ST1 (此ST1必須是可轉發的)再轉發給域控制器認證服務器，為用戶請求訪問service2的ST1，此后，service1便能使用新獲得的ST2模擬用戶訪問service2。如下圖所示：
S4U2Self (協議轉換)：上圖中Client是通過Kerberos協議與Service1進行認證的，而當用戶以其他方式(如NTLM認證，基于表單的認證等方式)與Service1進行認證后，用戶是無法向Service1提供請求該服務的服務票據ST的，因而服務器也無法進一步使用S4U2Proxy協議請求訪問Service2。S4U2Self協議便是解決該問題的方案，配置了TrustedToAuthForDelegation的服務向認證服務器為用戶請求訪問自身的可轉發的服務票據，S4U2Self的示意圖如下圖所示：
通過S4U2Self Service1便能夠獲得請求其自身服務的服務票據ST1，該ST1的Cname字段標識為Client，此后，便可通過S4U2Proxy使用這張服務票據向域控制器請求訪問Service2的票據。
基于資源的約束委派(RBCD)是在Windows Server 2012中新加入的功能，與傳統的約束委派相比，它不再需要域管理員權限去設置相關屬性。RBCD把設置委派的權限賦予了機器自身，既機器通過修改msDS-AllowedToActOnBehalfOfOtherIdentity屬性來決定誰可以被委派來控制我。
在前面的內容中，我們已經介紹了Kerberos協議的認證過程和Kerberos委派的相關知識，在介紹CVE-2020-17049 漏洞之前我們先來簡單介紹一下攻擊者如何利用約束委派進行攻擊。
假設攻擊者已經獲得了Service1的密碼hash值，且Service1和Service2之間存在委派信任關系（Service1配置為對Service2的約束委派或Service2接受來自Service1的基于資源約束的委派）。如果Service1允許進行協議轉換（配置了TrustedToAuthForDelegation屬性），就可以利用impacket套件中的GetST.py腳本來獲得指定身份的Service2的服務票據ST2。具體攻擊流程如下圖所示：
利用服務票據ST2，攻擊者就能偽造成目標用戶與Service2進行交互。
由于委派攻擊的危害性，因此微軟官方提供了多種配置來降低委派攻擊的危害。首先可以通過禁止協議轉換（即關閉TrustedToAuthForDelegation屬性），如果下圖所示。
其次是可以在AD中配置域內賬戶為“敏感賬戶，不能被委派”。
最后還可以將域內賬戶添加到 “Protected Users”安全組內，該組成員都不能通過委派進行身份驗證。
如果某域內賬戶設置了上述配置至少一個，那么為該域內賬戶申請服務票據時，該服務票據的“ForWardable”將始終設置為0。即Service1仍然能通過S4U2self 協議獲取該域內賬戶的服務票據ST1，但由于該服務票據ST1的ForWardable標志位0，那么就不能在S4U2 proxy中使用該服務票據ST1獲取其他服務票據，如下圖所示。
“ForWardable”設置為0時的TGS_REP的結構示意圖如下圖所示。
仔細觀察上圖，可以發現在ST1是使用Service1密匙進行加密的。這意味著Service1可以解密ST1后修改forwardable值，然后重新使用Service1密匙進加密后發送給KDC ，forwardable標志不在PAC中，所以KDC無法檢測到該值是否已經被篡改。具體攻擊示意如下如所示：
繞過限制后，攻擊者就可以模擬目標用戶與Service2進行交互。
本節中復現所使用的環境為一臺Windows Server 2012的域控環境和兩臺Windows 10的普通域內PC機器。
2.2.1 約束委派攻擊示例
首先我們需要在域控上對測試環境進行配置，我們將Service1（域內Windows102004機器）配置為對Service2（域內Windows10機器）的約束委派（通過“僅使用Kerberos”選項來禁止協議轉換）。
同時將域內的域管理員賬戶設置為“敏感賬戶，不能被委派”并將其添加至“Protected Users”安全組內。
通過mimikatz或impacket 中的secretsdump.py等方式獲取域內Service1（域內Windows102004機器）的密碼hash。
嘗試直接使用getST.py 獲取Administrator訪問Service2（域內Windows10機器）的服務票據ST2。
可以看到由于Administrator設置了保護，使用S4U2self獲得的服務票據ST1是不可轉發的，該票據無法在S4U2 proxy中使用，因此會導致出錯。
接下來我們使用最新修改的getST.py 并添加-force-forwardable參數來對服務票據ST1進行修改。
可以看到通過-force-forwardable參數我們將原本不可轉發的服務票據ST1修改成了可轉發的，然后用該服務票據ST1來申請訪問Service2的服務票據ST2。接下來就可以通過將服務票據ST2導入內存就能以Administrator的身份來訪問Service2。
2.2.2 基于資源約束的委派攻擊示例
在約束委派的攻擊示例中，我們需要控制一個域內的服務賬戶Service1且該服務賬戶配置了對目標服務賬戶Service2的約束委派。在實際的滲透過程中是很難獲得以上條件，更多的情況是在某個站點上上傳了一個webshell，通過連接該webshell所獲得的權限一般都是比較小的。下面我來介紹一下如何在這種情況下利用資源約束委派和CVE-2020-17049漏洞在目標機器上提權。
首先假設我們已經連接到一臺域內目標機器的webshell，通過連接該webshell所獲得的權限為iis apppool\defaultapppool，該權限不在本地管理員中且只在當前webshell所在目錄下有讀寫權限。
通過Webshell上傳我們的惡意程序exp.exe，并執行該惡意程序。該惡意程序的作用在域內是生成一個不存在機器賬戶evil1，并修改目標機器Win10 的msDS-AllowedToActOnBehalfOfOtherIdentity屬性為evil1的SID,即配置Win10接受來自evil1的基于資源約束的委派。能夠通過iis apppool\defaultapppool修改Win10 的msDS-AllowedToActOnBehalfOfOtherIdentity是因為在Windows系統中，iis apppool\defaultapppool的出網身份為機器賬戶，而機器賬戶是擁有修改自身msDS-AllowedToActOnBehalfOfOtherIdentity屬性權限的。
嘗試直接使用機器賬戶密碼來運行getST.py提示服務票據ST1是不可轉發的，運行S4U2 proxy失敗。
通過mimikatz獲取到evil1的密碼hash值。
重新利用getST.py 并添加-force-forwardable參數來對服務票據ST1進行修改。
然后用該修改后的服務票據ST1來申請訪問Service2的服務票據ST2。接下來就可以通過將服務票據ST2導入內存就能以Administrator的身份來訪問Service2。
?
看完上述內容，你們掌握怎么進行CVE-2020-17049 Kerberos Bronze Bit攻擊深入的分析的方法了嗎？如果還想學到更多技能或想了解更多相關內容，歡迎關注億速云行業資訊頻道，感謝各位的閱讀！
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
