kerberos體系中委派的利用方式是什么

這篇文章將為大家詳細講解有關(guān)kerberos體系中委派的利用方式是什么，文章內(nèi)容質(zhì)量較高，因此小編分享給大家做個參考，希望大家閱讀完這篇文章后對相關(guān)知識有一定的了解。

一、前言

下面主要說明一下在kerberos體系中關(guān)于委派的利用方式，委派在域環(huán)境中其實是一個很常見的功能，對于委派的利用相較于先前說的幾種攻擊方式較為“被動”，但是一旦利用也會有很大的危害。

二、什么是委派

在域中如果出現(xiàn)A使用Kerberos身份驗證訪問域中的服務(wù)B，而B再利用A的身份去請求域中的服務(wù)C，這個過程就可以理解為委派。

例：

User訪問主機s2上的HTTP服務(wù)，而HTTP服務(wù)需要請求其他主機的SQLServer數(shù)據(jù)庫，但是S2并不知道User是否有權(quán)限訪問SQLServer，這時HTTP服務(wù)會利用User的身份去訪問SQLServer，如果User有權(quán)限訪問SQLServer服務(wù)才能訪問成功。

而委派主要分為非約束委派（Unconstraineddelegation）和約束委派（Constrained delegation）兩個方式，下面分別介紹兩種方式如何實現(xiàn)。

1 非約束委派

非約束委派在Kerberos中實現(xiàn)時，User會將從KDC處得到的TGT發(fā)送給訪問的service1（可以是任意服務(wù)），service1拿到TGT之后可以通過TGT訪問域內(nèi)任意其他服務(wù)，所以被稱為非約束委派。

流程：

1.  用戶通過發(fā)送KRB_AS_REQ消息請求可轉(zhuǎn)發(fā) TGT（forwardable TGT，為了方便我們稱為TGT1）。

2.  KDC在KRB_AS_REP消息中返回TGT1。

3.  用戶再通過TGT1向KDC請求轉(zhuǎn)發(fā)TGT（forwardedTGT，我們稱為TGT2）。

4.  在KRB_TGS_REP消息中返回轉(zhuǎn)發(fā)TGT2。

5.  用戶使用TGT1向KDC申請訪問Service1的ST（ServiceTicket）。

6.  TGS返回給用戶一個ST。

7.  用戶發(fā)送KRB_AP_REQ請求至Service1，這個請求中包含了TGT1和ST、TGT2、TGT2的SessionKey。

8.  Service1使用用戶的TGT2通過KRB_TGS_REQ發(fā)送給KDC，以用戶的名義請求能夠訪問Service2的票據(jù)。

9.  KDC在KRB_TGS_REP消息中返回Service2到Service1的票據(jù)。

10.  Service1以用戶的名義像Service2發(fā)送KRB_AP_REQ請求。

11.  Service2響應(yīng)步驟10中Service1的請求。

12.  Service1響應(yīng)步驟7中用戶的請求。

13.  在這個過程中的TGT轉(zhuǎn)發(fā)機制，沒有限制Service1對TGT2的使用，也就是說Service1可以通過TGT2來請求任意服務(wù)。

14.  KDC返回步驟13中請求的票據(jù)。

15和16即為Service1通過模擬用戶來訪問其他Service。

可以看到在前5個步驟中User向KDC申請了兩個TGT（步驟2和4），一個用于訪問Service1一個用于訪問Service2，并且會將這兩個都發(fā)給Service1。并且Service1會將TGT2保存在內(nèi)存中。

非約束委派的設(shè)置：

Windows域中可以直接在賬戶屬性中設(shè)置：

2 約束委派

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

從下圖可以看到整個過程其實可以分為兩個部分，第一個是S4U2Self的過程（流程1-4），第二個是S4U2Proxy的過程（流程5-10）。

流程：

1. 用戶向Service1發(fā)送請求。

2. 這時在官方文檔中的介紹是在這一流程開始之前Service1已經(jīng)通過KRB_AS_REQ得到了用戶用來訪問Service1的TGT，然后通過S4U2self擴展模擬用戶向KDC請求ST。

3. KDC這時返回給Service1一個用于用戶驗證Service1的ST（我們稱為ST1），并且Service1用這個ST1完成和用戶的驗證過程。

4. Service1在步驟3使用模擬用戶申請的ST1完成與用戶的驗證，然后響應(yīng)用戶。

注：這個過程中其實Service1是獲得了用戶的TGT和ST1的，但是S4U2Self擴展不允許Service1代表用戶去請求其他的服務(wù)。

5. 用戶再次向Service1發(fā)起請求，此時Service1需要以用戶的身份訪問Service2。這里官方文檔提到了兩個點：

A.Service1已經(jīng)驗證通過，并且有一個有效的TGT。

B.Service1有從用戶到Service1的forwardableST（可轉(zhuǎn)發(fā)ST）。個人認為這里的forwardable ST其實也就是ST1。

6. Service1代表用戶向Service2請求一個用于認證Service2的ST（我們稱為ST2）。用戶在ST1中通過cname（client name）和crealm（client realm）字段標識。

7. KDC在接收到步驟6中Service1的請求之后，會驗證PAC（特權(quán)屬性證書，在第一篇中有說明）的數(shù)字簽名。如果驗證成功或者這個請求沒有PAC（不能驗證失敗），KDC將返回ST2給Service1，不過這個ST2中cname和crealm標識的是用戶而不是Service1。

8. Service1代表用戶使用ST2請求Service2。Service2判斷這個請求來自已經(jīng)通過KDC驗證的用戶。

9. Service2響應(yīng)Service1的請求。

10. Service1響應(yīng)用戶的請求。

在這個過程中，S4U2Self擴展的作用是讓Service1代表用戶向KDC驗證用戶的合法性，并且得到一個可轉(zhuǎn)發(fā)的ST1。S4U2Proxy的作用可以說是讓Service1代表用戶身份通過ST1重新獲取ST2，并且不允許Service1以用戶的身份去訪問其他服務(wù)。更多的細節(jié)可以參考官方的文檔，和RFC4120的內(nèi)容。

同時注意forwardable字段，有forwardable標記為可轉(zhuǎn)發(fā)的是能夠通過S4U2Proxy擴展協(xié)議進行轉(zhuǎn)發(fā)的，如果沒有標記則不能進行轉(zhuǎn)發(fā)。

https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-sfu/3bff5864-8135-400e-bdd9-33b552051d94

約束委派的配置：

可以在賬戶屬性中將tsvc的委派方式更改為約束委派

三、發(fā)現(xiàn)域中的委派主機或賬戶

在域中，可以通過PowerView腳本來搜索開啟了委派的主機和用戶。查詢非約束委派主要是通過搜索userAccountControl屬性包含ADS_UF_TRUSTED_FOR_DELEGATION的主機或賬戶。而約束委派則通過查詢userAccountControl屬性包含TRUSTED_TO_AUTH_FOR_DELEGATION的主機或用戶。

1 非約束委派

通過Import-ModulePowerView.ps1加載PowerView腳本之后使用下面的命令進行查詢。

查詢域中配置非約束委派的賬戶：

Get-NetUser -Unconstrained -Domainyunying.lab

查詢域中配置非約束委派的主機：

Get-NetComputer -Unconstrained -Domainyunying.lab

在另一個版本的PowerView中采用的是Get-DomainComputer

Get-DomainComputer -Unconstrained-Properties distinguishedname,useraccountcontrol -Verbose | ft -a

2 約束委派

查詢域中配置約束委派的賬戶：

Get-DomainUser –TrustedToAuth -Propertiesdistinguishedname,useraccountcontrol,msds-allowedtodelegateto| fl

Get-DomainUser -TrustedToAuth -Domainyunying.lab

查看設(shè)置了約束委派的用戶

查詢域中配置約束委派的主機:

Get-DomainComputer -TrustedToAuth -Domainyunying.lab

四、非約束委派的利用

上文中說明了兩種委派方式，下面結(jié)合實驗說明針對兩種委派的利用方式。

實驗

首先環(huán)境和前兩篇文章相同。假設(shè)我們已經(jīng)獲取了一個已經(jīng)配置了委派的賬戶權(quán)限或者是密碼，現(xiàn)在我們通過這些條件來攻擊其他賬戶。

實驗環(huán)境：

域：YUNYING.LAB

域控：WindowsServer 2008 R2 x64(DC)：用戶Administrator

域內(nèi)主機：WindowsServer 2008 R2 x64(s2)：用戶tsvc

所需工具：

Mimikatz

實驗流程：

在域中只有服務(wù)賬戶才能有委派功能，所以先把用戶tsvc設(shè)置為服務(wù)賬號。

setspn -U -Avariant/golden tsvc

通過setspn -l tsvc查看配置成功。

然后在“AD用戶和計算機”中將tsvc設(shè)置為非約束委派模式

此時在域控上使用Administrator訪問tsvc所在主機S2的SMB服務(wù)。

我們在S2上通過mimikatz可以導(dǎo)出Administrator發(fā)送過來的TGT內(nèi)容。這里需要使用管理員權(quán)限打開mimikatz，然后通過privilege::debug命令提升權(quán)限，如果沒有提升權(quán)限會報kuhl_m_sekurlsa_acquireLSA錯誤。再使用sekurlsa::tickets/export命令導(dǎo)出內(nèi)存中所有的票據(jù)。

可以看到名稱為[0;9bec9]-2-0-60a00000-Administrator@krbtgt-YUNYING.LAB.kirbi的這一條即為Administrator發(fā)送的TGT。

此時訪問域控被拒絕。

通過

kerberos::ptt [0;9bec9]-2-0-60a00000-Administrator@krbtgt-YUNYING.LAB.kirbi

命令將TGT內(nèi)容導(dǎo)入到當(dāng)前會話中，其實這也是一次Pass The Ticket攻擊（有興趣的可以了解一下）。

通過kerberos::list查看當(dāng)前會話可以看到票據(jù)已經(jīng)導(dǎo)入到當(dāng)前會話。

導(dǎo)入之后已經(jīng)可以訪問域控的共享目錄。也就是說每當(dāng)存在用戶訪問tsvc的服務(wù)時，tsvc的服務(wù)就會將訪問者的TGT保存在內(nèi)存中，可以通過這個TGT訪問這個TGT所屬用戶的所有服務(wù)。非約束委派的原理相對簡單，就是通過獲取到的administrator的TGT進行下一步的訪問。

這里有一個點就是sekurlsa::tickets是查看內(nèi)存中所有的票據(jù)，而kerberos::list只是查看當(dāng)前會話中的kerberos票據(jù)。更多的mimikatz的使用可以參考https://github.com/gentilkiwi/mimikatz/wiki

Print Spooler服務(wù)+非約束委派提升至域控權(quán)限：

在2018年的DerbyCon中WillSchroeder（@ Harmj0y），Lee Christensen（@Tifkin_）和Matt Nelson（@ enigma0x3）提到了關(guān)于非約束委派的新方式，通過域控的Print Spooler服務(wù)和非約束委派賬戶提升至域控權(quán)限（https://adsecurity.org/?p=4056），主要的原理就是通過PrintSpooler服務(wù)使用特定POC讓域控對設(shè)置了非約束委派的主機發(fā)起請求，獲取域控的TGT，從而提升權(quán)限。

五、約束委派的利用

約束委派由于只指定了特定的服務(wù)，所以利用起來相對非約束委派更加復(fù)雜，本實驗的條件是配置了約束委派的賬號，并且已知當(dāng)前配置了約束委派的當(dāng)前賬戶的密碼（tsvc的密碼）。

1 實驗

這里環(huán)境和上文中不變，依然使用普通域賬號tsvc和域Administrator賬戶。不過增加了一個新的工具kekeo，他和mimikatz是同一個作者。

1）、確認賬號tsvc設(shè)置了約束委派。

通過工具PowerView的查詢可以看到域內(nèi)配置了約束委派的列表：

2）、使用kekeo對域控發(fā)起申請TGT的請求。

通過已知的賬戶名和明文密碼對KDC發(fā)起請求，得到TGT。

Kekeo# tgt::ask /user:tsvc /domain:yunying.lab/password:admin1234! /ticket:tsvc.kirbi

/user:當(dāng)前用戶名

/domain:所在域名

/password:當(dāng)前用戶名的密碼

/ticket:生成票據(jù)名稱，上圖里生成的沒有按參數(shù)設(shè)定的來命名，不重要，也可以直接跳過這個參數(shù)

3）、使用kekeo申請TGS票據(jù)

Kekeo#tgs::s4u /tgt:TGT_filename/user:administrator@yunying.lab /service:cifs/dc.yunying.lab

/tgt:上一步通過kekeo生成的tgt票據(jù)

/user:想要偽造的用戶名寫全稱（用戶名@域名）

/service:想要偽造訪問的服務(wù)名（服務(wù)名/主機的FQDN名稱）

4）、從kekeo中使用exit命令退出，然后使用mimikatz將生成的TGS文件導(dǎo)入到Kerberos憑據(jù)列表中

這時可以看到導(dǎo)入之后已經(jīng)能夠成功訪問域控的共享文件（嚴格來說應(yīng)該是非約束委派中設(shè)置的SPN的權(quán)限）。而且在這個過程中是不需要管理員權(quán)限的，只是用當(dāng)前賬戶的權(quán)限就可以完成，因為不需要從內(nèi)存中導(dǎo)出票據(jù)。

2 原理

下面看一下在非約束委派中是如何實現(xiàn)通過非約束委派去獲得所設(shè)置的SPN的權(quán)限的。實驗過程其實主要是三個步驟：

1、請求TGT

2、請求TGS

3、將TGS導(dǎo)入內(nèi)存

主要看1、2兩個步驟，第1步中使用Kekeo發(fā)起AS-REQ請求去請求TGT。

Kekeo# tgt::ask /user:tsvc/domain:yunying.lab /password:admin1234! /ticket:tsvc.kirbi

這時tsvc獲取到了一個TGT，并且kekeo工具將其保存為一個kirbi格式的文件。

第2步，再使用這個TGT申請兩個ST文件，上文中說到過在約束委派實現(xiàn)的過程中分為兩個部分，分別是S4U2Self擴展和S4U2Proxy擴展。S4U2Self中Service1會代替用戶向KDC申請一張用于訪問自身的TGS，這個TGS也就是生成的兩個TGS中的一個（TGS_administrator@yunying.lab@YUNYING.LAB_tsvc@YUNYING.LAB.kirbi）還有一個TGS是用于訪問非受限委派中設(shè)置的SPN的TGS（TGS_administrator@yunying.lab@YUNYING.LAB_cifs~dc.yunying.lab@YUNYING.LAB.kirbi）。

我們抓包也可以看到這里是發(fā)起了兩次TGS_REQ請求，在第一個TGS_REQ請求的包里面可以看到KRB5-PADATA-S4U2SSELF的標識。并且cname和sname都是tsvc，也是側(cè)面說明這個TGS其實就是拿來驗證自身的。

再看第二個TGS_REQ請求，sname的值為cifs/dc.yunying.lab，也就是截圖中非約束委派中“可由此賬戶提供委派憑據(jù)的服務(wù)”一欄中添加的SPN。而這個其實就是S4U2Proxy擴展中所申請的TGS票據(jù)。

關(guān)于約束委派的這種攻擊方式就是通過在Service1（tsvc）中將自己偽造成用戶，然后獲取允許約束委派的SPN的TGS的一個過程。

六、委派攻擊的防御

通過上文中說到設(shè)置了非約束委派的賬戶權(quán)限如果被竊取那么攻擊者可能獲取非常多其他賬戶的TGT，所以最好是不要在域中使用非約束委派這種功能。

域中不需要使用委派的賬戶特別是administrator賬戶，設(shè)置為“敏感用戶不能被委派”。

如果是win2012的系統(tǒng)也可以通過設(shè)置受保護的用戶組來緩解委派所帶來的危害。

在兩種方式的委派中，非約束委派的實驗獲取的權(quán)限更大，能夠通過TGT直接獲取目標主機的所有服務(wù)權(quán)限，而約束委派實驗主要是通過TGS來獲取約束委派列表中設(shè)置的SPN的TGS來獲得相應(yīng)的SPN的權(quán)限。

關(guān)于kerberos體系中委派的利用方式是什么就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，可以學(xué)到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。