6.7 תקיפת Unconstrained Delegation הרצאה

תקיפת Unconstrained Delegation – ניצול האמון של Kerberos לצורך תנועה רוחבית¶

התקפת Unconstrained Delegation (הפנייה לא מוגבלת) נחשבת לאחת מהטכניקות החזקות והמתקדמות ביותר בתהליך Privilege Escalation (הגברת הרשאות) במתקפות Active Directory. היא מנצלת את פרוטוקול האימות Kerberos וכוללת את אפשרויות ה-Delegation השונות, המאפשרות לתוקף להשתמש בהן לצורך תנועה רוחבית בתוך הרשת.

במהלך ההרצאה נלמד איך לנצל את הבעיות הקיימות ב-Delegation של Kerberos, כיצד עובד מנגנון ה-Constrained Delegation ו-Unconstrained Delegation, ונבין כיצד ניתן לבצע את ההתקפות S4U2Self, S4U2Proxy, ו-RBCD (Resource-Based Constrained Delegation).

מה זה Kerberos ו-Delegation?¶

פרוטוקול Kerberos הוא פרוטוקול אימות שמיועד בעיקר לרשתות מחשבים. זהו פרוטוקול המיועד לאימות משתמשים ומחשבים, שנעשה בו שימוש בעיקר בסביבות Windows Domain. בפרוטוקול זה, תחום האימות בוצע באמצעות Ticket-Granting Ticket (TGT), שמונפק על ידי שרת ה-Kerberos, וכולל את המידע שמאפשר למחשב להתחבר לשירותים או מחשבים אחרים ברשת בצורה מאובטחת.

כאשר Delegation היא טכניקת ניהול הרשאות ב-Active Directory שמאפשרת למחשב אחד או יישות מסוימת להיות "נציג" של מחשבים או שירותים אחרים ולהשתמש בהרשאותיהם לגישה למשאבים שונים. ישנם שני סוגים עיקריים של Delegation:

הפיצ'ר Unconstrained Delegation: מאפשר למחשב להיכנס לכל שירות במערכת עם הרשאות המשתמש שמבצע את ההתקשרות.
ולעומת זאת Constrained Delegation: מגביל את האפשרות של המחשב להיכנס רק לשירותים מסוימים ומוגדרים.

הבעיה ב-Unconstrained Delegation¶

ב-Unconstrained Delegation, כל מחשב או שרת המוגדר ככזה שיכול ל delegat את זהותו של המשתמש (לשלוח בקשה בשם המשתמש למחשב אחר) יכול להיכנס לכל שירות במערכת עם ההרשאות של אותו משתמש. אם תוקף מצליח להשתלט על מחשב כזה, הוא יכול לגנוב את ה- TGT ולהשתמש בו כדי להשיג גישה למערכות נוספות. התוקף יכול לבצע tactical lateral movement ולהתפשט לרשת דרך שירותים שהיו אמורים להיות מוגנים.

הבעיה הגדולה ביותר היא בכך ש-Unconstrained Delegation לא מגביל את המחשב או השרת המשתמש במידע הזה לגישה למחשב מסוים או משאבים מסוימים. כל המידע שנמסר בין המחשב למחשב אחר ברשת יכול לשמש את התוקף למעבר רוחבי או לתקיפות נוספות.

S4U2Self ו-S4U2Proxy¶

התקפות S4U2Self ו-S4U2Proxy הן חלק מהניצול של מנגנוני ה-Constrained Delegation. מדובר בהתקפות המתמקדות ביכולת של המחשב המארח ל delegat את ההרשאות של המשתמש לשרתים אחרים. אלה שתי התקפות שונות אך מתמקדות באותו רעיון - שליחת בקשה או קבלת שירותים בשם משתמש אחר על מנת לבצע פעולה לא מורשית.

S4U2Self - Self-Delegation:¶

ההתקפה הזו מתבצעת כאשר מחשב מצליח להשתמש בכרטיס ה-TGT של משתמש אחר כדי לגשת לשירותים מבלי שהמשתמש יידע על כך. למשל, מחשב אחד יכול לשלוח בקשה בשם משתמש אחר לשירות כדי לגשת למשאב, כשהוא עצמו לא צריך את הרשאות המשתמש. זוהי טכניקת delegation לא מבוקרת שמביאה לכך שלמחשב המפוקפק יש הרשאות חסרות הגבלה.

דוגמה ל-S4U2Self:¶

נניח שמחשב X מחובר לרשת ויש לו גישה ל-Unconstrained Delegation.
התוקף מחליף את כרטיס ה-TGT של משתמש כלשהו באמצעות Mimikatz או כלים אחרים, ושולח בקשה לשירות בשם אותו משתמש.

פקודת Mimikatz לשימוש בכרטיסי TGT של משתמש:
```
mimikatz.exe "kerberos::tgt /user:<username> /rc4:<hash>"
```
השירות מקבל את הבקשה ומספק לתוקף את ההרשאות של אותו משתמש, דבר שמאפשר לו לגשת למשאבים רגישים או לבצע פעולות אסורות.

S4U2Proxy - Proxy-Delegation:¶

ב-S4U2Proxy, התקיפה מתבצעת כשהתוקף שולח את בקשת ה-TGT של משתמש באמצעות שרת המורשה לבצע את הבקשה בשמו. במילים אחרות, מחשב שלישי (ה"מפנה") מבצע פעולות בשם המשתמש, עם אפשרות לשנות את זהותו של המשתמש באופן אוטומטי.

דוגמה ל-S4U2Proxy:¶

מחשב Z מצליח להשתלט על שרת A, שמוגדר ב-Constrained Delegation עם הרשאות להפעיל שירותים.
מחשב Z שולח את בקשת ה-TGT בשם משתמש אחר.

פקודת Mimikatz נוספת להנפקת TGT בשם משתמש אחר:
```
mimikatz.exe "kerberos::gettgt /user:<username>"
```
המחשב A מייצר את ה-TGT בשמו של המשתמש, ומחשב Z מבצע את הבקשה עם כרטיס זה.

Resource-Based Constrained Delegation (RBCD)¶

כאשר RBCD הוא טכניקת Delegation מתקדמת שהוצגה ב-Windows Server 2012. ב-RBCD, כל שרת או מחשב (Resource) יכול להגדיר איזה שרתים אחרים יכולים להיכנס אליו ולבצע פעולות על סמך ה-SID של המשתמשים.

ל-RBCD יש יתרון חשוב – היא מאפשרת לתוקפים לנצל את היכולות הללו במקרים שבהם יש תחום גישה מוגבל למחשב. ב-RBCD, המחשב שאליו יש גישה מוגבלת יוכל לאשר רק מחשבים שמוגדרים לכך, אך אם המחשב המוגדר כמשאב אינו מאובטח כראוי, התוקף יכול להערים עליו ולנצל אותו לצורך גישה לא מורשית.

דוגמה ל-RBCD:¶

תוקף מזהה מערכת שמשתמשת ב-RBCD עבור שירותים קריטיים.
התוקף משיג גישה לחשבון שנמצא תחת רשות ה-RBCD ומבצע עליו התקפות נוספות תוך כדי שליטה במערכת שהייתה אמורה להיות מאובטחת.

פקודת PowerShell כדי לבדוק את הגדרות ה-RBCD:
```
Get-ADComputer -Filter * -Properties msDS-AllowedToDelegateTo | Select-Object Name, msDS-AllowedToDelegateTo
```

שיטות זיהוי והגנה¶

הגבלת Unconstrained Delegation: חשוב להימנע משימוש ב-Unconstrained Delegation בסביבות בהן יש מידע רגיש או משאבים קריטיים. על מנהלי רשת להבטיח שזו לא אופציה פעילה בשירותים קריטיים.

פקודת PowerShell לבדוק אם ישנם מחשבים עם Unconstrained Delegation:
```
Get-ADComputer -Filter * -Properties msDS-AllowedToDelegateTo | Where-Object { $_."msDS-AllowedToDelegateTo" -eq $null } | Select-Object Name
```
הפעלת Constrained Delegation עם מגבלות ברורות: הגדרת שרתים מוגדרים לגישה עם Constrained Delegation תסייע במניעת ניצול דרך שירותים אחרים.

פקודת PowerShell להפעיל Constrained Delegation:
```
Set-ADComputer -Identity "ServerName" -Add @{ msDS-AllowedToDelegateTo = "serviceName" }
```
מעקב אחרי אתרי שירותים: חיוני להגדיר מעקב אחר שינויי שירותים והגדרות רגישות ב-Active Directory, במיוחד בנוגע לשירותים המוגדרים כ-Delegation.

פקודת Audit Policy למעקב אחר שירותים:
```
AuditPol /set /subcategory:"Logon/Logoff" /success:enable /failure:enable
```
שימוש בטכנולוגיות RBCD: אם ניתן, יש לעבור לשימוש ב-RBCD כדי לשלוט יותר בצורה מדויקת על אילו מחשבים יכולים לבצע פע