כך אפשרה חולשה אחת גישה למידע רגיש ולמשאבי ענן

מקרה לקוח: ניצול SSRF להדלפת מידע רגיש ולגישה למשאבי ענן

כיצד פרצת Server-Side Request Forgery הובילה לשליפת קובצי מערכת, התחברות לשירותים פנימיים ולגישה ל־Azure AD

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

הבנת הפגיעות: מהי SSRF ולמה היא מסוכנת כל כך

תוקפים יכולים לגרום לשרת לבצע בקשות בשמם – פנימיות או חיצוניות

SSRF או בשמה המלא Server-Side Request Forgery, היא חולשת אבטחה שבה תוקף מצליח לגרום לשרת לשלוח בקשות HTTP למשאבים לפי בחירתו. ברוב המקרים, הדבר מתרחש כאשר האפליקציה מאפשרת למשתמש להזין URL או HTML, בלי בדיקה מספקת. פגיעות זו מאפשרת עקיפת בקרות גישה, סריקת רשת פנימית, שליפת מידע ענן (כגון AWS Metadata), גניבת מפתחות API, או אפילו התחברות לשירותים פנימיים שאינם חשופים לעולם החיצון.

ככה פשוט ככה קריטי: תצוגה מקדימה של PDF הפכה לשער כניסה לשרת

כיצד מנגנון תמים של יצירת PDF הפך לסיכון עצום לארגון

החולשה התגלתה בדף המאפשר תצוגה מקדימה של קובץ PDF. לחיצה על כפתור "תצוגה מקדימה" שלחה בקשת HTTP עם תוכן HTML, תוכן שהמשתמש יכול לערוך. אותו תוכן רונדר ע"י השרת באמצעות ספריית צד שלישי ונהפך לקובץ PDF. באמצעות שינוי תוכן הפרמטר הרלוונטי, הצלחנו להזריק תגיות HTML מזיקות, כגון iframe או script, המבצעות בקשות XHR (בקשות הגורמות לשרת לבצע בעצמו בקשות HTTP) ולגרום לשרת לשלוח בקשות לעצמו (localhost) או למשאבים פנימיים. כך, כאשר הזרקנו לדוגמה תג iframe ל־localhost:3000, קיבלנו קובץ PDF שהכיל תמונה המראה את המסך "ברוך הבא ל־Nginx".

שליפת מידע רגיש: קובצי מערכת, מפתחות ופרטי התחברות לענן

כיצד פגיעות ה־SSRF אפשרה לנו לשלוף קובצי סיסמאות, Private Keys ו־API Tokens

באמצעות הפגיעות שהתגלתה בספריית ה־PDF Generator שהאפליקציה השתמשה בה, במקום לשלוח בקשות HTTP, השתמשנו בבקשות File Protocol (//:file, אותו פרוטוקול שבשימוש כאשר אנו קוראים קובץ PDF באמצעות הדפדפן לדוגמה). כך באמצעותו, הצלחנו לקבל בחזרה בקובץ ה־PDF שנוצר תכנים מקובצי מערכת כמו /etc/passwd, קובצי קונפיגורציה, Private Key לשירות ה־SSH של אחד המשתמשים, סיסמאות למסדי הנתונים של האפליקציה ו־Secrets נוספים הקשורים לפלטפורמות הענן של הארגון.

פריצה לשירותי Azure: גישה מלאה ל־Azure Active Directory

כיצד באמצעות ה־Secrets שנשלפו, התחברנו לשירותי הארגון בענן

כחלק מפרטי ההתחברות וה־Secrets שהשגנו, הצלחנו להתחבר ל־Microsoft Graph API ולבצע פעולות שליפה של כל המשתמשים הארגוניים. היו בבעלותנו הרשאות נרחבות ליצירה, עריכה ומחיקה של משתמשים וקבוצות ב־Azure Active Directory. זאת ועוד, הצלחנו להיכנס לחשבון משתמש השירות של האפליקציה ללא צורך באימות דו־שלבי (MFA), מפני שהוא משמש כמה גורמים בארגון ולכן שויך לקבוצה: "No MFA Group". כך, באמצעות אתר של ארגון, הצלחנו להשתלט על עוד ועוד תשתיות בארגון ולקבל גישה למידע רגיש ומסוכן באפליקציה.

המלצות מומחי הסייבר של IPV Security

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

1. להימנע מאפשרות עריכה של HTML בצד הלקוח – אין לבצע את תהליך יצירת תוכן ה־PDF בצד הלקוח ולחשוף אותו לשינויים שיכולים להתבצע ע"י המשתמש. כל תוכן ליצירת PDF יש לעבד אך ורק בצד השרת.
2. להחליף ספריות פגיעות – יש לשקול מעבר לספריית HTML to PDF מאובטחת יותר שאינה פגיעה ל־SSRF ונשארת מתוחזקת ומעודכנת מבחינת אבטחת מידע.
3. להשתמש בפתרונות ניהול Secrets ייעודיים – יש לאחסן סיסמאות, מפתחות API ומפתחות לשירותים חיצוניים באמצעות פתרונות ניהול סודות מאובטחים בלבד, כגון AWS Secrets Manager  או Azure Key Vault. אין לשלב Secrets בקוד המקור או בקובצי קונפיגורציה גלויים – גם לא בסביבות Staging או Dev. כך אפשר להבטיח הפרדה בין הקוד לבין הנתונים הרגישים, ולאפשר שליטה, ניטור והגדרה של הרשאות גישה מדויקות עבור כל Secret.
4. להגביל גישה לשירותים פנימיים – יש לוודא כי שירותים רגישים כמו SSH אינם פתוחים לגישה חיצונית מהאינטרנט. מומלץ לחשוף אותם רק ברשתות פנימיות או באמצעות חיבורי VPN מאובטחים, ולהשתמש ב־Firewall או Security Groups כדי לאפשר גישה מכתובות IP מוגדרות מראש בלבד. נוסף לכך, מומלץ לשלב מנגנוני אימות חזקים (כגון מפתחות ציבוריים/פרטיים ו־MFA) ולנטר ניסיונות התחברות חשודים.

לסיכום,

מנגנונים פשוטים שלא מאובטחים כראוי עלולים להפוך לשער כניסה עבור תוקפים. המקרה שגילינו ממחיש עד כמה פרצת SSRF מסוכנת כאשר לא מבוצעת הקשחה מתאימה בצד השרת. תהליך תמים של תצוגת PDF הפך בקלות לדרך לשלוף קבצים רגישים, פרטי התחברות ולהשיג גישה לפלטפורמת הענן הארגוני. הקפדה על ניהול ספריות קוד, בקרות גישה ובידוד בין רכיבי המערכת – היא קריטית בהגנה על נכסי הארגון. והכי חשוב – מקרה זה מדגיש את חשיבות ביצוע בדיקות חוסן לאפליקציות ולאתרים לפני יציאתם אל העולם.

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