הסבר על Kerberos RBCD
Resource Based Delegation

תמלול ההרצאה: הסבר על Kerberos RBCD Resource Based Delegation

הטקסט המלא של הדקות הראשונות בהרצאה «הסבר על Kerberos RBCD Resource Based Delegation» בקורס הווידאו של PracticU – כתוביות בעברית עם זמן התחלה לכל פסקה. כך תוכלו לקרוא ולחפש את הנושאים לפני שמתחילים ללמוד.

1. 00:02

   שלום לכולם בהרצאה הזו נדבר על delegation אחרון שלא קיים כאן בממשק הגרפי המציאו אותו רק ב-2012 שנקרא resource based constraint delegation המטרה זה אותה מטרה לאפשר ל-web אחד לשרת שמתחברים אליו המשתמשים שלנו ללכת בשמם לשרתי נניח sql או לשרת file server לטייל ברשת בשמם של המשתמשים דיברנו על זה שבאופציה הראשונה אי אפשר להגביל

2. 00:31

   אותו. השרת הזה, Web1 הזה, יכול לטייל בכל הרשת בשמם של יוזרים, ולמעשה הוא לוקח את ה-TGT של היוזר ולכן אי אפשר להגביל אותו.

3. 00:42

   וזה מאוד מאוד מסוכן, כי אם מישהו יפרוץ ל-Web1 הזה, הוא יוכל בשמו של כל יוזר ללכת לכל שירות ברשת.

4. 00:49

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

5. 01:18

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

6. 01:47

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

7. 02:19

   יום לשרת הזה שעומד פה מקדימה חייב להיות Service Ticket מיוזר אליו ועם ה Service Ticket הזה הוא פונה לדומיין קונטרולר ואומר תביא לי Service Ticket לשרת הפנימי הוא פונה לפרוקסי הזה שבתוך דומיין קונטרולר וההוכחה לזה שבאמת המשתמש פנה אליו לשרת הקדמי הזה לאפ 01 באמת ביקשו ממנו משהו הוא מציג את ה Service Ticket שלו שהיוזר נתן

8. 02:47

   לו ולא משנה האם יוזר קיבל אותו מדומיין קונטרולר או שהוא בעצמו בשמו של היוזר לקח את זה מדומיין קונטרולר.

9. 02:55

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

10. 03:14

    אז app01 מקבל סרוויס טיקט בשמו של יוזר ל-app02 והולך להביא לו את המידע ואז מחזיר לו את זה חזרה אם אנחנו נסתכל ברמת הפאקטים אנחנו נראה שהיוזר מתחבר לשרת הקדמי ב-HTTP ואז השרת הקדמי הזה מתחבר לדומיין קונטרולר מבקש סרוויס טיקט לעצמו מדומיין קונטרולר TGS ריקווסט TGS ריפלי ואחרי זה עם ה-TGS הזה הוא מבקש עוד סרוויס טיקט עוד TGS הפעם ליעד הסופי

11. 03:47

    שלו בכל מקרה אחרי שהוא מקבל את זה TGS הסופי הוא הולך בשמו של יוזר לשרת הקבצים נניח מביא את המידע ומחזיר ליוזר ב-HTTP בואו נראה איך זה עובד במציאות אז אנחנו מוצאים ש-Web אחד ייגש ל-SQL Server אחד בגלל שאנחנו ב-Resource Based Delegation השרת עצמו רשאי להגדיר על עצמו מי ייגש

12. 04:10

    אליו הוא לא חייב דומיין אדמין בואו נראה איך זה מוגדר נפתח PowerShell נתחיל מזה שנראה את המאפיין הזה ואנחנו רואים שהמאפיין הזה ברמת המחשב כרגע הוא ריק אין שם אף אחד מאחורי השם היפה הזה אם נעשה view advanced אנחנו נוכל לראות איפה מסתתר המידע באמת בתוך

13. 04:30

    attribute editor בתוך כל המאפיינים של sql server יש לנו מאפיין שנקרא microsoft dc allowed to act on behalf of other identities כרגע הוא ריק ברגע שאנחנו נגדיר כאן שלשרת הזה רשאי להתחבר Web 01 בשמם של כל היוזרים שהם לא Delegated תראו מה קורה בתוך הממשק הגרפי בתוך Attribute Editor אנחנו רואים שהשדה הזה פתאום קיבל ערך

14. 04:59

    לפני כן הוא היה ריק במקום לראות את זה בממשק גרפי אנחנו נראה את זה עכשיו בפאוור של אותו מידע אנחנו לוקחים את הקומפיוטר ומבקשים את ה-Property זה השם היפה שלו אבל ב-Database הוא שמור עם השם הלא יפה הזה האמיתי זה מה שקורה מאחורי הקלעים וזה כלפי חוץ בכל מקרה אנחנו רואים כאן ש-Web אחד פתאום נהיה

15. 05:22

    ברשימה הזאת של שרתים שיכולים לגשת בשמם של כל היוזרים ל-SQL Server 1 שימו לב שאנחנו מגדירים הכל על SQL Server 1 ואפשר גם למחוק את הכל לעשות clear וברגע שאני עושה clear לשדה הזה למאפיין הזה אנחנו יכולים לראות שפתאום זה נהיה ריק וכמובן שגם ממשק גרפי מסתכל בדיוק באותו דאטאבייס, NTDSD,

16. 05:48

    ואנחנו רואים פה שהשדה הזה שוב נהיה ריק. איפה יש כאן בעיית אבטחה? הבעיה היא שלהגדיר את השדה הזה לא חייב מנהל רשת. המחשב עצמו יכול להגדיר לעצמו מי רשאי לגשת אליו, בניגוד לדיליגיישנים הרגילים שהיו, שאותם יכול רק מנהל רשת להגדיר.

17. 06:06

    אז מה אפשר לעשות? אפשר לחטוף את החשבון של קורבן מסוים, זה יכול להיות Windows 11, זה לא חייב להיות שרת אנחנו הולכים לראות את זה על Windows 11 אז אנחנו חוטפים את החשבון של Windows 11 כאקרים מכניסים לשדה הזה איזשהו מחשב אחר שאנחנו שולטים עליו ומתחברים ממחשב ההוא בשמו של אדמיניסטרטור ברגע שהמחשב ההוא

18. 06:28

    מופיע כאן המחשב ההוא רשאי להמציא בלי לדעת סיסמה כל יוזר שבא לו הוא יכול לעשות בקשה כאילו אדמיניסטרטור ביקש להתחבר או כל יוזר אחר ברשת בלי לדעת אפילו את הסיסמה שלו כל עוד היוזר לא מוגדר עם ה-v של sensitive זאת אומרת אנחנו כאקרים שולטים על הקורבן הזה אומרים לו שאפשר להתחבר עליו מ-app01 ו-app01 שגם עליו אנחנו שולטים זאת אומרת אנחנו שולטים על שני

19. 06:57

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

20. 07:24

    של אדמיניסטרטור טיקט של אדמיניסטרטור ונבוא עם הטיקט של האדמיניסטרטור חזרה לאפ 02 וככה אנחנו מיוזר פשוט בתחנה הזאת נהפוך להיות