ההגנה הכי טובה? ארבע טכניקות לעקיפת MFA
עבור ארגונים רבים, 2020 הייתה השנה שבה אימות רב-גורמים (MFA) הפך לאמצעי הכרחי של בקרת גישה המסייע בהגנת הארגון מפני גניבת הרשאות. שי נהרי מחברת אבטחת המידע סייברארק מסביר כיצד ניתן לחזק את ההטמעה
ישראל דיפנס
| 23/06/2021
BIGSTOCK/ Copyright: Jakub Jirsak
הטרנספורמציה הדיגיטלית והתרחבות העבודה מהבית בעקבות מגפת הקורונה, כמו גם ההסתמכות הגדלה על שירותי ותשתיות ענן הוסיפו ליצירת אתגרים חדשים בגישה לנתונים. עבור ארגונים רבים, 2020 הייתה השנה שבה אימות רב-גורמים (MFA) הפך לאמצעי הכרחי של בקרת גישה המסייע בהגנת הארגון מפני גניבת הרשאות, תוך שהוא מבצע סגמנטציה של נכסים קריטיים על מנת להקשות על התוקפים להגיע ליעדם.
הטיעונים בעד אימות רב-גורמים רבים ומשכנעים. בשנה שעברה חשפו מהנדסי מיקרוסופט ש-99.9% מהחשבונות שנפרצו ושאחריהם עקבו, לא עשו שימוש ב-MFA. במקביל, גוגל מצאה שאפילו אימות דו-שלבי פשוט, כגון הודעת טקסט הנשלחת ברשת סלולרית (SS7), מסוגל לבלום 100% מההתקפות האוטומטיות, 96% ממתקפות פישינגו-75% מהמתקפות הממוקדות.
MFA חייב לשמש כאמצעי אבטחה יסודי המהווה חלק מאסטרטגיה מרובת רבדים והוליסטית של אפס אמון. בתכנון או הטמעה שגויים, גם תשתית MFA עלולה להיפרץ ולמלא תפקיד בשרשרת המתקפה. ככל שהתוקפים ממשיכים ומשיקים חידושים, הם מוצאים דרכים חדשות ויצירתיות להתמודד עם MFA ולעקוף את אמצעי הבקרה הקריטי הזה.
קחו למשל את טכניקת Golden SAML MFA לעקיפת MFA שבה השתמשו תוקפי SolarWinds כדי להשיג גישה בכל עת ומכל מקום לרשתות שנפלו קורבן למתקפה. באותה מתקפה נרחבת, כלי ה-MFA ספג פגיעה משמעותית בהרשאות אחרי שהתוקפים גנבו מפתח סודי שאוחסן בכלי עצמו. ככל שטכניקות כגוןGolden SAML ואחרות נעשות מקובלות בשימוש, ניתן לצפות ששחקנים זדוניים אחרים יחפשו דרכים נוספות לגניבת הרשאות בלתי מוגנות המאוחסנות בכלי ה-MFA על מנת להשיג גישה בלתי מורשית.
מאז תחילת 2021, היינו עדים לגידול חד בבקשות מלקוחות ארגוניים בכל העולם להדמיית מעקפים של MFA על-ידי תוקפים. בהתקשרויות אלו, אנו עובדים על תיקון הנזקים ומחקר משותף של ההתקפה יחד עם מעבדות סייברארק וזיהינו ארבעה ווקטורי התקפה עיקריים שבהם משתמשים התוקפים כדי לעקוף מנגנוני MFA: פגמים בארכיטקטורה ובתכנון של ערוצים לא מאובטחים, מתקפות מערוצים צדדיים וכיסוי בלתי מספק של משטח ההתקפה.
נבחן כמה מתקפות מהעולם האמיתי נגד בקרות MFA:
מתקפת MFA מס' 1: ניצול פגמים בארכיטקטורה ובתכנון
הרבה ארגונים פורסים מנגנוני כניסה יחידה single sign-on (SSO) כאשר ה-MFA נועד לצמצם את הסיכון לגניבת הרשאות.
בעבודה שביצענו לאחרונה, ארגון גלובלי גדול שכר ספק MFA מצד שלישי שיאבטח את הגישה ל-VPN. לאחר החיבור ל-VPN, משתמשים מרוחקים השתמשו ב-SSO כדי להגיע לשירותי ענן שונים. ואולם, במהלך הבדיקות שלנו מצאנו שכאשר משתמשים נכנסו מכתובת IP בדוקה בטווח ה-VPN, הם התבקשו לתת רק את הרשאת הדומיין שלהם ומיד לאחר מכן קיבלו גישה לכל שירות ענן.
עובדה זאת חשפה פגם יסודי בארכיטקטורה. ה-MFA הוחל רק על גישה מהתשתית, לא על זהויות משתמשים ספציפיים הניגשים לנכסים קריטיים. הפגם נטרל למעשה את האפקטיביות של ה-MFA, כשהוא מותיר את הארגון פגיע למתקפות מכניסה חד-גורמית. מספיק היה לפרוץ לתחנת עבודה של משתמש אחד ולהשיג גישה ליישום אסימון תוכנה המותקן באותו מכשיר, לכבות בקלות משתמשים אחרים תוך שימוש בסיסמה של משתמש אחד ולהגיע לכל המידע הארגוני, החל מהמייל של המנכ"ל וכלה בקונסולות ענן עוצמתיות.
מתקפת MFA מס' 2: ניצול תהליכי Onboarding לא מאובטחים הנעשים באמצעות אסימונים (tokens)
המטרה בהתקשרות המסוימת הזאת של ה-Red Team הייתה להיכנס לרשתות תעשייתיות רגישות של הארגון, המוגנות באסימוני MFA. עם הכניסה הראשונית לרשת המחשוב התחלנו לבחון את המיילים של המשתמשים. עד מהרה הבחנו במשהו מוזר בתהליך האונבורדינג הראשוני. משתמשים חדשים קיבלו אי-מייל המכיל לינק שעליו נדרשו להקליק כדי להצמיד את אסימון תוכנת ה-MFA של הטלפון לזהות המשתמש בשרת ה-MFA של החברה.
למרבה הצער, אותו לינק הכיל גם את הזרע הקריפטוגרפי לאסימון ה-MFA של המשתמש, או במלים אחרות, את חומר הגלם המוצפן המשמש ליצירת האסימון. החדשות הטובות היו שאותו חומר גלם היה מוגן בקוד PIN.
כעת, כשכל המיילים בידינו, הייתה לנו גישה לצופן והיינו זקוקים רק לקוד PIN ולחותמת זמן כדי לשכפל אסימוני MFA ולחולל קודי OTP משלנו בשם המשתמש. עד מהרה הבנו שכל "זרע" היה מוגן בקוד של ארבע ספרות, שאותו פיצחנו בשניות. כך יכולנו לפרוץ את הצופן לכל אסימון MFA ולשכפל אסימונים של כל משתמש, מה שסיפק לנו גישה מלאה לרשת התעשייתית.
מתקפת MFA מס' 3: תקיפת עוגיות הדפדפן אחרי אימות זהות
מתקפות המתבצעות אחרי שלב אימות הזהות עם MFA מתמקדות בקובצי "העוגיות" והופכות לחלק מהשיטות המועדפות על הצוות שלנו להדמיית מתקפות, ולו רק משום שניתן לבצע אותן מרחוק אחרי עמידה בתנאים מסוימים.
המטרה העיקרית שלנו בהתקשרות זאת עם הלקוח הייתה לפגוע או לגנוב עוגיות בצד הקליינט של ה-session, כלומר בשלב שאחרי אימות הזהות בדפדפן של משתמש הקצה. לדוגמה, כאשר אתם נכנסים לג'ימייל עם ההרשאות שלכם כדי לבדוק דואר, אתם מפעילים "session "עוגיות", המאוחסנות במצב מוצפן בדפדפן שלכם. קובצי עוגיות אלה נשלחים עם כל בקשה לדומיין משנה של ג'ימייל כדי שלא תצטרכו להקיש את הרשאות הגישה שלכם מחדש אחרי כל סגירה של הדפדפן.
במערכות ווינדוס, עוגיות אלו מוצפנות על-ידי ממשק קריפטוגרפי הקרוי DPAPI. ממשק זה מאפשר בעיקרון למשתמש לבצע קריאה יחידה ל-API להצפין או להסיר הצפנה מיחידת נתונים מבלי לבקש הרשאות אדמין מקומיות. בכל סביבה שמצטרפת לדומיין ישנו מפתח גיבוי כוללני המסוגל לפתוח את הצפנת ה-DPAPI של הדומיין כולו. בנוסף, ברגע שמפתח הגיבוי נוצר, לא מחליפים אותו לעולם.
מאחר ו-DPAPI מיועד לשימוש בהקשר של המשתמש, קל להסיר את ההצפנה מהעוגיות בדפדפן המשתמש ולהשתמש בהרשאות שלו עצמו עם קריאה יחידה ל-API של ווינדוס. ברגע שהושגה גישה למפתחות הדומיין, אפשר להרחיב את המתקפה מרחוק לכל המשתמשים והמכשירים באותו דומיין.
מתקפת MFA מס' 4: תקיפת נכסים קריטיים באמצעות ערוצים משניים
כאשר ניתן לגשת למשאבים מערוצים רבים, הרבה ארגונים נוטים להחמיץ את אבטחת הערוצים המשנים. אנו עדים לטעויות רבות כאלו בהתקשרויות שאנו מבצעים כ-Red Team.
במקרה המסוים הזה, ארגון הקים מנגנון MFA עבור האדמין כדי שיוכל להגיע לשרתים קריטיים מסוימים באמצעות פרוטוקול שולחני מרוחק (RDP). כאשר משתמש פריבילגי נכנס לשרת באמצעות RDP, מערכת ההפעלה של ווינדוס קוראת לספק ה-MFA המותקן כמודול נפרד. המשתמש מקבל הודעת "PUSH" הטלפון שלו ונדרש לאמת את ניסיון הכניסה. עם אישור בקשת הכניסה, המשתמש מקבל גישה אינטראקטיבית לשרת באמצעות RDP.
כלומר, אם תוקף יצליח להשיג את שם המשתמש והסיסמה לשרת, ניתן יהיה עדיין לחסום את כניסתו דרך ה-RDP, וטוב שכך. אבל ה-RDP הוא מנגנון חד-סטרי שפועל רק בגישה לתוך הארגון. מה קורה בערוצים אחרים? בסביבות אקטיב דירקטורי (AD) ברירת המחדל מאפשרת יציאות ניהול מרוחקות.
לפרוטוקולים אחרים כגון Server Message Block (SMB ו-Remote Procedure Call (RPC) ניתן להיכנס עם כלים כגון as PsExec, Powershell ואובייקטי COM ישירים אחרים. פרוטוקולים אלה פטורים מגורם האימות השני מאחר ורוב מודולי ה-MFA אינם מכסים תקשורת שאינה אינטראקטיבית. התוקף יוכל להיכנס ולהשיג גישה לשרת תוך שימוש בשם משתמש וסיסמה בלבד.
אימוץ נקודת המבט של התוקפים כדי לחזק את הטמעות ה-MFA בארגון
הצוות האדום של סייברארק משתמש בתגליות אלו כדי לסייע ללקוחות להבין את האיומים המתפתחים מנקודת המבט של התוקפים ולהגן על הארגון באופן יזום , לא רק לאחר מעשה, להגן על מה שחשוב ולהקדים את התוקפים. בשיתוף פעולה עם צוות המומחים והחוקרים שלנו, ארגונים יכולים להגדיר נקודת מוצא שממנה ימשיכו וימדדו כל שיפור עתידי באבטחת הארגון.
ללא ספק, MFA הוא מנגנון אבטחה קריטי בעולמנו הנייד. הוא גם מקשה מאוד על עבודתנו כחברי הצוות האדום של סייברארק. עם זאת, גם אליו יש להתייחס כחלק מהקשר רחב יותר של רובדי אבטחה רבים, הכוללים גם בקרת גישה פריבילגית כגון בידוד ססיות וניהול הרשאות. כמו כל היבטי הבטחה, התכנון וההטמעה חשובים מאוד. חשוב מכל להקפיד על האבטחה התפעולית. כידוע, חוזק האבטחה שווה לחוזק החולייה החלשה ביותר שלה.
מאת שי נהרי, מנהל שירותי Red Team בחברת סייברארק
מחקר זה הוצג כחלק ממסלול "ללמוד מהמעבדות ומה-Red Team" באירועIMPACT LIVE 2021 .
עבור ארגונים רבים, 2020 הייתה השנה שבה אימות רב-גורמים (MFA) הפך לאמצעי הכרחי של בקרת גישה המסייע בהגנת הארגון מפני גניבת הרשאות. שי נהרי מחברת אבטחת המידע סייברארק מסביר כיצד ניתן לחזק את ההטמעה
BIGSTOCK/ Copyright: Jakub Jirsak
הטרנספורמציה הדיגיטלית והתרחבות העבודה מהבית בעקבות מגפת הקורונה, כמו גם ההסתמכות הגדלה על שירותי ותשתיות ענן הוסיפו ליצירת אתגרים חדשים בגישה לנתונים. עבור ארגונים רבים, 2020 הייתה השנה שבה אימות רב-גורמים (MFA) הפך לאמצעי הכרחי של בקרת גישה המסייע בהגנת הארגון מפני גניבת הרשאות, תוך שהוא מבצע סגמנטציה של נכסים קריטיים על מנת להקשות על התוקפים להגיע ליעדם.
הטיעונים בעד אימות רב-גורמים רבים ומשכנעים. בשנה שעברה חשפו מהנדסי מיקרוסופט ש-99.9% מהחשבונות שנפרצו ושאחריהם עקבו, לא עשו שימוש ב-MFA. במקביל, גוגל מצאה שאפילו אימות דו-שלבי פשוט, כגון הודעת טקסט הנשלחת ברשת סלולרית (SS7), מסוגל לבלום 100% מההתקפות האוטומטיות, 96% ממתקפות פישינגו-75% מהמתקפות הממוקדות.
MFA חייב לשמש כאמצעי אבטחה יסודי המהווה חלק מאסטרטגיה מרובת רבדים והוליסטית של אפס אמון. בתכנון או הטמעה שגויים, גם תשתית MFA עלולה להיפרץ ולמלא תפקיד בשרשרת המתקפה. ככל שהתוקפים ממשיכים ומשיקים חידושים, הם מוצאים דרכים חדשות ויצירתיות להתמודד עם MFA ולעקוף את אמצעי הבקרה הקריטי הזה.
קחו למשל את טכניקת Golden SAML MFA לעקיפת MFA שבה השתמשו תוקפי SolarWinds כדי להשיג גישה בכל עת ומכל מקום לרשתות שנפלו קורבן למתקפה. באותה מתקפה נרחבת, כלי ה-MFA ספג פגיעה משמעותית בהרשאות אחרי שהתוקפים גנבו מפתח סודי שאוחסן בכלי עצמו. ככל שטכניקות כגוןGolden SAML ואחרות נעשות מקובלות בשימוש, ניתן לצפות ששחקנים זדוניים אחרים יחפשו דרכים נוספות לגניבת הרשאות בלתי מוגנות המאוחסנות בכלי ה-MFA על מנת להשיג גישה בלתי מורשית.
מאז תחילת 2021, היינו עדים לגידול חד בבקשות מלקוחות ארגוניים בכל העולם להדמיית מעקפים של MFA על-ידי תוקפים. בהתקשרויות אלו, אנו עובדים על תיקון הנזקים ומחקר משותף של ההתקפה יחד עם מעבדות סייברארק וזיהינו ארבעה ווקטורי התקפה עיקריים שבהם משתמשים התוקפים כדי לעקוף מנגנוני MFA: פגמים בארכיטקטורה ובתכנון של ערוצים לא מאובטחים, מתקפות מערוצים צדדיים וכיסוי בלתי מספק של משטח ההתקפה.
נבחן כמה מתקפות מהעולם האמיתי נגד בקרות MFA:
מתקפת MFA מס' 1: ניצול פגמים בארכיטקטורה ובתכנון
הרבה ארגונים פורסים מנגנוני כניסה יחידה single sign-on (SSO) כאשר ה-MFA נועד לצמצם את הסיכון לגניבת הרשאות.
בעבודה שביצענו לאחרונה, ארגון גלובלי גדול שכר ספק MFA מצד שלישי שיאבטח את הגישה ל-VPN. לאחר החיבור ל-VPN, משתמשים מרוחקים השתמשו ב-SSO כדי להגיע לשירותי ענן שונים. ואולם, במהלך הבדיקות שלנו מצאנו שכאשר משתמשים נכנסו מכתובת IP בדוקה בטווח ה-VPN, הם התבקשו לתת רק את הרשאת הדומיין שלהם ומיד לאחר מכן קיבלו גישה לכל שירות ענן.
עובדה זאת חשפה פגם יסודי בארכיטקטורה. ה-MFA הוחל רק על גישה מהתשתית, לא על זהויות משתמשים ספציפיים הניגשים לנכסים קריטיים. הפגם נטרל למעשה את האפקטיביות של ה-MFA, כשהוא מותיר את הארגון פגיע למתקפות מכניסה חד-גורמית. מספיק היה לפרוץ לתחנת עבודה של משתמש אחד ולהשיג גישה ליישום אסימון תוכנה המותקן באותו מכשיר, לכבות בקלות משתמשים אחרים תוך שימוש בסיסמה של משתמש אחד ולהגיע לכל המידע הארגוני, החל מהמייל של המנכ"ל וכלה בקונסולות ענן עוצמתיות.
מתקפת MFA מס' 2: ניצול תהליכי Onboarding לא מאובטחים הנעשים באמצעות אסימונים (tokens)
המטרה בהתקשרות המסוימת הזאת של ה-Red Team הייתה להיכנס לרשתות תעשייתיות רגישות של הארגון, המוגנות באסימוני MFA. עם הכניסה הראשונית לרשת המחשוב התחלנו לבחון את המיילים של המשתמשים. עד מהרה הבחנו במשהו מוזר בתהליך האונבורדינג הראשוני. משתמשים חדשים קיבלו אי-מייל המכיל לינק שעליו נדרשו להקליק כדי להצמיד את אסימון תוכנת ה-MFA של הטלפון לזהות המשתמש בשרת ה-MFA של החברה.
למרבה הצער, אותו לינק הכיל גם את הזרע הקריפטוגרפי לאסימון ה-MFA של המשתמש, או במלים אחרות, את חומר הגלם המוצפן המשמש ליצירת האסימון. החדשות הטובות היו שאותו חומר גלם היה מוגן בקוד PIN.
כעת, כשכל המיילים בידינו, הייתה לנו גישה לצופן והיינו זקוקים רק לקוד PIN ולחותמת זמן כדי לשכפל אסימוני MFA ולחולל קודי OTP משלנו בשם המשתמש. עד מהרה הבנו שכל "זרע" היה מוגן בקוד של ארבע ספרות, שאותו פיצחנו בשניות. כך יכולנו לפרוץ את הצופן לכל אסימון MFA ולשכפל אסימונים של כל משתמש, מה שסיפק לנו גישה מלאה לרשת התעשייתית.
מתקפת MFA מס' 3: תקיפת עוגיות הדפדפן אחרי אימות זהות
מתקפות המתבצעות אחרי שלב אימות הזהות עם MFA מתמקדות בקובצי "העוגיות" והופכות לחלק מהשיטות המועדפות על הצוות שלנו להדמיית מתקפות, ולו רק משום שניתן לבצע אותן מרחוק אחרי עמידה בתנאים מסוימים.
המטרה העיקרית שלנו בהתקשרות זאת עם הלקוח הייתה לפגוע או לגנוב עוגיות בצד הקליינט של ה-session, כלומר בשלב שאחרי אימות הזהות בדפדפן של משתמש הקצה. לדוגמה, כאשר אתם נכנסים לג'ימייל עם ההרשאות שלכם כדי לבדוק דואר, אתם מפעילים "session "עוגיות", המאוחסנות במצב מוצפן בדפדפן שלכם. קובצי עוגיות אלה נשלחים עם כל בקשה לדומיין משנה של ג'ימייל כדי שלא תצטרכו להקיש את הרשאות הגישה שלכם מחדש אחרי כל סגירה של הדפדפן.
במערכות ווינדוס, עוגיות אלו מוצפנות על-ידי ממשק קריפטוגרפי הקרוי DPAPI. ממשק זה מאפשר בעיקרון למשתמש לבצע קריאה יחידה ל-API להצפין או להסיר הצפנה מיחידת נתונים מבלי לבקש הרשאות אדמין מקומיות. בכל סביבה שמצטרפת לדומיין ישנו מפתח גיבוי כוללני המסוגל לפתוח את הצפנת ה-DPAPI של הדומיין כולו. בנוסף, ברגע שמפתח הגיבוי נוצר, לא מחליפים אותו לעולם.
מאחר ו-DPAPI מיועד לשימוש בהקשר של המשתמש, קל להסיר את ההצפנה מהעוגיות בדפדפן המשתמש ולהשתמש בהרשאות שלו עצמו עם קריאה יחידה ל-API של ווינדוס. ברגע שהושגה גישה למפתחות הדומיין, אפשר להרחיב את המתקפה מרחוק לכל המשתמשים והמכשירים באותו דומיין.
מתקפת MFA מס' 4: תקיפת נכסים קריטיים באמצעות ערוצים משניים
כאשר ניתן לגשת למשאבים מערוצים רבים, הרבה ארגונים נוטים להחמיץ את אבטחת הערוצים המשנים. אנו עדים לטעויות רבות כאלו בהתקשרויות שאנו מבצעים כ-Red Team.
במקרה המסוים הזה, ארגון הקים מנגנון MFA עבור האדמין כדי שיוכל להגיע לשרתים קריטיים מסוימים באמצעות פרוטוקול שולחני מרוחק (RDP). כאשר משתמש פריבילגי נכנס לשרת באמצעות RDP, מערכת ההפעלה של ווינדוס קוראת לספק ה-MFA המותקן כמודול נפרד. המשתמש מקבל הודעת "PUSH" הטלפון שלו ונדרש לאמת את ניסיון הכניסה. עם אישור בקשת הכניסה, המשתמש מקבל גישה אינטראקטיבית לשרת באמצעות RDP.
כלומר, אם תוקף יצליח להשיג את שם המשתמש והסיסמה לשרת, ניתן יהיה עדיין לחסום את כניסתו דרך ה-RDP, וטוב שכך. אבל ה-RDP הוא מנגנון חד-סטרי שפועל רק בגישה לתוך הארגון. מה קורה בערוצים אחרים? בסביבות אקטיב דירקטורי (AD) ברירת המחדל מאפשרת יציאות ניהול מרוחקות.
לפרוטוקולים אחרים כגון Server Message Block (SMB ו-Remote Procedure Call (RPC) ניתן להיכנס עם כלים כגון as PsExec, Powershell ואובייקטי COM ישירים אחרים. פרוטוקולים אלה פטורים מגורם האימות השני מאחר ורוב מודולי ה-MFA אינם מכסים תקשורת שאינה אינטראקטיבית. התוקף יוכל להיכנס ולהשיג גישה לשרת תוך שימוש בשם משתמש וסיסמה בלבד.
אימוץ נקודת המבט של התוקפים כדי לחזק את הטמעות ה-MFA בארגון
הצוות האדום של סייברארק משתמש בתגליות אלו כדי לסייע ללקוחות להבין את האיומים המתפתחים מנקודת המבט של התוקפים ולהגן על הארגון באופן יזום , לא רק לאחר מעשה, להגן על מה שחשוב ולהקדים את התוקפים. בשיתוף פעולה עם צוות המומחים והחוקרים שלנו, ארגונים יכולים להגדיר נקודת מוצא שממנה ימשיכו וימדדו כל שיפור עתידי באבטחת הארגון.
ללא ספק, MFA הוא מנגנון אבטחה קריטי בעולמנו הנייד. הוא גם מקשה מאוד על עבודתנו כחברי הצוות האדום של סייברארק. עם זאת, גם אליו יש להתייחס כחלק מהקשר רחב יותר של רובדי אבטחה רבים, הכוללים גם בקרת גישה פריבילגית כגון בידוד ססיות וניהול הרשאות. כמו כל היבטי הבטחה, התכנון וההטמעה חשובים מאוד. חשוב מכל להקפיד על האבטחה התפעולית. כידוע, חוזק האבטחה שווה לחוזק החולייה החלשה ביותר שלה.
מאת שי נהרי, מנהל שירותי Red Team בחברת סייברארק
מחקר זה הוצג כחלק ממסלול "ללמוד מהמעבדות ומה-Red Team" באירועIMPACT LIVE 2021 .
