תשתית Active Directory היא תשתית קריטית ברוב הארגונים, והיא מהווה את עמוד השדרה של תשתיות המחשוב בארגון. תשתית Active Directory מספקת את כלל הספריות, האובייקטים, הערכים והמשאבים שאיתם אנו עובדים ביומיום, כמו משתמשים, קבוצות ומשאבים לצורך ניהול הרשאות וגישה.
לצורך העניין, כל גישה, הרשאה או תשאול בסביבת המחשוב מצריכה מעורבות של סביבת Active Directory, ובגלל צורך זה, התשתית של Active Directory היא קריטית.
בנוסף לכך, גם בימים שאנו עושים טרנספורמציה דיגיטלית ועוברים לענן, עדיין ניתן לראות כי תצורת Active Directory הופכת להיות במצב היברידי, כמו למשל סביבת Active Directory מקומית המוגדרת מול Azure AD, עדיין מצריכה שניהול האובייקטים יהיה מתוך סביבת Active Directory מקומית.
כמו טכנולוגיות אחרות, גם Active Directory סובל מבעיות אבטחה שונות אשר רובן מוכרות, כמו Pass The hash ואחרים, אך מדובר על בעיות שניתנות להכלה וניתן לצמצם את שטח התקיפה שלהן.
ההבדל של בעיות האבטחה בסביבת Active Directory מהבעיות של טכנולוגיות אחרות הוא שברגע שישנה אחיזה מסוימת או מלאה בסביבת Active Directory – המשחק נגמר מפני שהתוקף השתלט על החלק הכי קריטי בארגון.
ישנן בעיות אבטחה שונות בסביבת Active Directory, כמו הבעיות הבאות:
• Domain Vulnerability
• Password Attack
• DC Shadow
• OverPass-the-Hash
• Kerberoasting
• LDAP Reconnaissance
• Golden Ticket
• DCSync
• AdminSDHolder Modification
• Silver Tickets
מהו Kerberoasting?
כמה אובייקטים מסוג SPNs קיימים בסביבת Active Directory שלכם? מסתבר שעשרות, מאות או יותר נכון אלפים או עשרות אלפים!
Kerberoasting מנצל את האופן שבו חשבונות מסוג Services משתמשים באימות אל מול שרתי DC's: כאשר משתמש מבצע אימות מסוים מול שרתי DC's הוא מקבל טיקט (TGT) עם חתימה של הדומיין בכדי להוכיח שאותו משתמש הוא אכן המשתמש אשר ביצע את הבקשה והאימות, פעולה זאת נעשית ע"י חשבון krbtgt.
במידת הצורך משתמש מבצע בקשות נוספות באמצעות אותו טיקט (TGS) בכדי לעבוד או לתשאל משאבים נוספים. אחת הפעולות הסטנדרטיות היא פעולות מול Service Account ופעולות נוספות, וכל אותן פעולות נעשות ע"י טיקט נוסף (TGS).
במצב כזה, הטיקט (TGS) נעשה באמצעות טיקט (TGS) מוצפן ע"י NTLM Hash של אותו Service Account ספציפי, בכדי לקבל גישה. הפעולה שמתבצעת מאחורי הקלעים היא באמצעות Kerberos, המשתמש באובייקטים מסוג SPNs בכדי לקבוע איזה Hash של Service Account ומול איזה טיקט (TGS) תתבצע הפעולה וההצפנה.
ישנם שני סוגים של אובייקטים מסוג SPNs:
• Host Based SPNs – שייכים לחשבון האובייקט של התחנה
• Arbitrary SPNs – לרוב שייכים אל חשבון משתמש
איזה אובייקט הוא עדיף למתקפה, ומי מהווה בעיית אבטחה גדולה יותר? בעקרון, שניהם חלשים באותה המידה, אך לרוב משתמשים באובייקט Arbitrary SPNs מהסיבה שאובייקט מסוג תחנה, מחליף סיסמה אחת לתקופה (30 יום) לסיסמה אקראית.
הדוגמה הכי נפוצה של אובייקט SPN, הוא שרתי SQL שמקבלים ערך MSSQLSvc/HOST:PORT, ובמצבים כאלה ישנו ערך SPN, מה שמאפשר לנו לבצע שימוש עם NTLM Hash של סיסמת החשבון עבור יצירת הטיקט (TGS) וזהו למעשה המפתח בהתקפת Kerberoasting!
איך מתבצעת המתקפה?
מכיוון שהאובייקטים מסוג SPNs נמצאים בכמויות בסביבת Active Directory, סביר להניח שהסיסמאות של האובייקטים הנ"ל חלשות מאוד, ולעיתים אף לא הוחלפו מעולם!
במצבים כאלו, שטח המתקפה פתוח ולתוקף נשאר רק לבחור איזה אובייקט לבחור ואיך לבצע את המתקפה. כאשר מבצעים את המתקפה, ישנן שתי דרכים עיקריות של ביצוע על סמך כלים או על סמך שפות כדוגמת: PowerShell או Python.
התקפה מבוססת Kerberoasting נחלקת למספר שלבים:
ביצוע Recon על הסביבה – החלק הפשוט שניתן לבצע באמצעות הפקודה הבאה שאיתה ניתן לדעת גם מהם חשבונות מסוג crackable:
([adsisearcher]”(&(objectClass=User)(primarygroupid=513) (servicePrincipalName=*))”).FindAll() | ForEach-Object { “Name:$($_.properties.name)””SPN:$($_.properties.serviceprincipalname)””Path:$($_.Path)””” }
לאחר שיש לנו רשימה, ניתן לבחור את אחד האובייקטים.
בקשת טיקט מול אותו אובייקט SPN – הפעולה הספציפית של בקשת טיקט מאפשרת לדעת האם ישנו SPB, והאם פעיל וע"י כך להמשיך מול אותו אובייקט.
Add-Type –AssemblyName System.IdentityModel
New-Object System.IdentityModel.Tokens.KerberosRequestorSecurityToken –ArgumentList “host/servername:port
חילוץ הטיקט (TGS) – הוצאת המידע מאותו טיקט יכול להיעשות ע"י הכלי MimKatz, או באמצעות הסקריפט Invoke-Kerberoast, שם אנו מקבלים מידע רלוונטי לגבי הטיקט.
הוצאת הסיסמה מהאובייקט – בשלב זה לוקחים את המידע שאספנו עד כה ומתחילים בפעולה של הוצאת המידע וגילוי הסיסמאות - וכאן הפעולה מתבצעת ע"י סקריפט מבוסס Python ויכולה להתבצע אופליין.
פריצה לחשבון – לאחר שיש לנו סיסמה ומידע לגבי אותו אובייקט אנו חוזרים לבצע פעולות ברמת Active Directory, ומתחילים לבדוק אילו הרשאות יש לאובייקט הספציפי וכאלה המתשאלים אותו.
איך מזהים?
זיהוי תקיפות שונות מול Active Directory ובפרט Kerberoasting ללא כלים מתאימים אינה אפשרית כלל, ולכן כל תשתית Active Directory מצריכה כלי מסוים.
הכלים אשר יכולים לבצע זיהוי של מתקפות Active Directory, ובפרט Kerberoasting הם Javelin וכמובן Azure ATP.
במצב שבו ישנה מתקפה מסוימת (Kerberoasting למשל), המערכת כמובן מזהה את הבעיה תוך דקות ומאפשרת לבצע ניתוח מעמיק של המתקפה.
הערה: בכדי לזהות מתקפות Active Directory שונות, צריך להפעיל Eventים שונים ברמת Group Policy ולוודא שישנה פריסה של Azure ATP agent, ומכאן יתר העבודה מתבצעת באופן אוטומטי ע"י Azure ATP.
לסיכום
אובייקטים מסוג SPNs קיימים בכל תשתית Active Directory, ולרוב אובייקטים מסוג SPNs אינם מוגנים כנדרש ובמקרים אחרים אינם מתוחזקים כלל, כולל מצבים בהם לא הוחלפה סיסמה מעולם, ולכן מדובר כאן על שטח תקיפה גדול שאינו מקבל מענה כלל.
מאת: אלי שלמה, מומחה למערכות מיקרוסופט וענן
רוצים להתעדכן בתכנים נוספים הקשורים לאבטחת ענן? הצטרפו לפורום המקצועי של IsraelClouds בתחום > להרשמה
תשתית Active Directory היא תשתית קריטית ברוב הארגונים, והיא מהווה את עמוד השדרה של תשתיות המחשוב בארגון. תשתית Active Directory מספקת את כלל הספריות, האובייקטים, הערכים והמשאבים שאיתם אנו עובדים ביומיום, כמו משתמשים, קבוצות ומשאבים לצורך ניהול הרשאות וגישה.
לצורך העניין, כל גישה, הרשאה או תשאול בסביבת המחשוב מצריכה מעורבות של סביבת Active Directory, ובגלל צורך זה, התשתית של Active Directory היא קריטית.
בנוסף לכך, גם בימים שאנו עושים טרנספורמציה דיגיטלית ועוברים לענן, עדיין ניתן לראות כי תצורת Active Directory הופכת להיות במצב היברידי, כמו למשל סביבת Active Directory מקומית המוגדרת מול Azure AD, עדיין מצריכה שניהול האובייקטים יהיה מתוך סביבת Active Directory מקומית.
כמו טכנולוגיות אחרות, גם Active Directory סובל מבעיות אבטחה שונות אשר רובן מוכרות, כמו Pass The hash ואחרים, אך מדובר על בעיות שניתנות להכלה וניתן לצמצם את שטח התקיפה שלהן.
ההבדל של בעיות האבטחה בסביבת Active Directory מהבעיות של טכנולוגיות אחרות הוא שברגע שישנה אחיזה מסוימת או מלאה בסביבת Active Directory – המשחק נגמר מפני שהתוקף השתלט על החלק הכי קריטי בארגון.
ישנן בעיות אבטחה שונות בסביבת Active Directory, כמו הבעיות הבאות:
• Domain Vulnerability
• Password Attack
• DC Shadow
• OverPass-the-Hash
• Kerberoasting
• LDAP Reconnaissance
• Golden Ticket
• DCSync
• AdminSDHolder Modification
• Silver Tickets
מהו Kerberoasting?
כמה אובייקטים מסוג SPNs קיימים בסביבת Active Directory שלכם? מסתבר שעשרות, מאות או יותר נכון אלפים או עשרות אלפים!
Kerberoasting מנצל את האופן שבו חשבונות מסוג Services משתמשים באימות אל מול שרתי DC's: כאשר משתמש מבצע אימות מסוים מול שרתי DC's הוא מקבל טיקט (TGT) עם חתימה של הדומיין בכדי להוכיח שאותו משתמש הוא אכן המשתמש אשר ביצע את הבקשה והאימות, פעולה זאת נעשית ע"י חשבון krbtgt.
במידת הצורך משתמש מבצע בקשות נוספות באמצעות אותו טיקט (TGS) בכדי לעבוד או לתשאל משאבים נוספים. אחת הפעולות הסטנדרטיות היא פעולות מול Service Account ופעולות נוספות, וכל אותן פעולות נעשות ע"י טיקט נוסף (TGS).
במצב כזה, הטיקט (TGS) נעשה באמצעות טיקט (TGS) מוצפן ע"י NTLM Hash של אותו Service Account ספציפי, בכדי לקבל גישה. הפעולה שמתבצעת מאחורי הקלעים היא באמצעות Kerberos, המשתמש באובייקטים מסוג SPNs בכדי לקבוע איזה Hash של Service Account ומול איזה טיקט (TGS) תתבצע הפעולה וההצפנה.
ישנם שני סוגים של אובייקטים מסוג SPNs:
• Host Based SPNs – שייכים לחשבון האובייקט של התחנה
• Arbitrary SPNs – לרוב שייכים אל חשבון משתמש
איזה אובייקט הוא עדיף למתקפה, ומי מהווה בעיית אבטחה גדולה יותר? בעקרון, שניהם חלשים באותה המידה, אך לרוב משתמשים באובייקט Arbitrary SPNs מהסיבה שאובייקט מסוג תחנה, מחליף סיסמה אחת לתקופה (30 יום) לסיסמה אקראית.
הדוגמה הכי נפוצה של אובייקט SPN, הוא שרתי SQL שמקבלים ערך MSSQLSvc/HOST:PORT, ובמצבים כאלה ישנו ערך SPN, מה שמאפשר לנו לבצע שימוש עם NTLM Hash של סיסמת החשבון עבור יצירת הטיקט (TGS) וזהו למעשה המפתח בהתקפת Kerberoasting!
איך מתבצעת המתקפה?
מכיוון שהאובייקטים מסוג SPNs נמצאים בכמויות בסביבת Active Directory, סביר להניח שהסיסמאות של האובייקטים הנ"ל חלשות מאוד, ולעיתים אף לא הוחלפו מעולם!
במצבים כאלו, שטח המתקפה פתוח ולתוקף נשאר רק לבחור איזה אובייקט לבחור ואיך לבצע את המתקפה. כאשר מבצעים את המתקפה, ישנן שתי דרכים עיקריות של ביצוע על סמך כלים או על סמך שפות כדוגמת: PowerShell או Python.
התקפה מבוססת Kerberoasting נחלקת למספר שלבים:
ביצוע Recon על הסביבה – החלק הפשוט שניתן לבצע באמצעות הפקודה הבאה שאיתה ניתן לדעת גם מהם חשבונות מסוג crackable:
([adsisearcher]”(&(objectClass=User)(primarygroupid=513) (servicePrincipalName=*))”).FindAll() | ForEach-Object { “Name:$($_.properties.name)””SPN:$($_.properties.serviceprincipalname)””Path:$($_.Path)””” }
לאחר שיש לנו רשימה, ניתן לבחור את אחד האובייקטים.
בקשת טיקט מול אותו אובייקט SPN – הפעולה הספציפית של בקשת טיקט מאפשרת לדעת האם ישנו SPB, והאם פעיל וע"י כך להמשיך מול אותו אובייקט.
Add-Type –AssemblyName System.IdentityModel
New-Object System.IdentityModel.Tokens.KerberosRequestorSecurityToken –ArgumentList “host/servername:port
חילוץ הטיקט (TGS) – הוצאת המידע מאותו טיקט יכול להיעשות ע"י הכלי MimKatz, או באמצעות הסקריפט Invoke-Kerberoast, שם אנו מקבלים מידע רלוונטי לגבי הטיקט.
הוצאת הסיסמה מהאובייקט – בשלב זה לוקחים את המידע שאספנו עד כה ומתחילים בפעולה של הוצאת המידע וגילוי הסיסמאות - וכאן הפעולה מתבצעת ע"י סקריפט מבוסס Python ויכולה להתבצע אופליין.
פריצה לחשבון – לאחר שיש לנו סיסמה ומידע לגבי אותו אובייקט אנו חוזרים לבצע פעולות ברמת Active Directory, ומתחילים לבדוק אילו הרשאות יש לאובייקט הספציפי וכאלה המתשאלים אותו.
איך מזהים?
זיהוי תקיפות שונות מול Active Directory ובפרט Kerberoasting ללא כלים מתאימים אינה אפשרית כלל, ולכן כל תשתית Active Directory מצריכה כלי מסוים.
הכלים אשר יכולים לבצע זיהוי של מתקפות Active Directory, ובפרט Kerberoasting הם Javelin וכמובן Azure ATP.
במצב שבו ישנה מתקפה מסוימת (Kerberoasting למשל), המערכת כמובן מזהה את הבעיה תוך דקות ומאפשרת לבצע ניתוח מעמיק של המתקפה.
הערה: בכדי לזהות מתקפות Active Directory שונות, צריך להפעיל Eventים שונים ברמת Group Policy ולוודא שישנה פריסה של Azure ATP agent, ומכאן יתר העבודה מתבצעת באופן אוטומטי ע"י Azure ATP.
לסיכום
אובייקטים מסוג SPNs קיימים בכל תשתית Active Directory, ולרוב אובייקטים מסוג SPNs אינם מוגנים כנדרש ובמקרים אחרים אינם מתוחזקים כלל, כולל מצבים בהם לא הוחלפה סיסמה מעולם, ולכן מדובר כאן על שטח תקיפה גדול שאינו מקבל מענה כלל.
מאת: אלי שלמה, מומחה למערכות מיקרוסופט וענן
רוצים להתעדכן בתכנים נוספים הקשורים לאבטחת ענן? הצטרפו לפורום המקצועי של IsraelClouds בתחום > להרשמה
לפרטים נוספים ויצירת קשר עם נציג אורקל
הודעתך לא התקבלה - נסה שוב מאוחר יותר
