מה זה SSRF ולמה זו אחת החולשות הכי מסוכנות בעולם הענן¶
תארו לעצמכם שבנוי לכם קיר הגנה מושלם סביב הבית - דלת פלדה, אזעקה, מצלמות. ואז מתברר שיש לכם עוזר אישי שיוצא ונכנס בחופשיות, ומוכן לבצע כל בקשה שמישהו לוחש לו באוזן, בלי לשאול שאלות. זה בדיוק מה שקורה בחולשת SSRF, ואם עברתם כבר את הבסיס של פריצת אתרים ואתם רוצים להבין למה זו אחת החולשות שהכי מפחידות צוותי אבטחה בענן, זה המדריך בשבילכם.
אז מה זה בעצם SSRF¶
החולשה SSRF, שראשי התיבות שלה הם Server-Side Request Forgery, קורה כשתוקף מצליח לגרום לשרת לשלוח בקשת רשת למקום שהוא לא היה אמור לשלוח אליו. במקום שאתם, המשתמש, שולחים בקשה ישירות ליעד, אתם משכנעים את השרת לשלוח אותה בשבילכם. השרת הופך בלי לדעת לפרוקסי פרטי של התוקף.
זה נשמע פשוט, אבל התוצאה חמורה - השרת נמצא במקום שאתם, כמשתמשים אנונימיים מבחוץ, לא נמצאים בו. יש לו גישה לרשת הפנימית, לשירותים שלא חשופים לאינטרנט, ולפעמים אפילו להרשאות שאתם רק חולמים עליהן.
למה זה כל כך מסוכן דווקא בענן¶
בסביבות ענן כמו AWS, Azure ו-GCP, לכל מכונה וירטואלית יש כתובת פנימית מיוחדת - לרוב 169.254.169.254 - שמחזירה מטא-דאטה על המכונה עצמה. דרך הכתובת הזאת אפשר לפעמים לשלוף פרטי הרשאה זמניים (credentials) של המכונה, מפתחות API, ולעיתים אפילו סודות מלאים שהוגדרו לשירות.
אם שרת פגיע ל-SSRF רץ בתוך סביבת ענן כזאת, תוקף שמצליח לגרום לו לשלוח בקשה לכתובת הזאת יכול לצאת עם פרטי הרשאה מלאים למשאבי הענן של החברה - דליי אחסון, מסדי נתונים, ולפעמים שליטה כמעט מלאה בחשבון הענן כולו. זו הסיבה שבגללה SSRF נחשב היום לאחת החולשות המשמעותיות ביותר בכל מבדק חדירה שמתבצע על מערכת שרצה בענן.
עקיפת חומת האש מבפנים¶
בעיה נוספת היא שרוב הרשתות בנויות סביב ההנחה שהאיום מגיע מבחוץ. יש חומת אש שחוסמת גישה מהאינטרנט לרשת הפנימית, אבל אין כמעט הגבלה על מה שהשרת עצמו, שכבר נמצא בפנים, יכול לגשת אליו. SSRF מנצל בדיוק את הפער הזה - התוקף לא צריך לפרוץ את חומת האש, הוא פשוט משתמש בשרת שכבר נמצא משני צדדיה כדי לשלוח בקשות פנימה בשמו.
כך אפשר להגיע לפאנלים ניהוליים פנימיים, שרתי מסדי נתונים בלי אימות כי "ממילא רק שרתים פנימיים מדברים איתם", וממשקי ניהול תשתית שאף אחד לא חשב שצריך להגן עליהם מהרשת הפנימית עצמה.
איפה SSRF אוהב להתחבא¶
הבעיה עם SSRF היא שהיא לא נמצאת רק במקום מובן אחד. היא מתחבאת בכל תכונה שבה השרת שלכם צריך לשלוף משהו מכתובת שאתם, כמשתמשים, מספקים לו:
- מושכי URL - URL Fetchers. תכונות כמו "תצוגה מקדימה של קישור" שבהן השרת ניגש לכתובת שהזנתם כדי להביא כותרת או תמונה.
- וובהוקים - Webhooks. כשמערכת מאפשרת לכם להגדיר כתובת שאליה יישלחו התראות, השרת שלה בעצם שולח בקשות ליעד שאתם קובעים.
- מחוללי PDF ותמונות. שירותים שהופכים דף HTML או כתובת לקובץ PDF או לתמונה חייבים לגשת לתוכן הזה מהשרת, ולעיתים קרובות אפשר להזין להם כתובת שרירותית.
- פרוקסי תמונות - Image Proxies. שירותים שמורידים תמונה מכתובת חיצונית כדי להציג אותה מהשרת שלכם, במקום ישירות מהמקור.
- אימות כתובות חזרה ב-SSO ו-OAuth. תהליכי התחברות מסוימים דורשים מהשרת לאמת או לגשת לכתובת callback, ואם האימות הזה לא מספיק קפדני, גם הוא הופך לדלת פתוחה.
למה זה חמור כל כך מנקודת מבט הגנתית¶
הסיבה ש-SSRF הפך לחולשה כה מדוברת בשנים האחרונות היא לא רק שהיא נפוצה - היא גם קשה במיוחד להגנה מלאה. אי אפשר פשוט לחסום את כל הכתובות הפנימיות ברשימה שחורה, כי יש עשרות דרכים לעקוף רשימה כזאת - קידודים שונים של אותה כתובת, הפניות (redirects) שמובילות מכתובת חיצונית תמימה לכתובת פנימית, ואפילו שינויי DNS שמחזירים כתובת פנימית עבור דומיין שנראה חיצוני לגמרי.
ההגנה הנכונה בדרך כלל דורשת שילוב של רשימה לבנה קפדנית של יעדים מותרים, בידוד רשתי אמיתי בין השרת לרשת הפנימית הרגישה, וחסימה של גישה למטא-דאטה של הענן ברמת התשתית עצמה, לא רק ברמת הקוד.
זו בדיוק סיבה טובה להבין את החולשה הזאת לעומק, מהצד התוקף ומהצד המגן גם יחד - ואת זה בדיוק אנחנו עושים בקורס פריצת אתרים מתקדם, עם תרגול על מערכות אמיתיות שמדמות בדיוק את התרחישים האלה.
יש לכם שאלה על SSRF באמצע התרגול? זה בדיוק המקום לשאול.
לסיכום¶
ה-SSRF הוא לא עוד חולשה ברשימה - הוא הדרך שבה תוקף הופך את השרת שלכם לשליח שלו, וחודר איתו לכל מקום שהשרת עצמו יכול להגיע אליו. בעולם שבו כמעט הכל רץ בענן והמטא-דאטה של המכונה שווה יותר מכל הזרקת SQL, זו בדיוק החולשה ששווה להכיר קודם לכולן.