מה זה בריחה מ-Sandbox ברמה מושגית

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

מה זה בכלל sandbox

ה-sandbox, או בעברית ארגז חול, הוא סביבת הרצה מבודדת שנותנת לקוד לרוץ עם הרשאות מוגבלות מאוד, נמוכות בהרבה מאלה של המערכת שמריצה אותה. הרעיון הבסיסי הוא שאם מריצים קוד שלא סומכים עליו לגמרי - בין אם זה תוכן אתר, אפליקציה שהורדתם, או תהליך בתוך container - עדיף להריץ אותו במקום שבו גם אם הוא מתנהג רע, הנזק שהוא יכול לגרום מוגבל מראש.

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

מה זה אומר "לברוח" מ-sandbox

עכשיו נניח שמישהו הצליח להריץ קוד עוין בתוך אותו sandbox - הצליח להשיג מה שנקרא foothold, נקודת אחיזה ראשונית בתוך הסביבה המוגבלת. בשלב הזה, התוקף עדיין כפוף לכל ההגבלות של ה-sandbox. הוא לא יכול לקרוא קבצים חופשי, לא יכול לגשת לרשת הפנימית, ולא יכול להשפיע על תהליכים אחרים במערכת.

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

למה זה בדרך כלל השלב השני, ולא הראשון

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

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

דוגמאות מושגיות לסוגי sandbox נפוצים

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

• תוכן בתוך דפדפן. כל טאב שפותח אתר מריץ קוד בתוך תהליך מבודד עם הרשאות מוגבלות מאוד, כפי שהסברתי במאמר קודם על ניצול חולשות בדפדפן.
• מכולה כמו Docker - container. תהליכים שרצים בתוך container חולקים את הליבה של מערכת ההפעלה עם המארח, אבל מבודדים ממנה באמצעות מנגנונים שמגבילים מה הם רואים ומה הם יכולים לגעת בו. בריחה מ-container משמעה להגיע להרשאות על המארח עצמו, מחוץ לגבולות שהוגדרו.
• אפליקציית מובייל. גם באנדרואיד וגם באייפון, כל אפליקציה רצה בתוך sandbox משלה, עם הרשאות מוגבלות לגישה לקבצים של אפליקציות אחרות או למשאבי המערכת, אלא אם המשתמש אישר זאת במפורש.

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

לסיכום

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

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

הצטרפו לקהילה בדיסקורד