מה זה Unconstrained Delegation¶
Active Directory מציע לפעמים פתרונות נוחים מדי. Unconstrained Delegation נועד לפתור בעיה טכנית אמיתית - שרת שצריך לפעול בשם משתמש מול שירות אחר - אבל הפתרון שנבחר פתח דלת שכל בודק חדירות מנוסה יודע לחפש ברגע שהוא מגיע לדומיין חדש.
הבעיה שהפיצ'ר הזה בא לפתור¶
תארו לעצמכם שרת אינטרנט פנימי שדורש מהמשתמש להתחבר, ואז צריך לגשת בשם אותו משתמש לשרת קבצים כדי להביא מסמך. השרת הראשון צריך "להעביר הלאה" את הזהות של המשתמש לשרת השני. זו בדיוק הבעיה שדלגציה (Delegation) ב-Kerberos נועדה לפתור - לאפשר לשירות אחד לפעול בשם המשתמש מול שירות נוסף.
מה זה בדיוק Unconstrained Delegation¶
כשמגדירים מחשב או חשבון שירות עם Unconstrained Delegation, קורה משהו משמעותי: בכל פעם שמשתמש מתחבר לאותו שרת דרך Kerberos, בקר הדומיין מצרף להיא TGT מלא של המשתמש - כלומר את מלוא הזהות שלו - ושומר אותו בזיכרון של השרת. זה נקרא "בלתי מוגבל" בדיוק כי אין שום הגבלה על מה השרת יכול לעשות עם אותו TGT. הוא לא מקבל רק הרשאה לפעול בשם המשתמש מול שירות ספציפי אחד - הוא מקבל את הזהות המלאה של המשתמש, לשימוש בכל שירות שהוא רוצה.
איך תוקף מנצל את זה¶
ברגע שתוקף משיג שליטה מלאה על שרת שמוגדר עם Unconstrained Delegation, הוא בעצם מקבל גישה למאגר של טיקטים אמיתיים - כל TGT שנשמר בזיכרון של אותו שרת שייך למשתמש אמיתי שהתחבר אליו בעבר. אם בין המשתמשים האלה נמצא מנהל דומיין, לתוקף יש עכשיו את הזהות המלאה שלו, ואיתה - שליטה מלאה על הדומיין.
התרחיש הכי מסוכן הוא כאשר בקר הדומיין עצמו מתחבר לשרת עם Unconstrained Delegation - למשל דרך תקיפה שמכריחה את בקר הדומיין ליצור חיבור (כמו הבאג המוכר בשירות הדפסה שמנצל את זה בדיוק). ברגע שזה קורה, ה-TGT שנשמר הוא TGT של חשבון המחשב של בקר הדומיין עצמו - הזדמנות ליצור Golden Ticket ולהשתלט על כל הדומיין.
איך מזהים שרתים מוגדרים כך¶
בדיקת חדירות פנימית על Active Directory תמיד כוללת שלב של איתור מחשבים וחשבונות שמוגדרים עם Unconstrained Delegation. זה מידע שנגיש דרך שאילתות LDAP רגילות לכל משתמש בדומיין, ולכן זו בדיקה זולה מאוד לבצע - וכלים כמו BloodHound מציגים את זה ויזואלית כחלק ממפת ההרשאות הכללית של הדומיין.
למה זו הגדרה שכמעט אף פעם לא באמת נחוצה¶
ברוב המקרים, המטרה המקורית של Delegation - לאפשר לשירות לפעול בשם המשתמש מול שירות אחד ספציפי - מכוסה הרבה יותר בבטחה על ידי Constrained Delegation, שמגבילה בדיוק לאילו שירותים מותר להעביר את הזהות. Unconstrained Delegation הוא כמעט תמיד שאריות מקונפיגורציה ישנה או חוסר הבנה של הסיכון, ולא צורך אמיתי.
איך מתגוננים¶
- הימנעות מוחלטת משימוש ב-Unconstrained Delegation, והחלפתו ב-Constrained Delegation או בגרסה המבוססת על תעודות (Resource-Based Constrained Delegation).
- סימון חשבונות רגישים כ"אסורים לדלגציה" (Account is sensitive and cannot be delegated), מה שמונע מהם ליפול לתוך המלכודת הזו גם אם שרת מוגדר בצורה שגויה.
- סקירה תקופתית של הגדרות הדלגציה בדומיין כחלק מביקורת אבטחה שוטפת.
איך לומדים את זה נכון¶
Unconstrained Delegation הוא נושא מתקדם שדורש הבנה טובה של Kerberos ושל מפת ההרשאות בדומיין. מי שרוצה לבנות בסיס מוצק בנושאים כאלה יכול להתחיל מקורס בדיקות החדירות שלנו.
לסיכום¶
Unconstrained Delegation הוא דוגמה מצוינת לכך שנוחות טכנית והרשאות רחבות מדי הולכות יד ביד עם סיכון. הבנה של המנגנון הזה, ואיתור מהיר שלו בכל דומיין חדש, הופכת אותו לאחד הצעדים הראשונים בכל תקיפת Active Directory מקצועית.
יש לכם שאלות על דלגציה ותקיפות Kerberos נוספות? בואו לקהילה שלנו.