מה זה SID Injection¶
בכל דומיין ב-Active Directory, לכל אובייקט - משתמש, קבוצה, מחשב - יש מזהה ייחודי בשם SID, שהמערכת משתמשת בו כדי לקבוע הרשאות. הבעיה היא שיש שדה נוסף, שנועד למטרה מנהלתית תמימה לחלוטין, שכאשר הוא לא מנוטר כמו שצריך, הופך לאחת הדרכים השקטות ביותר לזייף הרשאות ברמת היער כולו. זו בדיוק המהות של SID Injection, או בשמו המלא - התקפת SID History.
מה זה SID ולמה יש בכלל שדה של היסטוריה¶
SID - Security Identifier - הוא המזהה שהמערכת בודקת בפועל בכל פעם שהיא מחליטה אם למשתמש יש הרשאה לגשת למשהו. כשמשתמש מתחבר, הטוקן שהוא מקבל כולל את ה-SID שלו וגם את ה-SID של כל הקבוצות שהוא חבר בהן, וכל זה נבדק מול ה-ACL של המשאב המבוקש.
שדה SID History נוצר כדי לפתור בעיה אמיתית: כשארגון מעביר משתמשים מדומיין ישן לדומיין חדש (תהליך מיגרציה), רוצים שהמשתמש ימשיך לגשת למשאבים הישנים שלו גם אחרי המעבר, בלי לבנות מחדש את כל ההרשאות. הפתרון היה לאפשר לשמור בשדה SID History את ה-SID הישן של המשתמש, כך שהמערכת ממשיכה להכיר בו גם אחרי המעבר לדומיין החדש.
איך זה הופך לחולשה¶
הבעיה היא שאם מישהו מצליח לכתוב ערך שרירותי לשדה SID History של משתמש - במקום SID אמיתי ממיגרציה - הוא בעצם יכול "להזריק" לתוך אותו משתמש הרשאות של כל משתמש אחר בכל דומיין, כולל SID של קבוצת מנהלי היער (Enterprise Admins). ברגע שזה קורה, המשתמש התקוף מקבל את כל ההרשאות של אותה קבוצה בפועל, למרות שהוא מעולם לא נוסף אליה כחבר רשמי - כי המערכת בודקת גם את שדה ה-SID History בעת חישוב ההרשאות.
כדי לבצע את זה בפועל, תוקף צריך גישה ברמת שליטה על בקר הדומיין - זו לא חולשה שנגישה למשתמש רגיל, אלא בעיקר כלי להסלמה חוצת-דומיינים או חוצת-אמון (trust), אחרי שכבר הושגה דריסת רגל חזקה באחד מהם.
למה זה כל כך מסוכן ביערות עם כמה דומיינים¶
בארגונים גדולים עם כמה דומיינים ביער אחד, או עם קשרי אמון (trust) בין יערות שונים, SID Injection הוא דרך מצוינת לחצות גבולות דומיין בשקט. תוקף שהשתלט על דומיין "חלש" יכול להזריק SID של קבוצת מנהלים מדומיין "חזק" יותר לתוך משתמש שהוא שולט בו, ולקבל הרשאות שם - גם אם מעולם לא היה לו קשר ישיר לאותו דומיין.
איך מזהים ומתגוננים¶
- סינון SID (SID Filtering) - מנגנון שקיים כברירת מחדל בקשרי אמון בין יערות, ומסנן החוצה ערכי SID History שמגיעים מבחוץ. חשוב לוודא שהוא לא בוטל בטעות, כי לפעמים מבטלים אותו כדי "לפתור בעיות תאימות" בלי להבין את המחיר.
- ניטור שינויים בשדה SID History - כל שינוי בשדה הזה על משתמש קיים, שלא קשור למיגרציה מתוזמנת ומתועדת, הוא סימן אזהרה חמור.
- בדיקה תקופתית - לוודא שאין ערכי SID History שנשארו משאריות מיגרציה ישנה בלי סיבה עסקית מתמשכת.
איך לומדים את זה נכון¶
SID Injection הוא נושא מתקדם שדורש הבנה טובה של איך Active Directory מחשב הרשאות בפועל, ושל יחסי אמון בין דומיינים. מי שרוצה לבנות בסיס מוצק לפני שמתקדמים לנושאים כאלה יכול להתחיל מקורס בדיקות החדירות שלנו.
לסיכום¶
SID Injection ממחיש שוב עיקרון שחוזר על עצמו בעולם ה-Active Directory - פיצ'ר שנבנה לצורך אדמיניסטרטיבי לגיטימי הופך למסוכן ברגע שאין עליו בקרה ומעקב. הבנה של המנגנון הזה חשובה במיוחד בסביבות עם כמה דומיינים או קשרי אמון מורכבים.
יש לכם שאלות על תקיפות חוצות דומיינים? בואו לקהילה שלנו.