ב-Dell Container Storage Modules בגרסאות שלפני 1.18.0 יש פעולה שאמורה להיות מוגנת באימות ואינה מוגנת. תוקף מרוחק, בלי שם משתמש ובלי חשבון באשכול, יכול להפעיל אותה ולהסלים דרכה הרשאות. הציון הוא 10 מתוך 10, הגבוה ביותר שיש.

מה החולשה?

Dell Container Storage Modules הוא אוסף רכיבים שמחבר אשכול Kubernetes אל מערכות האחסון של Dell, ומנהל את נפחי האחסון שהמכולות באשכול משתמשות בהם.

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

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

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

מי מושפע?

הרשומה מונה את Dell Container Storage Modules בכל גרסה שלפני 1.18.0.

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

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

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

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

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

מה עושים?

1. בררו איזו גרסה מותקנת אצלכם. את מספר הגרסה אפשר לראות על התמונות של רכיבי ה-CSM שרצים באשכול.

2. עדכנו ל-1.18.0 או חדשה ממנה. זאת הגרסה הראשונה שמחוץ לטווח, והיא מכסה גם את שאר החולשות שדווחו באותו מוצר. הודעת האבטחה DSA-2026-448 של Dell מרכזת את כולן.

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

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