ב-Incus, מערכת לניהול מכולות ומכונות וירטואליות על שרת, כל פעולה שהשרת מבצע מקבלת רשומה שאפשר לשאול עליה דרך ממשק ה-API. לפי הרשומה, השאילתה הזאת אינה בודקת לאיזה פרויקט הפעולה שייכת, ולכן לקוח שהוגבל לפרויקט אחד יכול לקרוא פעולות של פרויקטים שאינם שלו. הציון הוא 7.0 מתוך 10 בסולם CVSS 4.0, והתיקון כבר יצא.

מה החולשה?

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

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

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

יש גם תנאי מקדים, והרשומה מסמנת אותו במפורש: התוקף צריך להכיר את המזהה של הפעולה שהוא רוצה לקרוא. המזהים הם מזהי UUID ואינם ניחושים סבירים, וזה מה שמונע מהחולשה להיות סריקה פשוטה של כל מה שעל השרת. בסולם CVSS 4.0 הפרופיל ממוקד בהתאם: פגיעה גבוהה בסודיות, אפס בשלמות ואפס בזמינות. התוקף קורא, הוא אינו משנה.

מי מושפע?

הרשומה מגדירה שלושה טווחים, ושווה לקרוא אותם בדיוק: כל גרסה לפני 6.0.7, הטווח מ-6.1.0 ועד לפני 7.0.2, והטווח מ-7.1.0 ועד לפני 7.5.0. שלוש גרסאות התיקון הן אלה, לפי הענף שאתם יושבים עליו.

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

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

האם מנוצלת בפועל?

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

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

מה עושים?

1. בדקו את הגרסה המותקנת והשוו לשלושת הטווחים. בענף 6.0 עדכנו ל-6.0.7, בענף שמתחיל ב-6.1.0 עדכנו ל-7.0.2, ומ-7.1.0 ואילך עדכנו ל-7.5.0.
2. אחרי העדכון החליפו את ה-token-ים לצירוף לקוחות שהיו תקפים בתקופה שבה הייתם בטווח. זה הפריט שהרשומה מונה שהחלפתו היא ההבדל בין חשיפה שנסגרה לחשיפה שנשארה פתוחה.
3. החליפו גם סודות סביבה שהועברו לפעולות באותה תקופה, למשל פרטי אימות שהוזרקו לפקודה שהרצתם בתוך מכולה. אם הועבר שם מפתח, הניחו שאפשר שנקרא.
4. אם יש לכם לקוחות עם תעודות מוגבלות שאינם זקוקים להן כרגע, שקלו להסיר אותן עד לעדכון. הודעת האבטחה של Incus מרכזת את הפרטים ואת היקף התיקון.