סיכונים ואפשרויות תקיפה בקוברנטיס
לתקוף, להגן, לחקור ולתחקר קוברנטיס. קוברנטיס הוא ממש אי טכנולוגי עם מערכת אקולוגית מרובת אלמנטים שיש לה תנאים משלה. שמדברים על אבטחה בקוברנטיס זה אתגר מעניין הן בצד ההגנה, תקיפה ובפרט בצד התחקור.
אז מה זה קוברנטיס? מה חשוב לנו בתור אנשי אבטחה לקחת מהמערכת המורכבת והמעניינת הזאת? יש המון אלמנטים, אבני בניין, תנאים, רכיבים, תצורה, מתודלוגיות ודרכי אבטחה כאשר נוגעים בקוברנטיס. תחילה, כדאי להבין מהו קוברנטיס, את האפשרויות ובפרט איומי וסיכוני אבטחה.
מערכת הפעלה לקלאסטרים
קוברנטיס היא מערכת קוד פתוח לניהול ופריסה של יישומים על גבי קונטיינרים. בקוברנטיס ישנם אבני בניין שמספקים יחדיו מנגנונים לפריסה, ניהול ותחזוקה של היישומים וגודלם (סקייל, העלאת רכיבים חדשים ועוד). במקור קוברנטיס תוכנן לעבוד בצורה של לוסלי קאפלד (Loosely coupled) ועם האפשרות של הרחבות כדי לתמוך בעומסי עבודה (workloads) שונים, וכן עם האפשרות של הרחבות שניתנות לביצוע באמצעות דרכים שונות, בין היתר API.
בפשטות ובקצרה – קוברנטיס היא מערכת הפעלה לקלאסטרים.
טיפ: לגבי המונח Loosely coupled. מדובר על יישומים שמחולקים לפיסות קטנות ועצמאיות, וניתן לפרוס ולנהל אותם באופן דינמי, כלומר, לא ערימה אחת של טכנולוגיות עם רכיבים מונוליטים הפועלת על מכונה אחת גדולה.
תמיד אפשר להשוות את הפעולות בקוברנטיס לפעולות של מערכת הפעלה. כמו מערכת הפעלה רגילה, כך גם “קוברנטיס מאפשרת לכתוב תוכניות אשר רצות על הקלאסטר.” תוכנית שרצה על קלאסטר תהיה בדרך כלל סוג של סרביס שמקבל בקשות ושולח תשובות, למשל, Web App. במקרה זה, קוברנטיס תפעיל את היישומים, תדאג לחלק את משאבי הקלאסטר, ותחליט מי ירוץ על איזה שרת ואיזה משאב מהשרת הוא יקבל. בנוסף, תדאג להשאיר אותם בחיים ולהפעיל אותם מחדש אם אחד מהם נופל.
קצת מושגים על הרכיבים הקיימים של קוברנטיס
- Pod – יחידה ההרצה הבסיסית אשר יכולה להכיל יותר מיחידה אחת. לכל pod יש את המשאבים שכוללים משאבי מכונה למינהם.
- Service – הרכיב המנגיש את האפליקציה בתוך הקלאסטר ומחוצה לה, ואת היכולת לעשות איזון עומסים בין הפודים השונים באפליקציה.
- Namespace – מנגנון לבידוד קבוצות משאבים בתוך קלאסטר. שמות משאבים צריכים להיות ייחודיים בתוך מרחב שמות, אך לא בכל מרחבי השמות.
- ReplicaSet – אחראי על כמות הרצויה של הרצת פודים.
- Configmap – האפשרות להנגיש אפליקציות באמצעות קובצי קונפיגורציה.
- Secrets – מחזיק סיסמאות וגישה על סמך הסיקרט לטובת האפליקציה.
- שרת API – הרכיב הקדמי של control plane והרכיב היחיד שאיתו מקיימים אינטראקציה ישירה. רכיבי מערכת פנימיים, כמו גם רכיבי משתמש חיצוניים, כולם מתקשרים באמצעות אותו API.
- Controller – הבקר שנותן אינדיקציות לגבי שרת API, ולכן בודק את המצב הנוכחי של Nodes שהוא מוסמך לשלוט בהם, וקובע אם יש הבדלים, ופותר אותם במידת האפשר.
- etcd – שומר את כל התצורה של קוברנטיס והקלאסטר שלו, כמו גם עובד מול המאסטר בכדי להבין את סטטוס הרכיבים.
- Kubectl – ממשק CLI שבו נפעיל פעולות, למשל, יצירת pod כלשהו.
- kubeconfig – קובץ המשמש להגדרת גישה. למשל, כאשר נעשה בו שימוש עם כלי kubectl.
- Deployment – מגדיר איך נראית האפליקציה בשלמותה בתוך הקלאסטר, ובו יוגדרו כמות הפודים שנצטרך (יוצר ReplicaSet,איך לבצע שדרוג ועוד.
אין כמו ארכיקטורה כללית של קוברנטיס עם הרכיבים המגוונים בשביל לפשט ולהצמיד מושגים לתמונה הכללית.
התרשים נלקח מתוך האתר של Phoenixnap
אלה הם רק חלק קטן מהרכיבים הקיימים של קוברנטיס. למאמר נוסף שנוגע ברכיבים, מושגים ונקודות נוספות – רכיבים וכאלה על Kubernetes.
לפני שמתחילים להגן, לתקוף, לחקור ולתחקר קוברנטיס כדאי מאוד להבין את הארכיטקטורה, הרכיבים והאופן שבו בנויה המערכת.
סיכונים ואיומים
קוברנטיס היא אחת המערכות הפופולריות ביותר ואחד הפרויקטים הצומחים ביותר בהיסטוריה של הקוד הפתוח. בעוד שלקוברנטיס יש יתרונות רבים, הוא גם מביא אתגרי אבטחה חדשים ומעניינים. לכן, חיוני להבין את איומי וסיכוני האבטחה הקיימים בקוברנטיס על כלל הרכיבים והאפשרויות המוצעות.
רגע לפני שנבין מהם האפשרויות הספציפיות וכן את מטריצת האיומים והסיכונים של קוברנטיס, כדאי מאוד לקבל הבנה כללית לגבי מטריצת התקיפה הכללית של Azure. המטריצה יכולה להתאים גם לספקי ענן אחרים.
דיון נוסף בנושא A cloud full of attack points in LinkedIn.
סיכונים
לקוברנטיס ישנם תריסרי סיכונים ואיומים, החל מזהויות וגישה, דרך סיכונים ברמת Runtime ועד מיסקונפיגורציות, ואסור לשכוח את הרכיבים שעוטפים וכאלה שהם חלק מהאינטגרציה מול קוברנטיס. הדוח של The State of Kubernetes Security in 2022 נותן תמונה על מצב האבטחה והסיכונים.
הסיכונים והאיומים המובאים כאן הם רק חלק מינורי מתוך תריסרי סיכונים של קוברנטיס אשר קיימים בשטח.
סיקרסט
סיקרט הוא אחד מאבני הבניין של קוברנטיס לאחסון נתונים רגישים כמו סיסמאות, אישורים או טוקנים. השימוש של סיקרט בקונטיינרים מעלה מספר סוגיות קריטיות:
- סיקרט מאחסנים נתונים רגישים כמחרוזות מקודדות של Base64, אך הם אינם מוצפנים כברירת מחדל. קוברנטיס מציע הצפנה של המשאבים לאחסון, אבל גם כאן צריך להגדיר אותם. יתר על כן, האיום הקריטי על סיקרט הוא בתרחיש שבו POD והיישומים העובדים בתוכו על גבי אותו מרחב שמות יכול לגשת אליהם ולקרוא אותם.
- בקרת גישה מבוססת תפקידים המוכרת כגישת RBAC מאפשרת לווסת את הגורם שמקבל גישה למשאבים. חייב להגדיר כראוי את כללי RBAC, כך שרק לאנשים וליישומים הרלוונטיים תהיה גישה לסיקרט.RBA שלעצמו הוא סיכון רחב.
- סיקרט יחד עם Configmap הן שיטות להגדרה ולהעברת נתונים לקונטיינרים אשר רצים ופועלים. במידה וישנו סיקרט ישן או משאבי ConfigMap שאינו בשימוש, זה יכול ליצור קונפליקט וחמור מכך לגרום לדליפת נתונים. לדוגמה, במצב שבו מוחקים את היישום האחורי אך לא את הסיקרט שמכיל את סיסמאות מסד הנתונים שלך, כל POD זדוני עלול להשתמש בהן בעתיד.
קונטיינר פגיע
מכיוון שקוברנטיס היא גם פלטפורמה של הפצה והרצה של קונטיינרים על גבי Worker Nodes, היא עדיין אינה בודקת את התוכן של הקונטיינרים והאם יש בהן פגיעויות או חשיפות. לכן, יש צורך לסרוק את image לפני הפריסה בכדי להבטיח שרק image מרישומים מהימנים ללא פגיעויות קריטיות (כגון ביצוע קוד מרחוק) יפעלו בקלאסטר. סריקת Container image צריכה להיות משולבת גם במערכות CI/CD לצורך אוטומציה ואיתור פגמים מוקדם ככל האפשר.
זמן ריצה
עומסי העבודה בקוברנטיס, כלומר, אותם קוטיינרים, רצים על גבי Worker Nodes ונשלטים על ידי מערכת ההפעלה המארחת בזמן הריצה. במידה וישנה מדיניות מתירנית/פאסיבית או image עם פגיעות ברמת הקונטיינר, הם יכולים לפתוח דלתות אחוריות לכל קלאסטר. לכן, נדרשת הגנה בזמן ריצה ברמת מערכת ההפעלה כדי לאכוף אבטחה בזמן ריצה, וההגנה החשובה ביותר מפני איומי זמן ריצה ופגיעויות היא ליישם את העקרון הפחות מורשה עם גישת KSPM. גישת KSPM היא גישה שממנפת כלי אוטומציה כדי לזהות, לתקן ולהתריע על בעיות אבטחה, תצורה ותאימות באמצעות גישה הוליסטית.
תצורה שגויה והגדרות ברירת מחדל
אם יש משהו שהוא בעייתי באבטחת מידע ובפרט באבטחת מידע בענן זה הגדרות ברירת מחדל, תצורות שגויות ומיסקונפיגורציה.
ה API של קוברנטיס ומרכיביו מבוססים על קבוצה של הגדרות, משאבים ואפשרויות תצורה. לכן, קוברנטיס מציע ערכי ברירת מחדל עבור רוב פרמטרי התצורה ומנסה להסיר את הנטל של יצירת קבצי YAML ארוכים.
עם זאת, עלינו להיות זהירים לגבי סוגיות קריטיות הקשורות לתצורת קלאטסרים ומשאבים:
- תצורות ברירת המחדל של קוברנטיס אינן יעילות והן לא האפשרויות המאובטחות ביותר.
- דוגמאות או Reuse עבור משאבי קוברנטיס מועילות כדי להתחיל בעבודה, אך יש צורך לבדוק שוב אילו הגדרות משאבים יוגדרו בקלאסטר.
- נהוג לבצע שינויים במשאבי קוברנטיס באמצעות פקודות “kubectl” תוך כדי עבודה על קלאסטרים. עם זאת, במידה ולא מעדכנים את קובצי המקור, השינויים יוחלפו בפריסה הבאה, והשינויים שאינם במעקב עלולים להוביל להתנהגות אחרת.
API
הליבה של המערכת כולה, שבה כל הבקשות והתשובות הפנימיות והחיצוניות מתחברות ומתקשרות עם קוברנטיס. במידה ופורסים ומנהלים רכיבי קוברנטיס, חייבים להיות זהירים מכיוון ששרת API ורכיביו הם כלי קוד פתוח עם פגיעויות פוטנציאליות וממשיות. לכן, צריך להשתמש בגרסה היציבה האחרונה.
לצד הסיכונים המוזכרים מעלה ישנם סיכונים ואיומים נוספים יכולים להיות בין היתר, גישת רשת, ניטור הוליסטי, מדיניות RBAC, נתונים ואחסון, רכיבי אוטנטיקציה שונים, רכיבי Middleware וכן הלאה.
מטריצת איומים
אחת הדרכים לתקוף, להגן, לחקור ולתחקר קוברנטיס היא באמצעות מטריצת האיומים והסיכונים, ויש כאלה למכביר. אחת המטריצות המוכרות של קוברנטיס היא של מיקרוסופט. המטריצה מתבססת על MITRE והפריימוורק המוכר אשר מכסות את הטקטיקות, טכניקות ופרוצדורות (TTP) עם מיפוי נוף האבטחה של קוברנטיס.
- Initial access
- Execution
- Persistence
- Privilege escalation
- Defense evasion
- Credential access
- Discovery
- Lateral movement
- Impact
מידע נוסף Threat matrix for Kubernetes
כל חלק במטריצה היא בעלת ערך ויכולה לתת תמונה של נוף האבטחה בארגון, כלומר, לתוקף – מפת תקיפה, למגן – כיסוי ארגוני לחוקי זיהוי וגם להקשחות. למשל, טקטיקת הגישה הראשונית מורכבת מטכניקות המשמשות לקבלת גישה למשאבי קוברנטיס . בסביבות עם קונטיינרים, טכניקות אלה מאפשרות גישה ראשונה לקלאסטר. גישה זו יכולה להיות מושגת ישירות באמצעות שכבת ניהול בקלאסטר או, לחלופין, על ידי קבלת גישה למשאב זדוני או פגיע במערכת האקולוגית של קוברנטיס.
לצד כל האפשרויות המוזכרות במטריצת הסיכונים של קוברנטיס עדיין חסרה קטגוריה מאוד חשובה – Discover. רגע לפני שתוקפים קוברנטיס אנו צריכים להבין מי הנכסים, לחקור את הסביבה, להבין דרכי כניסה ועוד.
אז איך תוקפים קוברנטיס?
תרחיש אחד מיני רבים של תקיפה מתוך ה POD עצמו. במצב כזה, אנו צריכים להסלים הרשאות ע”י אנומרציה של יוזרים קיימים ואפילו יוזרים עצמאיים בסביבה. בדרך כלל, הפודים פועלים עם סרוויס שמוצמד אליו טוקן. לסרוויס כזה עשוי להיות הרשאות מתקדמות שתוכל לנצל כדי לעבור לפודים אחרים או להסלים הלאה אל Nodes בתוך הקלאסטר. מצב נוסף הוא כאשר ישנו פוד פגיע, ובמצב כזה כאשר ישנו פוד פגיע והוא צריך לאמת פודים אחרים אז אפשר להאזין לקרדס ומשם להסלים הרשאות ולנוע במרחב הקוברנטיס.
תרשים כללי שמתאר תקיפה בתוך POD. תחילה תוקף פונה לרכיב kubelet שמתוקף תפקידו הוא רץ על כל Node ונפרס על כל קלאסטר כך שהוא יכול ליצור קונטיינרים באמצעות קריאה אל API.כאן חשוב להדגיש כי ברירת המחדל של הזדהות היא אנונימית (–anonymous-auth).
טיפ: חיפוש של kubelet במנועי חיפוש כמו Shodan או סיוע על גבי OSINT מניב תוצאות רבות של רכיבים חשופים ופגיעים לתקיפה.
המאמר הבא יתמקד באיך לתקוף Kubelet החל משלב הגילוי ועד אימות עם טוקן.
