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

מה החולשה?

הרכיב CSM Authorization הוא זה שאמור להכריע מי מורשה לעשות מה מול מערכות האחסון שהאשכול מחובר אליהן. הוא שומר הסף.

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

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

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

מי מושפע?

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

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

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

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

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

מה עושים?

1. בדקו אם מותקן אצלכם רכיב CSM Authorization ובאיזו גרסה. אם הגרסה מתחת ל-1.18.0, התייחסו אליו כחשוף.

2. עדכנו ל-1.18.0 ומעלה. הודעת האבטחה DSA-2026-448 של Dell היא המסמך שמכסה את החולשה הזאת ואת האחרות שתוקנו באותה גרסה.

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

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