הסבר על Kerberos
Unconstrained Delegation

תמלול ההרצאה: הסבר על Kerberos Unconstrained Delegation

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

1. 00:02

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

2. 00:22

   בואו תראו איך עושים את זה. פה בתוך היוזר, נניח דיוויד, ונניח שהוא דומיין אדמין, הוא בקבוצות מאוד מאוד רגישות, ואנחנו רוצים למנוע הזדהות בשמו על ידי שרת מסוים אז אנחנו יכולים לסמן פה את ה-v הזה account is sensitive and cannot be delegated אבל לרוב אף מנהל רשת לא מסמן את זה ולא מבין

3. 00:31

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

4. 01:10

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

5. 01:35

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

6. 01:59

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

7. 02:21

   במקרה הזה אני רוצה להציל סמכות על שרת A להזדהות בשמי מול שרתים אחרים בלי הגבלה לאיזה שרת שבא לו שיזדהה לשרת b c d מה שהוא רוצה השרת a הזה למעשה יקבל את הtgt שלי ואחרי שהוא יקבל את הtgt שלי הוא ילך בשמי להזדהות מול כולם בוא נעבור על כל התהליך כמו שצריך שלב ראשון אני מזדהה מול הדומיין קונטרולר זה אומר שאני חייב להיות ברשת פנימית בתוך הארגון או דרך vpn מחובר לארגון

8. 02:55

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

9. 03:06

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

10. 03:20

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

11. 03:33

    כשהמשתמש ירצה לגשת לאיזשהו שירות, נניח לשירות A, הוא לוקח את ה-TGT ואיתו מבקש מדומיין קונטרולר TGS - Ticket Granting Service, מבקש ממנו טיקט עבור שירות מסוים, נניח נקרא לו Service A, ואת השם של השירות הוא מעביר ב-SPN.

12. 03:52

    כל זה הסברנו בהרצאות קודמות אז אני רץ מהר על ההסבר הזה הוא מבקש Service Ticket עבור SPN של Service A ומקבל אותו חזרה ועם ה-TGS הזה עם ה-Service Ticket הזה הוא הולך ל-Service A אבל שימו לב ביחד עם ה-TGS הוא מעביר לו גם את ה-TGT שלו אבל לא את המקורי את ה-TGT בגרזת Delegated לא כתוב פה אבל מאחורי הקלעים הוא הלך לשרת Domain

13. 04:19

    Controller ביקש עוד TGT מסוג דיליגייטד כביכול tgt סוג ב' שאי אפשר להחליף איתו סיסמה לדוגמה ליוזר שהוא לא פריימרי ואז הוא לוקח את הtgs הזה שהוא קיבל עבור שירות a יחד עם tgt מסוג דיליגייטד הtgt סוג ב' אני קורא לו ומעביר את זה לסרוויס a

14. 04:38

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

15. 05:05

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

16. 05:25

    מקורי או Service A בשמו של היוזר. אז Unconstrained Delegation הזה, החלק המרכזי שהיוזר מעביר את ה-TGT שלו ל-Service A. ו-Service A יכול עם ה-TGT שלו לעשות מה שהוא רוצה.

17. 05:38

    ברגע שיש לך TGT, אתה כאילו היוזר עצמו. וכמובן שאם האקר פורץ ל-Service A ומשתלט על המחשב הזה, ומצליח נניח מתוך הזיכרון שלו לגנוב את ה-TGT, של יוזרים שהגיעו אז הוא יכול לפרוץ את כל הרשת ולכן unconstrained delegation מאוד מאוד מסוכן וזאת הייתה האופציה היחידה כשיצא קרברוס בשנת 2000 האופציה הזאת trust is computer for delegation to any service למה

18. 06:05

    any service כי פשוט אני מקבל tgt של היוזר אבל יש פה catch חייבים רק קרברוס זה אומר שהיוזר לא יכול להיות באמת בבית הוא חייב להיות ברשת הפנימית שלי או בvpn אני לא יכול לעשות את זה ובי אני חייב חייב שהוא יהיה חלק מדומיין ושליוזר עצמו יהיה גישה ל-DC וזאת מגבלה די רצינית תחשבו שאני רוצה לתת שירות לאנשים בבית ובמקרה כזה אני חייב VPN

19. 06:33

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

20. 06:54

    של השרת אפשר יהיה לגנוב TGTים כי הם ישבו שמה ונניח מי מקצ יודע לעשות את זה ודבר שני האופציה הזאת היא בעייתית כי אני חייב להקים שרת VPN ולהשתמש במחשב שבדומיין אפילו שהוא