כיצד יתקפו גורמי איומים וישתמשו במכולות? זו שאלה שאני חושב עליה כל הזמן. אני עובד בתחום הזה כבר יותר משני עשורים, ואני מרגיש שצריכה להיות לי תשובה. אבל אני לא.
במקום זאת, יש לי הרבה רעיונות שונים, שאף אחד מהם לא באמת יכול להצביע כנכון. חלק מחוסר ההחלטיות הזה הוא בגלל כל הזמן שביליתי בלימוד אבטחה בעולם ה"מורשת". למיכלים אין ממש אנלוגי. בטח, מכונות וירטואליות (VMs) מתערבבות לעתים קרובות עם קונטיינרים, אבל הם אף פעם לא הצליחו להגדיל כמו קונטיינרים. הם משמשים גם למטרות שונות לחלוטין ממכולות. לקח זמן להתאים את החשיבה שלי ולהבין היכן מכולות באמת נכנסות למשטח ההתקפה.
הדוגמאות הציבוריות להתקפות נגד סביבות מכולות מוגבלות מאוד. ההפרות כמעט תמיד קשורות להצפנה, שהן התקפות חמורות, אבל המגיב לאירוע שבי מוצא אותן עצומות. משותף נוסף הוא שהם בעיקר תוצאה של תצורה שגויה, בין אם זה ב-Kubernetes או בחשבון ענן. השילוב בין המניעים והטקטיקה לא היה מאוד מעורר השראה עד כה.
הדרך העתיקה
פגיעויות של ביצוע קוד מרחוק (RCE) היו הדאגה העיקרית באבטחת מחשבים במשך זמן רב. הם עדיין, אבל איך צורת החשיבה הזו חלה על מכולות? קל לקפוץ מיד אל RCE כאיום העיקרי, אבל נראה שזו לא הדרך הנכונה לגשת למכולות. ראשית, מיכלים הם לרוב קצרים מאוד - 44% מהמכולות חיים פחות מחמש דקות - אז פולש יצטרך להיות מהיר.
גישה זו גם מניחה שהמכולה חשופה לאינטרנט. אין ספק שחלק מהקונטיינרים מוגדרים כך, אך לרוב הם פשוטים מאוד ומשתמשים בטכנולוגיות שנבדקו היטב, כמו NGINX. ייתכן שיהיו אפס ימים עבור יישומים אלה, אבל הם יהיו בעלי ערך רב וקשה להשגה. הניסיון שלי הראה לי שהרבה קונטיינרים נמצאים בשימוש פנימי ואינם מתחברים ישירות לאינטרנט. תרחיש RCE נעשה הרבה יותר קשה במקרה זה. אני צריך להזכיר log4j, אם כי לסוגים אלה של פגיעויות יש פוטנציאל לניצול מרחוק גם אם המערכת הפגיעה אינה בקצה.
דרך חדשה /
אם RCE אינו האיום הגדול ביותר שעומד בפני מכולות, אז מה כן? האם מכולות אפילו על הרדאר של גורמי איומים? כן, מיכלים והתשתית התומכת שלהם חשובים מכדי להתעלם מהם. תוכנת תזמור מיכל אפשרה להגדיל את עומסי העבודה במכולות למספרים בלתי נתפסים. מגמת השימוש גם גוברת, כך שתוכלו להיות בטוחים שהם יהיו יעד. פשוט אי אפשר לחשוב עליהם כמו שרתים שאתה מגיע אליהם דרך פרצות RCE.
במקום זאת, ההיפך הוא למעשה נכון. במקום לתקוף מכולות מבחוץ פנימה, צריך לתקוף אותן מבפנים החוצה. זה בעצם מה שעושות התקפות שרשרת האספקה. שרשרת אספקה היא וקטור התקפה יעיל ביותר נגד מכולות כאשר מתחילים להבין כיצד הם בנויים. קונטיינר מתחיל בקובץ הגדרה, כמו Dockerfile, שמגדיר את כל מה שיהיה בקונטיינר כשהוא פועל. זה הופך לתמונה ברגע שנבנה, והתמונה הזו היא מה שעשוי להסתובב לעומס עבודה אינספור פעמים. אם משהו בקובץ ההגדרה הזה נפגע, אז כל עומס עבודה שפועל נפגע.
קונטיינרים לרוב, אך לא תמיד, בנויים ייעודיים עם אפליקציה שעושה משהו ויוצאת. יישומים אלה יכולים להיות כמעט כל דבר - הדבר שחשוב להבין הוא כמה נבנה באמצעות ספריות, קוד סגור או קוד פתוח, שנכתבו על ידי אנשים אחרים. ל-GitHub יש מיליוני פרויקטים, וזה לא מאגר הקוד היחיד שקיים. כפי שראינו עם SolarWinds, קוד סגור פגיע גם להתקפות שרשרת האספקה.
התקפת שרשרת אספקה היא דרך מצוינת עבור גורמי איומים להיכנס לסביבת המכולה של המטרה. הם אפילו יכולים לתת לתשתית של הלקוח להתאים את ההתקפה שלהם עבורם אם הפשרה תיעלם מעיניהם. סוג זה של תרחיש כבר מתרחש, כפי שראינו עם הפרת Codecov. אבל קשה לזהות בגלל כמה כל זה חדש ואיך החשיבה שלנו עדיין נטועה בבעיות העבר.
הדרך הלאה
כמו בתיקון רוב הבעיות, הנראות היא בדרך כלל מקום מצוין להתחיל בו. קשה לתקן את מה שאתה לא יכול לראות. כדי לאבטח את המכולות שלך אתה צריך להיות נראות לתוך המכולות עצמן, כמו גם את כל הצינור שבונה אותם. ניהול פגיעות הוא סוג אחד של נראות שיש לשלב בצינור הבנייה. אכלול גם כלי ניתוח סטטיים אחרים, כמו כאלה שמחפשים סודות שדלפו גם לזה. מכיוון שלא ניתן לחזות כיצד נראית התקפת שרשרת אספקה, ניטור זמן הריצה הופך להיות קריטי כך שאתה יודע בדיוק מה הקונטיינרים שלך עושים.
