歡迎來到 黑吧安全網 聚焦網絡安全前沿資訊,精華內容,交流技術心得!

Kerberos協議探索系列之委派篇

來源:本站整理 作者:佚名 時間:2019-03-18 TAG: 我要投稿

在前兩節中說到了關于Kerberos的掃描和Kerberoasting以及金票的利用,本文主要說明一下在kerberos體系中關于委派的利用方式,委派在域環境中其實是一個很常見的功能,對于委派的利用相較于先前說的幾種攻擊方式較為“被動”,但是一旦利用也會有很大的危害。
 
0x01什么是委派
在域中如果出現A使用Kerberos身份驗證訪問域中的服務B,而B再利用A的身份去請求域中的服務C,這個過程就可以理解為委派。
例:

User訪問主機s2上的HTTP服務,而HTTP服務需要請求其他主機的SQLServer數據庫,但是S2并不知道User是否有權限訪問SQLServer,這時HTTP服務會利用User的身份去訪問SQLServer,如果User有權限訪問SQLServer服務才能訪問成功。
而委派主要分為非約束委派(Unconstrained delegation)和約束委派(Constrained delegation)兩個方式,下面分別介紹兩種方式如何實現。
1 非約束委派
非約束委派在Kerberos中實現時,User會將從KDC處得到的TGT發送給訪問的service1(可以是任意服務),service1拿到TGT之后可以通過TGT訪問域內任意其他服務,所以被稱為非約束委派。

流程:
用戶通過發送KRB_AS_REQ消息請求可轉發 TGT(forwardable TGT,為了方便我們稱為TGT1)。
KDC在KRB_AS_REP消息中返回TGT1。
用戶再通過TGT1向KDC請求轉發TGT(forwarded TGT,我們稱為TGT2)。
4在KRB_TGS_REP消息中返回轉發TGT2。
5、用戶使用TGT1向KDC申請訪問Service1的ST(Service Ticket)。
TGS返回給用戶一個ST。
用戶發送KRB_AP_REQ請求至Service1,這個請求中包含了TGT1和ST、TGT2、TGT2的SessionKey。
Service1使用用戶的TGT2通過KRB_TGS_REQ發送給KDC,以用戶的名義請求能夠訪問Service2的票據。
KDC在KRB_TGS_REP消息中返回Service2到Service1的票據。
Service1以用戶的名義像Service2發送KRB_AP_REQ請求。
Service2響應步驟10中Service1的請求。
Service1響應步驟7中用戶的請求。
在這個過程中的TGT轉發機制,沒有限制Service1對TGT2的使用,也就是說Service1可以通過TGT2來請求任意服務。
KDC返回步驟13中請求的票據。
15和16即為Service1通過模擬用戶來訪問其他Service。
可以看到在前5個步驟中User向KDC申請了兩個TGT(步驟2和4),一個用于訪問Service1一個用于訪問Service2,并且會將這兩個都發給Service1。并且Service1會將TGT2保存在內存中。
非約束委派的設置:
Windows域中可以直接在賬戶屬性中設置:

2 約束委派
由于非約束委派的不安全性,微軟在windows2003中發布了約束委派的功能。約束委派在Kerberos中User不會直接發送TGT給服務,而是對發送給service1的認證信息做了限制,不允許service1代表User使用這個TGT去訪問其他服務。這里包括一組名為S4U2Self(Service for User to Self)和S4U2Proxy(Service for User to Proxy)的Kerberos協議擴展。
從下圖可以看到整個過程其實可以分為兩個部分,第一個是S4U2Self的過程(流程1-4),第二個是S4U2Proxy的過程(流程5-10)。

流程:
用戶向Service1發送請求。
這時在官方文檔中的介紹是在這一流程開始之前Service1已經通過KRB_AS_REQ得到了用戶用來訪問Service1的TGT,然后通過S4U2self擴展模擬用戶向KDC請求ST。
KDC這時返回給Service1一個用于用戶驗證Service1的ST(我們稱為ST1),并且Service1用這個ST1完成和用戶的驗證過程。
Service1在步驟3使用模擬用戶申請的ST1完成與用戶的驗證,然后響應用戶。
注:這個過程中其實Service1是獲得了用戶的TGT和ST1的,但是S4U2Self擴展不允許Service1代表用戶去請求其他的服務。
用戶再次向Service1發起請求,此時Service1需要以用戶的身份訪問Service2。這里官方文檔提到了兩個點:
Service1已經驗證通過,并且有一個有效的TGT。
Service1有從用戶到Service1的forwardable ST(可轉發ST)。個人認為這里的forwardable ST其實也就是ST1。
Service1代表用戶向Service2請求一個用于認證Service2的ST(我們稱為ST2)。用戶在ST1中通過cname(client name)和crealm(client realm)字段標識。
KDC在接收到步驟6中Service1的請求之后,會驗證PAC(特權屬性證書,在第一篇中有說明)的數字簽名。如果驗證成功或者這個請求沒有PAC(不能驗證失敗),KDC將返回ST2給Service1,不過這個ST2中cname和crealm標識的是用戶而不是Service1。
Service1代表用戶使用ST2請求Service2。Service2判斷這個請求來自已經通過KDC驗證的用戶。
Service2響應Service1的請求。
Service1響應用戶的請求。
在這個過程中,S4U2Self擴展的作用是讓Service1代表用戶向KDC驗證用戶的合法性,并且得到一個可轉發的ST1。S4U2Proxy的作用可以說是讓Service1代表用戶身份通過ST1重新獲取ST2,并且不允許Service1以用戶的身份去訪問其他服務。更多的細節可以參考官方的文檔,和RFC4120的內容。
同時注意forwardable字段,有forwardable標記為可轉發的是能夠通過S4U2Proxy擴展協議進行轉發的,如果沒有標記則不能進行轉發。
https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-sfu/3bff5864-8135-400e-bdd9-33b552051d94
約束委派的配置:

[1] [2] [3] [4]  下一頁

【聲明】:黑吧安全網(http://www.nkppsz.live)登載此文出于傳遞更多信息之目的,并不代表本站贊同其觀點和對其真實性負責,僅適于網絡安全技術愛好者學習研究使用,學習中請遵循國家相關法律法規。如有問題請聯系我們,聯系郵箱[email protected],我們會在最短的時間內進行處理。
  • 最新更新
    • 相關閱讀
      • 本類熱門
        • 最近下載
        秒速时时彩骗局