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

מה החולשה?

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

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

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

מי מושפע?

הרשומה מציינת את NetScaler ADC ואת NetScaler Gateway בענף 14.1 עד בנייה 73.32, ובענף 13.1 עד בנייה 63.21. שני המוצרים באותם טווחים.

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

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

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

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

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

מה עושים?

בדקו את מספר הבנייה שרץ אצלכם מול הטווחים שברשומה, 14.1 עד 73.32 ו-13.1 עד 63.21. בנייה שנמצאת בתוך הטווח מחייבת שדרוג.

הבניות שסוגרות את החולשה מתפרסמות במסמך של Citrix. זהו המקור הרשמי לגרסה המתקנת, ו-NVD עצמה אינה נוקבת בה.

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

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