תוכן העניינים
הסיפור של מבדק חדירה אחד: מ־View Source בדפדפן, דרך נתיבים נסתרים שלא השתמשו בהם, עד Microsoft Graph Token של מנהל ראשי שמחכה למי שירים אותו
לפני כמה שבועות התחלנו מבדק חדירה אפליקטיבי על פלטפורמת SaaS חדשה. בלי משתמש, בלי סיסמה, בלי תיעוד פנימי – רק כתובת אינטרנט ודף Login. בסוף המבדק, הצלחנו להראות שמי שיהיה סבלני מספיק ויחכה שמנהל בכיר יתחבר לאפליקציה, יקבל בידיו את Microsoft Graph Token שלו – ועם זה, את כל הארגון. זה הסיפור שלב אחרי שלב, כפי שהוא קרה.
נקודת המוצא: קובצי JavaScript שכל אחד יכול לקרוא
איך View Source הופך לכלי ה־Reconnaissance הראשון של כל תוקף
לפני שמקלידים שם משתמש כלשהו, יש לכל אפליקציית Web מודרנית קובצי JavaScript שהדפדפן מוריד באופן ציבורי. ב־view-source של דף הבית, או בכלי הפיתוח של הדפדפן, רואים כתובות של עשרות קובצי JS של React/Angular, ספריות, סקריפטים של אנליטיקס, ולעיתים גם מודולים פנימיים. כל גורם ברשת יכול להוריד אותם, גם בלי להיכנס למערכת.
קבצים אלה הם מפת הדרכים של האפליקציה. הם מכילים את כל הקריאות שה-Frontend מבצע לשרת: נתיבים, שמות פרמטרים, מבני בקשה, ולעיתים אפילו שמות של תכונות שעדיין לא הופעלו במוצר. ארגונים רבים שוכחים את זה, כי הם רואים את ה־Frontend כ"חלק שלהם" – אך מבחינת התוקף, זה פשוט תיעוד API חינמי.
הגילוי: נתיבים שאינם מופיעים בזרימת ההתחברות הרגילה
איך ניתוח מעמיק של ה־JavaScript חשף נתיבים שה־UI מעולם לא נגע בהם
הורדנו את כל קבצי ה־JavaScript מהאפליקציה, כמה מגה־בייט של קוד לא קריא במיוחד, וחילצנו מתוכם כל מחרוזת שנראית כמו נתיב API. התקבלה רשימה של עשרות נתיבים. חלקם זוהו בקלות מתהליך ההתחברות הרגיל: Login, רענון Session, טעינת פרופיל. אבל היו רבים אחרים – חיפוש משתמשים, הגדרות מערכת, סנכרון מול ענן, ייצוא נתונים – שמשתמש רגיל לא היה רואה אותם אף פעם בזרימה הסטנדרטית של האפליקציה. הם פשוט "ישנים" שם, מחכים שמישהו ירכיב את הבקשה הנכונה.
בעזרת מבנה הבקשות שראינו בקובצי ה־JavaScript, בנינו פנייה ידנית אל כל אחד מהנתיבים הללו – בלי כל פרטי הזדהות, ללא Cookie, ללא Bearer. רוב הנתיבים החזירו, כצפוי, שגיאת אימות. אבל מעט מאוד מהם החזירו דבר אחר לגמרי: נתונים. ובמקרה אחד מסוים – הרבה יותר נתונים ממה שציפינו.
הממצא: נתיב שמחזיר את מסד המשתמשים – וכל ה־Tokens שבתוכו
איך פנייה ללא אימות הולידה דליפת מידע שגרמה לנו לעצור ולקרוא שוב
הנתיב שהפתיע אותנו היה נתיב חיפוש משתמשים, שמופעל בדרך כלל רק אחרי התחברות. במקרה הזה, השרת לא בדק זאת. שלחנו בקשה בלי שום אימות, עם אות בודדת כשאילתה – וקיבלנו בחזרה את מסד הנתונים המלא של משתמשי הפלטפורמה: אלפי רשומות, כל אחת עם שם, כתובת דואר אלקטרוני, הרשאה ארגונית, ותפקיד.
עד כאן, זו דליפת PII חמורה אבל לא נדירה. מה שהפך אותה לקריטית היה השדה הנוסף בכל רשומה: azure_user_token. זה היה Microsoft Graph Token פעיל, שהאפליקציה החזיקה אצלה כדי לפנות בשם המשתמש ל־Microsoft 365. השרת לא רק שמר אותו – הוא גם הוציא אותו החוצה, בתגובה ל־API ציבורי לחלוטין, יחד עם ה־Tokens של אינטגרציות SharePoint וה־JWT הפנימי של היישום.
ההסלמה: מ-Token יחיד לסיור חופשי ב־Microsoft 365
איך הראינו ללקוח, בזמן אמת, מה Token אחד יכול לעשות בענן הארגוני
לקחנו Token אחד פעיל מתוך התגובה ושלחנו אותו ישירות אל graph.microsoft.com מבלי לעבור דרך האפליקציה כלל. תוך דקות בודדות יכולנו לראות את שם הארגון ואת זהות ה־Tenant, למנות עשרות דומיינים מאומתים, ולקבל רשימה מלאה של למעלה מאלף קבוצות Microsoft Entra – לרבות קבוצות תשתית רגישות וקבוצות מנהלי IT. המשכנו לאתרי SharePoint של הארגון, עברנו לפורטל העובדים ולקטלוג היישומים הפנימי, ומשם הורדנו תוכן של מצגות הנהלה, מסמכי משאבי אנוש וסרטוני קליטה.
הדבר המטריד באמת לא היה כמות המידע אלא העובדה שאף אחת מהפעולות לא הופיעה כפעולה חשודה בלוגים של Microsoft 365. הכול נראה כאילו המשתמש המקורי, זה שדלף לו ה־Token, הוא שביצע את הפעולות. אין שגיאת התחברות, אין דרישת MFA, אין הפעלה של Conditional Access. מבחינת מערכות ההגנה של הענן, התוקף והמשתמש החוקי הם אותה זהות בדיוק.
נקודת השיא: לחכות שמנהל ראשי יתחבר
איך אספקה רציפה של Tokens הופכת דליפה חד־פעמית להשתלטות שקטה על הארגון
ואז הבחנו במאפיין הקטלני: כל פעם שמשתמש מתחבר מחדש, האפליקציה מנפיקה לו Microsoft Graph Token חדש – ושומרת אותו באותו מאגר. מי שיכול לקרוא את הנתיב הציבורי, יכול לדגום אותו כל כמה דקות ולאסוף Tokens שזה עתה הונפקו. אורך החיים של כל Token הוא כשעה, וזה הזמן שבו ניתן להפעיל אותו.
מכאן, התסריט המעשי בנוי מסבלנות בלבד. תוקף לא מאומת מריץ סקריפט פשוט שמושך את הרשימה כל חמש דקות, ובוחן את הרשומות החדשות. בעלי תפקידים בכירים – מנהלי IT, סמנכ"לים, חשבונות שירות עם הרשאות גבוהות – מתחברים מדי פעם. ברגע ש־Global Administrator של ה־Tenant מתחבר לאפליקציה, ה־Token שלו זמין לתוקף בתוך דקות. עם Microsoft Graph Token של Global Admin בידיים, המשמעות אינה גישה לעוד כמה קבצים – היא שליטה מלאה על ה־Tenant: יצירת משתמשים, איפוס סיסמאות, שינוי מדיניות Conditional Access, רישום אפליקציות חדשות עם הרשאות לפי בחירה, וקריאה לתיבות הדואר של ההנהלה. כל זאת מתחילה בקובץ JavaScript ציבורי שכל אחד ברשת יכול להוריד.
תובנות ממומחי הסייבר של IPV Security
איך להגן על הארגון מפני שרשרת ניצול זו, על שלביה
- להניח שכל קוד שמגיע לדפדפן הוא קוד ציבורי. לתכנן את ה־Backend תחת ההנחה שהתוקף קרא את כל ה־Frontend – ולכן לא לסמוך על "מסך שלא מוצג ב־UI" כשכבת הגנה.
- לבדוק כל נתיב שמופיע בקוד מול תרחיש של פנייה ללא אימות, ללא Cookie וללא Bearer. רוב הדליפות הקשות שראינו השנה התחילו מנתיב שאיש לא חשב שמישהו ינסה להפעיל בלי להיות מחובר.
- לעולם לא להחזיר Microsoft Graph Tokens, SharePoint Integration Tokens או Refresh Tokens אל הדפדפן או אל ה־API החיצוני. Tokens אלו חייבים להישאר בצד השרת בלבד.
- לצמצם את ההרשאות שהאפליקציה הארגונית מבקשת ב־Entra: במקום Read.All ו-Sites.Read.All רחבים, להשתמש ב־Sites.Selected ובהרשאות ממוקדות לתכונות הקיימות בפועל.
- לעקוב אחר Sign-In Logs של Microsoft 365 ולהתריע על קריאות Graph בדפוסים חריגים – שאילתות רחבות, גישה ממקור גיאוגרפי לא רגיל, או הורדה של מסה גדולה של קבצים בזמן קצר.
סיכום: הסיפור הזה לא מתחיל ב־Microsoft – הוא מתחיל באפליקציה שלכם
מדוע ביקורת אבטחה של אפליקציות SaaS המשולבות ב־M365 חשובה לא פחות מהגנת הענן עצמו
הקפיצה מ־View Source של דף ציבורי לשליטה ב־Tenant של מנהל ראשי נשמעת דרמטית, אבל היא נבנתה משלבים קטנים מאוד – כל אחד מהם נראה בנפרד כאילו "אין בו ממש סכנה". זו בדיוק הסיבה שאפליקציות הפועלות לצד Microsoft 365 צריכות להיבדק לעומק: לא רק האם הן מאובטחות בפני עצמן, אלא איך הן שומרות, מעבירות ומחזירות את ה־Tokens של הענן שמתחתיהן.
האם אתם יודעים האם הנתיבים של האפליקציות שלכם נבדקו מול תרחיש של פנייה ללא אימות? האם מישהו עבר על קבצי ה־JavaScript הציבוריים וזיהה מה מסתתר בהם? והאם נבחנה אינטראקציה של האפליקציות עם הענן הארגוני – אילו Tokens הן מחזיקות ולאן הן מחזירות אותם?
מבדק חדירה אפליקטיבי של IPV Security בוחן בדיוק את שרשרת הניצול הזו – מ־View Source של הדפדפן, דרך כל נתיב שמופיע בקוד, ועד התנהגות האפליקציה מול שירותי ענן מקושרים, ומספק מפת דרכים מעשית לסגור את הפרצות לפני שתוקף ימצא אותן ראשון.
לחצו כאן
שאלות נפוצות
כיצד הצליחו החוקרים לאתר את הפרצה הראשונית?
הפרצה אותרה באמצעות ניתוח קובצי JavaScript ציבוריים שהורדו מהאפליקציה. מתוך הקוד חולצו נתיבי API שלא היו נגישים דרך ממשק המשתמש, ולאחר בדיקה התגלה כי אחד מהם היה נגיש ללא כל מנגנון אימות.
מדוע דליפת Microsoft Graph Token נחשבת למסוכנת במיוחד?
Access Token תקף מאפשר לבצע פעולות בשם המשתמש מול Microsoft Graph, בהתאם להרשאות שהוענקו לו. כאשר מדובר במשתמש בעל הרשאות גבוהות, היקף הגישה למשאבי הארגון עלול להיות משמעותי.
האם MFA ו-Conditional Access היו אמורים למנוע את התקיפה?
לא בהכרח. לאחר שהונפק Access Token תקף, השימוש בו מתבצע כזהות המשתמש עצמו, ולכן מנגנוני MFA או Conditional Access שכבר הופעלו בעת ההתחברות אינם בהכרח מופעלים מחדש במהלך תקופת תוקפו של ה־Token.
כיצד ניתן למנוע שרשרת תקיפה מסוג זה?
באמצעות אכיפת אימות והרשאות על כל נתיב API, מניעת חשיפת Tokens מחוץ לשרת, צמצום הרשאות Microsoft Graph, ביצוע מבדקי חדירה תקופתיים וניטור חריגות בגישה למשאבי Microsoft 365.
מהו הלקח המרכזי מהאירוע?
גם חולשות שנראות שוליות בפני עצמן, כמו נתיב API ללא אימות או מידע שנחשף בקובצי JavaScript, עלולות להתחבר לשרשרת תקיפה מלאה. לכן יש לבחון את האפליקציה כמערכת שלמה, כולל כל האינטגרציות שלה עם שירותי הענן הארגוניים.