כיצד שינוי מספר בודד בקישור לאתר יכול לחשוף מידע רגיש?
מומחי האבטחה שלנו גילו פגיעות קריטית במהלך בדיקה שגרתית – קראו כיצד זה קרה ולמדו כיצד להגן על הארגון שלכם מפני איומים דומים!
במסגרת סקר סיכונים של אחד מלקוחותינו, הצוות הטכני שלנו ביצע מבדק חדירה אפליקטיבי מקיף לארגון. מטרת המבדק הייתה לבדוק את רמת האבטחה של האפליקציה ולזהות פגיעויות פוטנציאליות, הן משטח ההתקפה החיצוני והן משטח ההתקפה הפנימי (Black ו־Gray Box).
מה שגילינו היה פשוט למדיי לביצוע והוביל לתוצאות הרסניות.
אז מה זה בעצם Broken Access Control ו־IDOR ואיך הם קשורים למספרים רציפים?
Broken Access Control היא אחת הפגיעויות הנפוצות ביותר באתרי אינטרנט, ומופיעה במקום הראשון ברשימת OWASP TOP 10 (ארגון עולמי, שאינו למטרת רווח, המתמקד בשיפור רמת אבטחת המידע של מערכות תוכנה) לשנת 2021. פגיעות זו מתרחשת כאשר מנגנוני בקרת הגישה אינם מוגדרים או אינם מתבצעים כראוי, מה שמאפשר למשתמשים לבצע פעולות שאינן מורשות להם או לגשת למידע רגיש. המשמעות היא שאפילו משתמשים בעלי הרשאות נמוכות יכולים, במקרים מסוימים, לגשת למידע או לבצע פעולות שמורשות למשתמשים ברמת גישה גבוהה יותר.
פגיעות IDOR (Insecure Direct Object References) היא דוגמה לפגיעות במסגרת Broken Access Control. היא מתרחשת כאשר אתר אינטרנט או אפליקציה מאפשרים למשתמשים לשנות מספרים בכתובת האתר כדי לגשת למידע שאינו שלהם. לדוגמה, אם כתובת מסוימת מכילה מספר של קובץ או משתמש, שינוי המספר הזה יכול לאפשר למישהו לגשת לקבצים או למידע של אחרים.
סיפור לקוח: שימוש במספרי לקוחות רציפים.
במהלך מבדק החדירה האפליקטיבי שבוצע לאתר המאפשר לארגונים שונים לנהל באמצעותו את דרכי התקשורת עם הלקוחות שלהם, נתקלנו בסיטואציה שחשפה את הסכנות הטמונות בשימוש במספרים רציפים כאובייקטים ישירים. הכל התחיל כשמומחה האבטחה שלנו גילה ב־URL של אחת מקריאות ה־API באפליקציה שימוש במספר כמזהה לקובץ בעל מידע רגיש שנשלח על ידי אחד הלקוחות.
כתובת ה־URL של קריאת ה־API הייתה נראית כך:
https://vulnreableapp.com/api/v1/customers/12345/file
קריאת API זו החזירה לינק ל־AWS s3 Bucket אשר נתן הרשאה זמנית לגשת לקובץ. כאשר נכנסים לאותו לינק, המערכת הציגה את הקובץ שהועלה על ידי אותו לקוח, כולל כל המידע הרגיש והפרטי שהכיל.
המומחה זיהה פה בעייתיות וניסה להזין מספר מזהה שונה בקריאת ה־API:
https://vulnreableapp.com/api/v1/customers/12346/file
למרבה ההפתעה, התקבל לינק זמני נוסף לשירות ה־AWS s3 Bucket, ובו קובץ של לקוח אחר שאינו נשלח לאותו ארגון שאליו השתייך המומחה.
כך התגלה כי אנשי שירות מארגון אחד יכולים לגשת לקבצים של לקוחות מארגונים אחרים על ידי שינוי מספר ה־ID של הלקוח בבקשה בכתובת האתר. ככל שהמומחה בדק יותר, כך נחשפו עוד ועוד פרטים רגישים על לקוחות שונים, כל זאת על ידי שינוי פשוט של מספר בכתובת האתר.
תובנות מומחי סייבר בכירים של IPV Security:
כדי למנוע תרחישים דומים באתרי הארגון שלכם, אנו ממליצים לבצע את הפעולות האלו:
- אימות הרשאות משתמשים – יש לוודא שכל פעולה מוגבלת למשתמשים בעלי ההרשאות המתאימות בלבד. יש לערוך בדיקה והגדרה מחודשת של מנגנוני בקרת הגישה באופן תקופתי. במקרה הספציפי שלנו, יש לוודא כי אותו איש שירות משויך לאותו ארגון שאליו שייכים הנתונים שהוא מבקש גישה אליהם.
- שימוש במזהים אקראיים ולא במזהים עוקבים – במקום להשתמש במספרים רצים כמזהים, יש להשתמש במזהים אקראיים (UUIDs) שאינם ניתנים לניחוש.
- יישום מדיניות אבטחת מידע – יש להטמיע ולחזק מדיניות אבטחת מידע ברורה ונוקשה ולוודא כי כל גישה למידע רגיש נבדקת ומאומתת על פי הקריטריונים המתאימים.
- בדיקות אבטחה תקופתיות – יש לבצע בדיקות חדירה ואבטחה באופן תקופתי כדי לזהות ולתקן פרצות אבטחה פוטנציאליות במערכות הקיימות בארגון.
לסיכום,
הממצא שגילינו בבדיקת החדירה מדגים את הסכנות הכרוכות בשימוש במספרים רציפים כאובייקטים ישירים ואת הצורך הקריטי ביישום בקרת גישה חזקה ומאובטחת. באמצעות נקיטת הצעדים המומלצים ויישום אמצעי האבטחה המתאימים, נוכל לצמצם את הסיכון לחשיפות מידע ולהבטיח את בטיחות המידע הארגוני.
הקפדה על תהליכי אבטחת מידע קפדניים וביצוע בדיקות תקופתיות הם המפתח לשמירה על ביטחון המידע בארגון והגנה מפני פרצות אבטחה חמורות.
מעוניינים לבצע מבדק חדירה?
לכל התייעצות בנוגע לאבטחת מידע ניתן לפנות לחברת IPV Security במייל info@ipvsecurity.com או במספר הטלפון 077-4447130. החברה מתמחה זה 19 שנה באבטחת מידע ועוסקת בסקרי סיכונים הנוגעים לביטחון מידע.
