פורום

בדיקת חדירות

יוגב 22 ינואר 2019

בדיקת חדירות (Pentest \ Penetration Test)

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

פועלים בעיקר לפי שלושה סוגי מבדקים (על בסיס סוג המבדק מבצעים את הבדיקה בהתאם לתחום הנדרש, ראה פירוט מטה):

  • Black Box
  • White Box
  • Gray Box

סוגי מבדקים

Black Box

בדיקה זאת מתבצעת בדרך כלל כבדיקה חיצונית, לפחות כך היא מתחילה ובמידה והבודק מצליח לחדור פנימה, היא יכולה להמשיך גם לתוך הארגון, כמובן שהכול תלוי במהי מטרת הבדיקה ומה הגבול שסוכם מראש שבמידה ומגיעים ליעד ניתן לעצור. בדיקה זו מתבססת על סמך זה שהבודק אינו מקבל שום פרט או מידע מקדים על הארגון או על המערכות הקיימות בארגון, בדיקה זו בעצם מדמה מצב מציאותי ביותר ובו “האקר” רוצה לפרוץ לארגון כאשר אין לו שייכות לארגון כלל ואין לו מידע פנימי. בדיקה זו בדרך כלל ארוכה יותר היות וחלק גדול מהבדיקה הינו איסוף מידע, קיים חיסרון נוסף והוא שסביר להניח שבדיקה זו לא תכסה את כל המערכות “והשטחים” הקיימים בארגון.

בבדיקות תוכנה ובדיקות WEB Application בדיקה מסוג Black Box משמעותה בדיקת האפליקצייה כאשר אין שום מידע מקדים עליה ואין לבודק גישה לקוד התוכנה או לאפיון שלה לצורך מציאת פגיעויות בקוד עצמו.

White Box

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

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

Gray Box

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

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

ניתן לחלק את הבדיקות גם לפי : בדיקה חיצונית, בדיקה פנימית, בדיקה משולבת.

תחומי המבדקים הקיימים

מבדק חדירה פנימי (Internal Penetration Test)

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

במהלך בדיקת חדירות פנימית אנו מנסים להעלות את ההרשאות שלנו (אסקלציה) ככל האפשר כדי לקבל גישה לכל ההתקנים אשר נכללים בבדיקה.

כהוכחת הבדיקה ואימות הנתונים אנו נציין בדוח בין השאר את הפרטים הבאים שימצאו במהלך הבדיקה:

• סיסמאות גישה ניהוליות

• סיסמאות גישה למסדי נתונים

• תצלומי מסך

• הודעות מייל סודיות

• מסמכים סודיים וכו’

מבדק חדירות פנימי מתנהל לפי הסטנדרטים הרגילים של מבדקי חדירות:

• איסוף מידע על הרשת הפנימית

• סריקת פגיעויות

• זיהוי חולשות רלוונטיות

• ביצוע ניסיונות תקיפה

• הכנת דו”ח כולל

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

אבחון רשת חיצוני

מבדק חדירה חיצוני (External Penetration Test) – זהו מבדק שבו נבדקת יכולת מערכות המחשוב של הארגון לעמוד בפני התקפות חיצוניות, בדרך כלל התקפות אלו מתרחשות ללא מידע מקדים על פנים הארגון, מצב זה בא לדמות ניסיון תקיפה מכוון של תוקף חיצוני או ניסיון תקיפה “רנדומלי” שתוקף את הארגון.

בתהליך זה אנו סורקים את מערכות המידע והרשת הנגישות לנו מחוץ לארגון בכוונה לנסות ולאתר נקודות תורפה קיימות המובילות לחדירה או נזק לארגון.

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

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

• איסוף מידע חיצוני אודות הארגון ובדיקת הרלוונטיות שלו לגבי בדיקת החדירות.

• ביצוע סריקת פגיעויות לצורך זיהוי נקודות חולשה קיימות.

• ביצוע סקר סיכונים המתבסס על תוצאות הסריקה לצורך תעדוף ורלוונטיות הממצאים.

• ביצוע תהליך “פריצה בטוחה” על סמך הממצאים הקודמים.

• בדיקות התקני הרשת הנגישים מחוץ לארגון, כגון FW, נתבים, שרתי דואר וכו’.

• הכנת דו”ח מקיף.

אבחון Web Application

בקצרה בדיקת חדירות היא שיטה להעריך את האבטחה בהתקן מחשוב רשת על ידי הדמיית התקפה, מבדק חדירות אפליקטיבי ( WEB Application) מתמקד רק על הערכת מצב האבטחה של האפליקציה, שאנו אומרים אפליקציה כמובן שאתר אינטרנט נכנס לתוך הקטגוריה.

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

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

מבדקי ה-WEB שלנו מתמקדים לפי בסיס ה- OWASP – Open Web Application Security Project אשר מנחה וממקד את החולשות העיקריות והכי חשובות בצד האפליקטיבי.

אבחון הנדסה חברתית

ביצוע מבדק חדירה המשלב מבדק “הנדסה חברתית” אשר כולל בדיקת המודעות של העובדים, כולל ניסיון לחדור ולתקוף את הארגון על ידי התקפות מסוג “הנדסה חברתית” ולאחר מכן להסיק מסקנות ולשתף את העובדים בתוצאות.

קרא עוד...

מתודולוגיית מבחן חדירות

יוגב 22 ינואר 2019

הצבת יעדים ומטרות (Pre-engagement Interactions)

בשלב הראשון נדון בהיקף האבחון, תיאום ציפיות והגדרת יעדי המבדק אשר יעזרו לנו לבנות מודל מתודולוגי שילווה את צוות הבודקים בכל שבעת שלבי PTES (המתודולוגיה שלנו בנויה על בסיס PTES – http://www.pentest-standard.org/index.php/Main_Page) .

בשלב זה בין השאר נקבעים הנושאים הבאים:

  • סוג המבדק (חיצוני \ פנימי \ משולב וכו’)
  • מטרת המבדק (היעד הסופי שנקבע שברגע שהוא מושג המבדק מסתיים)
  • הגבלות וחוקים (יצירת כללי עבודה מוסכמים מראש, לאן מותר להגיע ומה מותר לעשות, באילו שעות תתאפשר ביצוע הבדיקה, אילו שרתים קריטיים יותר ואילו פחות ובאילו מערכות מותר לבצע את תהליך ה- Exploitation)
  • היקף המבדק (מיפוי כתובות רשת, כמות התקנים ברשת, כמות שרתים\תחנות עבודה וכו’)
  • האם המבדק יכלול בדיקות של תפקוד עובדי החברה וצוות המחשוב, בעיקר מדובר על מבדקים של הנדסה חברתית (Social Engineering)
  • הגדרת לוח זמנים

איסוף מידע (Intelligence Gathering)

שלב זה מוגדר בשפה המקצועית – “reconnaissance”. בשלב זה הבודק מתחיל באיסוף מידע אודות הארגון, דרכי איסוף המידע משתנות ומתבססות על פי סוג הבדיקה לדוגמה: בבדיקה חיצונית איסוף המידע יתבסס יותר על מקורות גלויים וחיצוניים כגון רשתות חברתיות, מנועי חיפוש וכו’, לעומת מבדק פנים ארגוני אשר בו איסוף המידע יתבסס פחות על מקורות חיצוניים וגלויים אלא על סמך המידע אשר ניתן להוציא מתוך מערכות החברה.

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

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

(Black Box \ Gray-Box).

 

בניית מודל לפריצה (Threat Modeling)

בשלב זה הבודק מתחיל לנתח ו-“לנצל” את כל המידע אשר נאסף בשלב איסוף המידע, הבודק מתחיל לזהות את נקודות התורפה של הארגון, באילו מערכות מידע יש יותר סיכוי להצליח בהתקפה, מהן ההתקפות העומדות על הפרק על סמך מערכות המידע שנבדקו.

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

זיהוי פגיעויות וניתוח נקודות תורפה (Vulnerability Analysis)

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

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

ניצול חולשות אבטחה (Exploitation)

שלב זה הנו השלב שאליו הבודק מייחל להגיע, שלב זה אינו קל אך מביא לסיפוק על ידי כך שבמידה ופעולות התקיפה מצליחות יש תמורה לכל השלבים שלפני, בשלב זה יש לנהוג בזהירות יתרה היות וברוב המקרים לא ניתן לחזור שנית על פעולה שנעשית כאן. שיטת העבודה היא להגיע מוכן ככל הניתן עד לרגע התקיפה ורק אז לבצע את מהלך התקיפה. בתהליך זה יש תיעוד של כל פרט ופרט, בדרך כלל מומלץ לבצע תהליך זה בצורה ידנית ומבוקרת ולא בצורה אוטומטית לצורך מזעור נזקים שעשויים לקרות. מומלץ לבצע תהליך זה ספציפית על מטרה אחת ברגע נתון (כמובן שהכול תלוי בסדר גודל הבדיקה), בעת תקיפה מוצלחת ו- “השתלטות” על מערכת, בחלק מהמקרים מצליחים אף לחדור לרשת נוספת במידה והיא מקושרת לאותו מחשב ובכך היקף הבדיקה יכול להשתנות.

ניצול מתקדם של חולשות אבטחה (Post Exploitation)

שלב זה מגיע לאחר השלב של ניצול החולשות ותקיפת המערכות, הבודק כבר הצליח “לפרוץ” לאחד המחשבים או יותר ו- “ניצל” מספר מערכות מידע והתקני רשת אך עדיין לא סיים את הבדיקה. יש מקרים שבהם מספר מערכות נפרצו אך אין להן שום משמעות מבחינת המידע שהחברה מחזיקה בו, ולכן נכנס לתמונה השלב שאחרי, בשלב זה כבר מכוונים את ההתקפה לכיוון שהכי יסכן את הארגון במידה וההתקפה תצליח, לדוגמה אם הבודק הצליח לחדור לשרת ה- FTP של החברה זה דבר אחד אך מה יקרה אם יצליח לפרוץ לשרת הכספים של החברה ויצליח לשנות נתונים של משכורות, להעביר כספים לחשבון, לשנות נתונים של חובות של לקוחות. דוגמה נוספת שבה הבודק הגיע למאגר הנתונים של כרטיסי האשראי של לקוחות החברה וכעת יכול להשתמש בהם, מדובר בסיכון חסר תקדים אשר כבר יפגע לא רק בארגון עצמו אלא מעבר!

דוחות ומידע (Reports)

הדיווח הוא ללא ספק אחד הדברים הכי חשובים במבדק החדירות, שם הבודק רושם כל צעד וצעד שעשה, כל המידע שאסף, איך הוא הגיע למידע, איזה פגיעויות נמצאו, איזה פגיעויות הוא ניצל, לאילו מערכות הוא חדר וכו’. כמובן שלכל “פירצה” וניצול שנמצא יוצג בדו”ח הפתרון לסגירת “החור” ומה הארגון צריך לבצע כדי להקטין את הסיכון ככל הניתן.

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

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

קרא עוד...

הנדסה חברתית

יוגב 22 ינואר 2019

רקע

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

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

הגדרת המושג “הנדסה חברתית”

הנדסה חברתית היא מושג שלקוח מתחום האבטחה ובעיקר מתחום אבטחת המידע, ויקיפדיה מגדירה זאת:

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

מה הכוונה?

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

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

כיום קיימות המון התקפות מסוג הנדסה חברתית, הרבה פעמים טוענים “שלי זה לא יקרה..” אך כמובן שקל לדבר כאשר מודעים מראש להתקפה. ברגע שלא מודעים להתקפה (ברוב המקרים) ולא מוכנים אליה מראש קל מאוד “ליפול בפח”.

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

אז מה כן אפשר לעשות כדי להימנע מהתקפות מסוג זה? הפתרון הכי אפקטיבי זה מודעות!

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

כמובן שהדגמות, מצגות והרצאות של איש מקצוע בעניין מאוד יתרמו להבנה של המשתמשים על אופן הפעולה שבה “האקר” יכול לנהוג ולגרום להם לחשוב פעמיים לפני ביצוע פעולה מסויימת.

הפתרון הנוסף הוא ביצוע מבדק חדירה המשלב מבדק “הנדסה חברתית” וכולל בדיקת המודעות של העובדים, כולל ניסיון לחדור ולתקוף את הארגון על ידי התקפות מסוג “הנדסה חברתית” ולאחר מכן להסיק מסקנות ולשתף את העובדים בתוצאות.

קרא עוד...

מתקפת Kerberoasting

Omri Zachay 17 ינואר 2019

בפוסט זה נתאר איך לאתר בסביבת ה- domain של Active Directory  חשבון מסוג service.
נבחן כיצד תוקף יכול לנצל את אותו חשבון ולהשתמש בנתוני ההזדהות שלו כדי לעבור אימות בסביבת הדומיין ובחלק מהמקרים אפילו להשיג הרשאת Domain admin.

סקירה כללית

Kerberoasting מנצל את האופן שבו חשבונות מסוג Service משתמשים באימות של ה- Kerberos עם Service Principal Names (SPNs). בהמשך הפוסט נראה כיצד ניתן לגלות ברשת חשבונות Service באמצעות סריקה של ערכי SPN של אובייקטי משתמש. 

ובסופו של דבר ננסה לפצח את הסיסמאות של אותם חשבונות עד לקבלת הסיסמא ב- Clear text.

כאשר אנחנו מבצעים Login עם משתמש בדומיין (גם משתמש רגיל), אנחנו יכולים לבקש Service Tickets עבור חשבונות מסוג Service וזאת על-ידי ציון ערך ה-SPN שלהם (אל תדאגו בהמשך הכל יהיה ברור יותר).

ה- AD מהצד שלו יחזיר לנו Ticket שמוצפן באמצעות ה- NTLM Hash של אותו חשבון Service שאליו הוא משוייך.

לאחר מכן נוכל לחלץ את אותו Ticket מהזיכרון , לשמור אותו כקובץ ואז לנסות לפצח אותו באמצעות Brute force. ניסיונות הפיצוח נעשים Offline ולכן לא צריך לדאוג מזיהוי של מערכות הגנה או מנעילת החשבון.

במידה והצלחנו בהתקפת ה Brute force – נקבל את הסיסמא של חשבון ה- Service ב- Clear text.

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

אז ככה, כיום כמעט בכל ארגון אתם תמצאו Service accounts שחברים בקבוצת Domain admins ☹

לרוב הסיסמא של החשבונות האלה מאוד חלשות ומסומן בהם שהסיסמא לא משתנה אף פעם. מה שאומר שיש מצב גדול שניתקל בחשבונות משנת 2000 שמאז לא החליפו להם את הסיסמא יהי יהי ! 

מדובר בהתקפה סופר פופולארית שכמט כל תוקף ינסה לבצע ברשת שלכם. 

הסיבות ברורות: אפשר לבצע את המתקפה עם Domain user רגיל ולהגיע די בקלות ל- Domain admin. בלי PE ובלי פעולות מסובכות. מה שנקרא Game Over !  

אפשר לחלק את ההתקפה ל5 צעדים פשוטים (החמישי כייפי במיוחד):

  1. השגת רשימה של ערכי SPN עבור חשבונות משתמשים באמצעות סריקת ה- Active Directory

  2. בקשת Service Ticket עבור שירות SPN של חשבון שירות

  3. חילוץ ה- Service Ticket מהזיכרון ושמירה שלו בקובץ באמצעות Mimikatz

  4. פיצוח ה – Ticket

  5. השגנו את הסיסמא ב- Clear text – נבדוק איזו הרשאה יש לחשבון ונפעל בהתאם ?

    חשוב לציין שהשימוש ב- Mimikatz בצעד מס' 2 דורש הרשאת Local admin על המכונה.
    אבל לשמחתנו ניתן ליישם את ההתקפה היום גם ללא שימוש ב- Mimikatz
    https://github.com/PowerShellMafia/PowerSploit/pull/180 



לפני שרצים להתקפה: קצת רקע

אחרי שמשתמש בדומיין עובר אימות מול ה-KDC שזה בעצם שרת ה- Domain Controller , הוא מקבל ticket-granting-ticket או בקיצור TGT שחתום עם החשבון הדומייני krbtgt שמוכיח שאכן המשתמש הוא מי שהוא טוען שהוא.
לאחר מכן ה-TGT משמש את חשבון המשתמש לבקש service tickets (TGS) עבור משאבים או שירותים  ספציפיים בדומיין.  חלק מאותו service ticket מוצפן עם ה- NTLM hash של חשבון שירות היעד שאליו המשתמש מנסה לקבל גישה.  

אז איך ה-KDC קובע עם איזה מפתח להשתמש כשהוא מצפין את ה- service ticket?
הקרברוס משתמש ב- service principal names (SPNs) כדי לקבוע באיזה hash של service account להשתמש כדי להצפין את ה- service ticket.

ישנם שני סוגים של SPNs ב- Active Directory:
1. host-based SPNs - מקושרים לחשבון המחשב בדומיין.
2. arbitrary SPNs – בדרך כלל מקושרים לחשבון משתמש (user account)  בדומיין.

כשאנחנו משתמשים במתקפת Kerberoasting, בדרך-כלל לא אכפת לנו מ- host-based SPNs. 

חשבון מחשב בדומיין מחליף את הסיסמא כל 30 יום בצורה דיפולטיבית לסיסמא אקראית. 

בכל אופן, אותנו מעניין ה- arbitrary SPNs של חשבונות המשתמשים.

דוגמא נפוצה היא service account שמנהל מס' מופעי MSSQL, חשבון כזה יציג עבור כל מופע  את ה-SPN שלו:

<MSSQLSvc/HOST:PORT>

וזה נראה ככה:


 

ואם יש לו SPN שרשום עבור חשבון משתמש בדומיין אז זה אומר שנעשה שימוש ב-NTLM hash של סיסמאת החשבון עבור יצירת ה- service ticket.  זה בעצם המפתח שלנו בהתקפת Kerberoasting. 
ואם אותו חשבון גם משוייך לקבוצת Domain Admins אז בכלל אנחנו בעננים ?

מכל הרקע הזה אנחנו יכולים להבין שבצורה שקרברוס עובד, כל משתמש יכול לבקש TGS עבור כל שירות בעל SPN רשום בחשבונות של משתמש או מחשב בסביבת הדומיין.
ומכיוון שחלק מה-TGS מוצפן עם ה- NTLM hash של סיסמאת ה- service account, כל משתמש יכול לבקש TGS ticket ואז לנסות לפצח את סיסמאת החשבון Offline ללא כל סכנה.

ישנם כל מיני Service accounts שיכולים לעניין אותנו:

הנה רשימה שלהם כולל הסבר לגבי כל אחד: https://adsecurity.org/?page_id=183

והנה דוגמא למימוש של מוצר שמבקש רישום של SPN מסוג CIFS:

https://community.alfresco.com/docs/DOC-4953-configuring-the-cifs-and-web-servers-for-kerberosad-integration

 


לאלה ממכם שמתעניינים איך מתבצע רישום SPN בדומיין, האפשרויות:

1. רישום אוטומטי של ה-SPN – מתבצע בחלק מה-Services. 

לדוגמא, הרמתם Instance של SQL. ברקע מתבצע רישום אוטומטי של ה-SPN של אותו Instance. 

2.רישום SPN בצורה ידנית:

 

לדוגמא רישום של 2 SPN שונים:

setspn -a cifs/<cifs-server-name>.<domain> user_name

 setspn -s MSSQLSvc/myhost.redmond.microsoft.com:instancename DOMAIN\SQLServiceAccount


למתקפה עצמה

תחילה ננקה את כל הTickets שיש לנו על מערכת ההפעלה


נריץ סריקת SPN לאיתור accounts Service בארגון  (יש להיות מחוברים עם משתמש בדומיין)


התשובה שהתקבלה
ker5

הרשימה נתנה לנו את ה-SPNs ובחלקם את החשבון המשוייך, עם הפקודה הבאה אני גם אוכל לראות מי חבר בקבוצת ה-Domain admins וככה אדע איזה SPN מעניין אותי.

שימו לב שמשתמש בשם sysadmin חבר בקבוצה Domain Admins


ה- Service שמולו אנסה את התקיפה הוא שירות ה-HTTP שרץ עם המשתמש sysadmin שלו כאמור הרשאות Domain admin


 

כעת אנחנו צריכים להריץ פקודות PowerShell כדי לבקש את ה-  Service ticket (TGS) 

ה-Service ticket יוצג בפלט וישמר בזיכרון של המערכת.

שימו לב שאני משתמש עבור ArgumentList בערך שאותו לקחתי מסריקת ה-SPN והוא: "HTTP/teamcitycpa.local"
ker8

נשתמש ב-Mimikatz כדי לייצא את ה- Kerberos tickets מהזיכרון לדיסק המקומי


נעתיק מהתיקייה של Mimikatz את ה-Ticket הרלוונטי ונעביר אותו למכונת ה-Kali שלנו
ker10

שימוש בכלי Kerberoast

הורידו את ה-Git הבא למכונת ה-Kali linux שלכם:  

 https://github.com/nidem/kerberoast.git

 

ייצוא ה- Kerberos ticket שמעניין אותנו למכונת ה- Kali linux ושימוש ב-Cracker כדי לנסות לפצח את הסיסמא
ker11

Game Over -  יש לנו סיסמא של משתמש בעל הרשאת Domain admin בארגון.

קרא עוד...