גילוי פגיעות חמורה: עקיפת בקרת גישה באמצעות שינוי כותרת ה־Host

איך באמצעות שינוי כותרת ה־Host אפשר לעקוף מדיניות גישה המבוססת כתובת IP (Whitelist)
במסגרת סקר סיכונים של אחד מלקוחותינו, הצוות הטכני שלנו ביצע מבדק חדירה אפליקטיבי מקיף לארגון. מטרת המבדק הייתה לבדוק את רמת האבטחה של האפליקציה ולזהות פגיעויות פוטנציאליות, הן משטח ההתקפה החיצוני והן משטח ההתקפה הפנימי (Black-Box ו־Gray Box) מה שגילינו היה פשוט לביצוע, אך יכול להוביל לתוצאות הרסניות.

הבנת הפגיעות : Host Header Injection
פגיעות מסוג Host Header Injection מתרחשת כאשר שרת האינטרנט מתבסס על כותרת (Header) ה־Host כדי להחליט לאיזה דומיין להפנות את הבקשה, ואינו מבצע בדיקה מספקת של כותרת זו. כאשר ישנו שימוש ברשימת גישה (Whitelist) המבוססת על כתובת IP כדי לקבוע מי מורשה לגשת לאתר מסוים, שינוי כותרת ה־Host עלול לאפשר לתוקף לעקוף את הבדיקה הזו.

סיפור לקוח: עקיפת בקרת גישה באמצעות שינוי כותרת ה־Host
במהלך מבדק החדירה האפליקטיבי שבוצע לאתר שמארח סאב דומיינים מרובים – סאב דומיין עבור כל לקוח של החברה, נתקלנו בבעיה פשוטה שחשפה את הסכנות הטמונות בבדיקת גישה המבוססת על כותרת ה־Host בלבד. הכול התחיל כשנמסר למומחה האבטחה שלנו כי כלל סביבות הלקוחות – הסאב-דומיינים (a.domain.com) מוגנות באמצעות רשימת גישה (Whitelist) מבוססת כתובות IP חיצוניות, מלבד סאב-דומיין אחד (b.domain.com) שהיה נגיש לכל העולם לאור דרישת הלקוח.

במהלך המבדק, בוצעו ניסיונות לשלוח בקשות אל הסביבות המוגנות, באמצעות זיוף כתובות ה־IP של המומחים עם ה־Header "X-Forwarded-For" לכתובות IP מולבנות או פנימיות כמו 127.0.0.1 (localhost) – כולן נכשלו להגיע אל היעד.
כיוון שלא הצלחנו לשלוח בקשות אל הסביבות האחרות, החלטנו להתרכז בסביבה המוחצנת, ולנסות דרכה להגיע אל הסביבות האחרות.
במהלך הניסיונות שביצענו, החלטנו לשלוח בקשה אל השרת המוחצן, ולאחר מכן לערוך את הבקשה ולשנות את ה־Host Header לסביבה אחרת.
למרבה ההפתעה, השרת קיבל את הבקשה, ומכיוון שהכותרת Host הייתה של הסביבה המוגנת, השרת התייחס לבקשה כאילו הגיעה לדומיין המוגן והחזיר לנו תשובה שמעידה כי אכן מדובר בסביבה המוגנת.

אז מה בעצם קרה פה?
קיימים כמה Sub-Domains המתארחים על אותו השרת ושרתי Web כמו Nginx ו־Apache לרוב מסתמכים על ה־Host Header כדי להחליט איזה אתר (במקרה שלנו סביבת לקוח) להציג. לפיכך במקרה כמו שלנו, כאשר השרת מארח כמה דומיינים, הוא משתמש ב־Host header כדי לשלוח את הבקשה לאתר הנכון. לכן אף שהבקשה עצמה (ה־HTTP Request) נשלחה לדומיין א', כיוון שה־Host Header הצביע על דומיין ב', הבקשה הועברה לתשובת דומיין ב'.

התוצאה
באמצעות שינוי פשוט של כותרת ה־ Host הצלחנו לעקוף את בקרת הגישה המבוססת על רשימת כתובות IP. כך קיבלנו גישה למשאבים מוגנים שהיו אמורים להיות זמינים למשתמשים מסוימים בלבד.

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

1. אימות כותרת Host: יש לוודא שהשרת מאמת את כותרת ה־Host מול הרשימה הצפויה של דומיינים ואינו מסתמך על הכותרת שהתקבלה בבקשה בלבד.
2. שימוש בשרת Proxy: אפשר להשתמש בשרת Proxy כדי לוודא שכל הבקשות עוברות בדיקה נוספת ושהפנייה לדומיין המתאים נעשית בצורה מאובטחת.
3. בקרת גישה מבוססת כתובת IP: לוודא שהגישה לדומיינים מוגנים מתבצעת לא רק באמצעות כותרת Host, אלא מבוססת גם על כתובת ה־IP של המשתמש.
4. לוג ומעקב: יש לבצע לוג ומעקב אחר כל הבקשות הנכנסות לשרת, בייחוד אלו המכילות כותרת Host שונה מהצפוי, כדי לזהות ניסיונות לגשת למשאבים מוגנים.
5. יישום מדיניות אבטחת מידע: להטמיע ולחזק מדיניות אבטחת מידע ברורה ונוקשה. לוודא כי כל גישה למידע רגיש נבדקת ומאומתת על פי הקריטריונים המתאימים.
6. בדיקות אבטחה תקופתיות: לבצע בדיקות חדירה ואבטחה באופן תקופתי כדי לזהות ולתקן פרצות אבטחה פוטנציאליות במערכות הקיימות בארגון.

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

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

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