תוכן העניינים
כיצד הסתמכות על מאפייני זהות הניתנים לשינוי אפשרה לתוקף לעקוף הרשאות, להתחפש למשתמש אחר ולהשיג שליטה מלאה במערכת
יותר ויותר ארגונים מעבירים את ניהול ההזדהות של המשתמשים לשירותי זהות מנוהלים בענן, כמו AWS Cognito. זו בחירה נוחה ויעילה, אך היא טומנת בחובה סיכון שקט: אם האפליקציה סומכת באופן עיוור על המידע שהשירות מחזיר לגבי המשתמש, טעות תכנון אחת יכולה למסור לתוקף את המפתחות לכל המערכת. במבדק חדירה שערכנו לאחרונה, בדיוק זה קרה.
מאפייני זהות – נוחות שהופכת לפרצה
כיצד מאפיין שנועד לפשט את הניהול הופך לחור אבטחה?
שירותי זהות כמו AWS Cognito מאפשרים לצרף לכל משתמש מאפיינים (Custom Attributes), למשל התפקיד שלו, החברה שאליה הוא משתייך והמזהה הייחודי שלו. מאפיינים אלה נשמרים בתוך ה-Token שהמשתמש מקבל בעת ההתחברות, והאפליקציה קוראת מתוכו את התפקיד כדי להחליט אילו פעולות מותרות לו. הבעיה מתחילה כאשר חלק מהמאפיינים האלה ניתנים לעריכה על ידי המשתמש עצמו, ישירות מול שירות הזהות. במצב כזה, האפליקציה מסתמכת על נתון שנמצא בשליטת התוקף כדי לקבוע אילו הרשאות להעניק לו.
הרשמה עצמית ומאפיינים הניתנים לכתיבה
מדוע השילוב של רישום פתוח ומאפיינים הניתנים לעריכה הוא מתכון לצרות?
שירותי זהות כמו AWS Cognito מאפשרים לעיתים רישום עצמי פתוח, כל אחד יכול ליצור לעצמו חשבון ישירות מול השירות, גם כאשר האפליקציה עצמה דורשת קוד הזמנה של ארגון. בפני עצמו זה לא בהכרח קריטי, אך התמונה משתנה כאשר אותם מאפייני הרשאה – התפקיד, החברה ואפילו מזהה המשתמש, ניתנים לכתיבה על ידי המשתמש כבר בבקשת ההרשמה או בעדכון פרטים.
כששני התנאים מתקיימים יחד, תוקף אינו צריך לפרוץ דבר: הוא יוצר חשבון ובאותה נשימה מצהיר על עצמו כמי שירצה. אם ה-Backend סומך על המאפיינים האלה, ההצהרה הופכת למציאות עד כדי קביעת מזהה משתמש של אדם אחר והתחזות מלאה אליו.
עקיפת האימות הדו-שלבי בדלת האחורית
מדוע אימות דו-שלבי לא תמיד מגן, גם כשהוא מופעל?
מנגנון אימות דו-שלבי (MFA) מגן רק אם הוא נאכף במקום שבו ה-Token באמת מונפק. כאשר ה-MFA מיושם רק בשכבת הממשק של האפליקציה (ה-API הרשמי שבו משתמש הלקוח), אך שירות הזהות עצמו מנפיק Token גם בהזדהות ישירה (עם שם משתמש וסיסמה בלבד) נוצר נתיב עוקף שבו לא נדרש קוד ה-OTP כלל.
המשמעות? תוקף שברשותו שם משתמש וסיסמה בלבד יכול לעקוף לחלוטין את שלב האימות השני, מפני שה-MFA אינו נאכף בשירות הזהות, המקום שבו ה-Token נוצר.
מקרה לקוח: משתמש אחד, שליטה על כל המערכת
כיצד שרשרת ליקויים קטנה הובילה להשתלטות מלאה?
במבדק חדירה לאפליקציה לניהול ושירות דיירים התחלנו כתוקף חסר כל הרשאה ללא חשבון וללא קוד הזמנה של ארגון. שלב אחר שלב, הפכנו את נקודת הפתיחה הזו לשליטה מלאה במערכת.
שלב ראשון – הרשמה עצמית. במקום לעבור בתהליך הרישום של האפליקציה, פנינו ישירות ל-AWS Cognito ונרשמנו ללא קוד הזמנה. כבר בבקשת ההרשמה צירפנו לחשבון החדש מזהה משתמש של דייר קיים, כך שלא רק שיצרנו חשבון – שייכנו אותו למזהה שהאפליקציה כבר מכירה.
שלב שני – התחזות. כשהתחברנו, האפליקציה זיהתה אותנו לפי מזהה המשתמש שקבענו בעצמנו ולא לפי מי שבאמת נרשם. מבחינת המערכת היינו אותו דייר קיים, וקיבלנו גישה מלאה לפרופיל ולפרטים האישיים שלו – ואף יכולת לבצע פעולות בשמו.
שלב שלישי – הסלמת הרשאות. שינינו מאפיין אחד בלבד, התפקיד, וקבענו אותו כ“מנהל”. השרת קיבל את השינוי ללא עוררין, ובן רגע הפך החשבון האנונימי שיצרנו לחשבון בעל הרשאות ניהול מלאות.
שלב רביעי – גישה לכל הנתונים. בתור מנהל כבר לא היינו מוגבלים לארגון אחד, אלא ניגשנו למאגר המשתמשים של כלל הארגונים במערכת: שמות, כתובות מייל, מספרי טלפון ופרטים אישיים של אלפי משתמשים מחברות שונות לחלוטין.
ולאורך כל הדרך, איש לא נעצר על ידי ה-MFA. כל הבדיקות בוצעו על חשבונות ייעודיים בלבד, וכל שינוי הוחזר לקדמותו בתום המבדק.
תובנות ממומחי הסייבר של IPV Security
כדי למנוע פרצות מסוג זה כבר בשלב התכנון, אנו ממליצים על העקרונות הבאים:
- להגדיר מאפייני הרשאה ברמת שירות הזהות כך שלא ניתן לכתוב או להזריק אותם מצד הלקוח (הרשאת קריאה או ניהול בלבד).
- לגזור את התפקיד והזהות של המשתמש בצד השרת בלבד, ממקור אמין כמו בסיס הנתונים ולפי המזהה הקבוע והחתום של המשתמש ולא לפי מאפיינים הניתנים לעריכה שבתוך ה-Token.
- לא לאפשר הרשמה עצמית פתוחה מול שירות הזהות; כל יצירת משתמש חדשה תעבור דרך השרת ולאחר אימות הזמנה תקין.
- לאכוף את האימות הדו-שלבי בשלב הנפקת ה-Token עצמו, ולא רק בממשק ההתחברות, כך שלא ניתן יהיה לעקוף אותו בהזדהות ישירה.
לסיכום
שירותי זהות מנוהלים הם כלי רב-עוצמה, אך הם אינם פוטרים את האפליקציה מהאחריות לבדוק ולהצליב את המידע שהם מספקים. כאשר תפקיד, זהות והרשאות נקבעים על סמך נתונים הניתנים לעריכה מצד המשתמש, גבול ההגנה כולו מיטשטש ומשתמש בודד מספיק כדי להשתלט על המערכת כולה.
גם האפליקציה שלכם משתמשת ב-AWS Cognito? מבדק חדירה לאפליקציות של IPV Security יסייע לכם לזהות שרשראות ליקויים כאלה לפני שתוקף יעשה זאת, ולוודא שגבולות ההרשאה במערכת אכן מוגנים.
להתייעצות מקצועית עם מומחי הסייבר של t.077-4447130 IPV Securityשנים של ניסיון בהגנת סייבר, מבדקים וסקרי סיכונים וציות לרגולציות.
שאלות נפוצות
האם שימוש ב-AWS Cognito עצמו יוצר את החולשה?
לא. AWS Cognito מספק שירותי זהות והזדהות, אך האבטחה תלויה גם באופן שבו האפליקציה מגדירה את המאפיינים, ההרשאות וזרימות ההזדהות. החולשה נוצרת כאשר ה-Backend מעניק אמון בנתונים שהמשתמש יכול לשנות או מאפשר נתיב הזדהות שאינו כפוף לאותן בקרות אבטחה.
למה מסוכן להשתמש ב-Custom Attributes לצורך קביעת הרשאות?
מכיוון שלא כל Attribute בהכרח מתאים לשמש כמקור סמכות להרשאות. אם משתמש יכול לשנות Attribute שמייצג תפקיד, ארגון או זהות, והשרת מסתמך עליו כדי להחליט מה מותר לו לבצע, המשתמש למעשה יכול להשפיע על ההרשאות שלו עצמו. הרשאות צריכות להיגזר בצד השרת ממקור אמין שאינו בשליטת המשתמש.
איך MFA יכול להיות מופעל ועדיין להיות ניתן לעקיפה?
MFA יעיל רק אם הוא נאכף בכל נתיב שמאפשר למשתמש לקבל Token. אם האפליקציה דורשת קוד נוסף דרך ממשק ההתחברות, אך שירות הזהות מאפשר לקבל Token באמצעות תהליך אחר עם שם משתמש וסיסמה בלבד, נוצר נתיב עוקף. לכן חשוב לבדוק לא רק אם MFA מופעל, אלא היכן וכיצד הוא נאכף בפועל.
מהו השילוב שהפך את הממצא לחמור במיוחד?
לא חולשה בודדת, אלא שרשרת של ליקויים: הרשמה עצמית ללא הזמנה, אפשרות לשלוט במאפייני זהות והרשאה, הסתמכות של השרת על אותם מאפיינים, ונתיב הזדהות שבו MFA לא נאכף. יחד, החולשות אפשרו להפוך משתמש חדש למשתמש קיים, להסלים את הרשאותיו ולגשת למידע של משתמשים וארגונים נוספים.
כיצד ניתן למנוע שרשרת חולשות כזו?
יש להפריד בין נתונים שהמשתמש יכול לספק לבין נתונים שקובעים את זהותו והרשאותיו. תפקידים והרשאות צריכים להיקבע בצד השרת ממקור אמין, הרשמה צריכה לעבור תהליך בקרה מתאים, ומנגנון MFA צריך להיאכף בנקודת הנפקת ה-Token ובכל נתיב חלופי שמאפשר הזדהות.