איך פרצנו לאפליקציה דרך סביבת הבדיקות!

מקרה לקוח: סביבת Staging חשופה שהובילה להסלמת הרשאות וגישה למידע רגיש באמצעות משתמש Demo במערכת

כיצד חשיפת קריאות API בסביבת בדיקות אפשרה לתוקף להשיג גישת אדמין במערכת

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

הפגיעות הראשונית: חשיפת קריאות API האפשריות בסביבת Staging

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

במהלך המבדק התגלה כי סביבת ה־Staging של הארגון הייתה פתוחה לכל גורם חיצוני, ללא הגבלת גישה או צורך באימות. במהלך הבדיקה, מצאנו שה־API של המערכת פועל ב־GraphQL, ובניגוד לסביבת ה־Production, הוא מאפשר אינטרוספקציה (Introspection) – מנגנון שמאפשר לראות את כל קריאות ה־API הקיימות במערכת. פגיעות זו אפשרה לנו ללמוד על מבנה קריאות ה־API, הרשאות המשתמשים והפעולות שאפשר לבצע – מידע קריטי עבור כל תוקף פוטנציאלי.

הפגיעות הקריטית: כיצד גילוי של קריאת API הובילה להסלמת הרשאות

משתמש רגיל הצליח להפוך לאדמין באמצעות בקשת API בלבד

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

חיבור הנקודות: גישת Demo באתר החברה הובילה לחשיפה חמורה

כיצד משתמש דמו באתר ה־Production אפשר גישה לכלל הנתונים של הארגון

בבדיקות נוספות שערכנו, גילינו כי באתר הרשמי של החברה, בסביבת ה־Production, הייתה אפשרות לגשת לאפליקציה כמשתמש "Demo", משתמש קיים במערכת שאינו דורש התחברות.
כיוון שהפגיעות שהתגלתה באמצעות סביבת ה־Staging הייתה רלוונטית גם עבור משתמשים פשוטים, הצלחנו לבצע את אותה הסלמת הרשאות עם משתמש ה־Demo באתר החברה, ולהפוך אותו למשתמש אדמין מלא.
באמצעות הרשאות אלו, קיבלנו גישה מלאה לכלל לקוחות הארגון, כולל מידע רגיש ביותר עם הרשאות קריאה, כתיבה ומחיקה – מצב חמור מאוד מבחינת אבטחת המידע של החברה.

תובנות ממומחי סייבר בכירים של IPV Security

כדי להימנע מחשיפות כאלה בעתיד, אנו ממליצים לבצע את הפעולות האלה:

1. הגבלת גישה לסביבת Staging – יש לוודא שסביבות בדיקות אינן פתוחות לכלל האינטרנט, אלא מוגבלות לגישה פנימית בלבד. אם הגישה אליהן נדרשת, יש לאבטח אותן בדיוק כמו סביבות ה־Production.
2. נטרול אינטרוספקציה ב־GraphQL – יש להשבית את אפשרות ה־Introspection ב־Production וב־Staging, כך שלא יהיה אפשר לשלוף מידע על קריאות ה־API הקיימות.
3. בקרת הרשאות מחמירה בקריאות API – כל קריאה צריכה להיות מאובטחת בצד השרת, כך שמשתמשים לא יוכלו לשנות את רמת ההרשאות שלהם ללא בקרת גישה מתאימה.
4. בדיקות חדירה תקופתיות – מומלץ לבצע מבדקי חדירה באופן קבוע כדי לאתר חשיפות במערכות, בייחוד חשיפה של סביבות בדיקות.

לסיכום: כיצד למנוע פגיעויות דומות בעתיד

אבטחת סביבת Staging חשובה לא פחות מאבטחת ה־Production

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

להתייעצות מקצועית ניתן לפנות אלינו לאימייל info@ipvsecurity.com או במספר הטלפון 077-4447130. IPV Security מתמחה זה 20 שנה באבטחת מידע, סייבר, סקרי סיכונים ותקנים ורגולציות הנוגעים לביטחון מידע ועוד.