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

מה החולשה?

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

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

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

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

מי מושפע?

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

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

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

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

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

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

מה עושים?

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