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

Kerberos中繼攻擊:濫用無約束委派(下)

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

一旦解析了該結構,我們就可以看到包含Kerberos票據和驗證者的AP_REQ消息。這些在Kerberos身份驗證中都很重要:
1.票據是用服務的密碼加密的,它包含標識身份驗證用戶的信息,以及加密的會話密鑰。此票據還用于委派,因為它包含一個PAC,其中包含用戶所屬的組。
2.身份驗證程序是使用會話密鑰加密的結構,它證明客戶端擁有此密鑰,并用于對客戶端進行身份驗證。
當你在Wireshark中看到這些時,很容易注意到常規Kerberos AP_REQ數據包與同時發送TGT的數據包(無約束委派)之間的區別。一個常規的AP_REQ包將包含一個加密的票據,這是AP_REQ結構中最大的子結構。在我的測試域中,票據是1180字節。如果使用無約束委派,AP_REQ中最大的子結構是authenticator(身份驗證程序),它包含用戶委托的TGT。在我的域中,這是1832字節。不包含TGT的身份驗證程序通常要小得多,大約400字節。
使用前面計算的Kerberos密鑰,我們解密票據,并得到了如下結構:
EncTicketPart:
 flags=1084555264
 key=EncryptionKey:
  keytype=23
  keyvalue=0xbd88d929fc420e8b840f3e4bcd9346b6
 crealm=INTERNAL.CORP
 cname=PrincipalName:
  name-type=1
  name-string=SequenceOf:
   testuser
 transited=TransitedEncoding:
  tr-type=1
  contents=
 authtime=20190216190927Z
 starttime=20190216190927Z
 endtime=20190217050927Z
 renew-till=20190223190927Z
 authorization-data=AuthorizationData:
  Sequence:
   ad-type=1
   ad-data=0x308202e230...e8bd0fb67130
  Sequence:
   ad-type=1
   ad-data=0x305d303fa0...6517b0000000000
其中包含票據有效性、票據的用戶名、一些授權數據(包括用戶PAC)和一個加密密鑰。這個加密密鑰是會話密鑰,我們可以用它解密AP_REQ的身份驗證程序:
Authenticator:
 authenticator-vno=5
 crealm=INTERNAL.CORP
 cname=PrincipalName:
  name-type=1
  name-string=SequenceOf:
   testuser
 cksum=Checksum:
  cksumtype=32771
  checksum=0x100000000...a3997
 cusec=84
 ctime=20190216192428Z
 subkey=EncryptionKey:
  keytype=23
  keyvalue=0x2b340c020be62cbd6284fd2977c5e303
 seq-number=1035294623
 authorization-data=AuthorizationData:
  Sequence:
   ad-type=1
   ad-data=0x3081...005000
此時,我們再次看到經過身份驗證的用戶、另一個加密密鑰(子密鑰)、更多的授權數據和校驗和。校驗和是個有趣的部分,如果它的值等于32771(或0x8003),這意味著它是一個KRBv5校驗和,這是RFC4121第4.1.1節中定義的特殊結構,顯然RFC的作者也厭倦了ASN.1,引入了另一個自定義傳輸二進制數據的格式。
在這個checksum字段中(如果設置了正確的標志),我們可以找到一個KRB_CRED結構(回到ASN.1!),其中包含了委派的TGT。
KRB_CRED:
 pvno=5
 msg-type=22
 tickets=SequenceOf:
  Ticket:
   tkt-vno=5
   realm=INTERNAL.CORP
   sname=PrincipalName:
    name-type=2
    name-string=SequenceOf:
     krbtgt     INTERNAL.CORP
   enc-part=EncryptedData:
    etype=18
    kvno=2
    cipher=0xe70d38ec...c2ec0e
 enc-part=EncryptedData:
  etype=23
  cipher=0xdea2c107a...850ba2a285
另外,還需要一個步驟將我們與TGT分隔開來,而TGT則正在解密enc-part。KRB_CRED結構的這個加密部分包含票據信息,包括與委派的TGT相關聯的會話密鑰,我們需要它在DC請求服務票據。解密后,票據將以ccache格式(由impacket使用)或以kirbi格式(這是Mimikatz用于KRB_CRED結構化文件的名稱)保存到磁盤。現在,其他工具可以使用委派的TGT對域中的任何系統進行身份驗證。
如果這還不夠詳細,本節描述的所有步驟都在krbrelayx的kerberos.py文件中進行了概述。如果在不同階段取消print語句的注釋,則可以查看整個結構。
緩解措施和無約束委派的檢測
最直接的緩解方法是盡可能避免使用無約束的委派,受約束的委派要安全得多,盡管它也可能被濫用,但受約束的委派只允許對顯式指定的服務進行身份驗證,從而可以對單個服務進行風險分析。而無約束委派則取決于連接到服務的用戶,然后將其憑據公開。如果無法避免運行具有無約束的委派權限的帳戶,則可以應用以下緩解措施:
1.請確保將具有這些權限的系統作為敏感資產加以保護,可能會出現域攻擊;
2.通過啟用“帳戶敏感且不能委派”選項來保護敏感帳戶;
3.將管理帳戶放置在“受保護的用戶”組中,這將防止它們的憑證被委派;
4.確保管理帳戶在啟用了憑據保護的最新工作站中執行操作,這將防止憑據委派。
 

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

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