אנומרציה וריקון בסביבת Microsoft 365

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

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

פלטפורמות ענניות נמצאות איתנו כבר שנים רבות, וליתר דיוק כבר למעלה מעשור עם Azure ,AWS או Oracle ונוספים. אחת הפלטפרומות המרכזיות היא Microsoft 365, שהיא חלק מתוך פלטפורמה הרבה יותר רחבה של Microsoft Cloud. תשתיות דואר, מסרים וסרוויסים אחרים נמצאים בענן של Microsoft 365 שנים רבות וחלקנו עובדים או תוקפים אותם ביומיום. 

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

Enumeration is the key, fuzz for the hole or the misconfig

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

מאיפה מתחילים

ספקי הענן מנגישים את הסרוויסים בענן בצורה גלויה כי כך הפלטפורמות בנויות, ולכן זה מאפשר לנו להבין במינימום זמן איך נראית התשתית כלפי חוץ ולעיתים גם כלפי פנים. ספקי הענן אינם רואים בסריקות ואנומרציות חיצוניות בעיות אבטחה אלא תכונה, וכמו שנאמר, it's not bug it's a feature. לכן, פלטפורמות ענניות הן יעד נהדר ושטח פורה לתקיפה.

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

אחד מתוך אותן נקודות קצה נמצא בכתובת האתר הבאה:

https://login.microsoftonline.com/getuserrealm.srf?login=username@domain.com&xml=1

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

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

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

הבקשה באמצעות GetUserRealm משמש בדרך כלל בתרחישי זהות, שבהם ארגון משתמש בספק הזהות שלו כדי לאמת משתמשים עבור שירותי Microsoft Online. בתרחישים אלה, כמו כן, GetUserRealm מסייע בהפניית בקשת המשתמש לספק זהויות הנכון בהתבסס על דומיין הדוא"ל. במקרה הזה Azure AD כי לא מצוין אחרת או לגורם חיצוני.

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

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

דוגמה נוספת היא זיהוי סרוויס 

$DOMAIN = "ellishlomo.com"

host autodiscover.$DOMAIN

דוגמה אחרת יכולה לקחת אותנו למקומות נחמדים כמו הפוורשל המצורף

Invoke-RestMethod -Uri "https://login.microsoftonline.com/common/GetCredentialType" -Method POST -Body '{"Username":"ellis@ellishlomo.com"}' -ContentType "application/json"

• שליחת בקשה באמצעות HTTP POST לנקודת הקצה של Azure AD לאימות בכתובת https://login.microsoftonline.com/common/GetCredentialType על מנת לאחזר את סוג האישור עבור חשבון משתמש שצוין.
• החלק של cmdlet Invoke-RestMethod משמש לשליחת בקשת POST, והפרמטרים Uri, Method, Body ו ContentType משמשים לציון כתובת אתר היעד, שיטת HTTP, נתוני גוף הבקשה וסוג התוכן של גוף הבקשה, וזאת בהתאמה.
• נתוני גוף הבקשה הם אובייקט JSON עם ערך המייצג את שם המשתמש (ellis@ellishlomo.com). נקודת הקצה GetCredentialType תחזיר תגובה המציינת את סוג האישור הנדרש לאימות המשתמש שצוין, כגון סיסמה או אסימון אימות מרובה גורמים.

‎בקשות ותגובות

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

קוד HTTP	תיאור
200	כניסה מוצלחת (משתמש/סיסמה תקינה)
401	שם משתמש חוקי, סיסמה לא תקינה
403	שם משתמש חוקי, סיסמה תקינה, נדרש אימות דו-שלבי
404	שם משתמש לא חוקי

בריפו של rapid7/metasploit-framework ישנו תיאור פשוט וברור לגבי קוד תגובה מתוך HTTP. 

ישנם דרכים מגוונות לבדוק קוד תגובה מול סרוויסים שונים ולא דווקא מול ActiveSync. למשל, בכלי 0xZDH/o365spray אפשר לבצע אנומרציה בלבד מול נקודות קצה אחרות. בקיצור, קצת שינוי בקוד ואפשר להתאים לדרישות הסריקה מול נקודות קצה מגוונות ושונות. 

טיפ: בעת ניתוח התוצאות של כלי זה עבור כניסות מוצלחות או אמינות אובייקט, אפשר להשתמש בפרמטר grep -v כדי להסיר תגובות של 404 ו-401. זה משאיר רשימה קצרה. אגב, אפשר לעשות זאת מול תגובות נוספות. 

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

דוגמה לבדיקה ידנית על אובייקטים. 

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

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

Taking What M365 Gives You

רשימות תקיפה

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

רשימות עם אינספור משתמשים כמו זאת של wordlist/usernames.txt at master · jeanphorn/wordlist · GitHub אינה בהכרח הדרך הנכונה להריץ סריקות ובפרט תקיפות כמו Brute-Force או ספריי. לצד זה, אפשר להשתמש במאגרים שזלגו מתקיפות קודמות. 

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

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

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

Get-Content list.txt | ForEach-Object {$_ + "@ellishlomo.com"} | Set-Content new-list.txt

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

גם כאן קצת פוורשל יעשה את העבודה

$firstnames = Get-Content firstnames.txt
$lastnames = Get-Content lastnames.txt

foreach ($firstname in $firstnames) {
foreach ($lastname in $lastnames) {
$email = "$firstname.$lastname@ellishlomo.com"
Write-Output $email
}
}

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

משהו נוסף שיכול לסייע הוא להשוות רשימה של משתמשים שכבר נבדקו, מול רשימה של משתמשים שעדיין לא נבדקו. שוב, פוורשל נחלץ לסייע בבניית של הרשימה. במקרה הזה, לוקחים רק ערכים ייחודיים מקובץ 'old_users.txt' שאינם קיימים בקובץ users_enumarated.txt, ואנו מפיקים את הרשימה המתקבלת לקובץ 'new_users.txt'.

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

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