שירות TeleMessage, עד ה-5 במאי 2025, נבנה על יישום JSP שבו תוכן הזיכרון שקול פחות או יותר לקובץ קריסה מלא של התוכנית. סיסמה שנשלחה קודם לכן בחיבור HTTP נכללה בתוך התוכן הזה. הציון הוא 4.0, והחולשה נמצאת בקטלוג החולשות שמנוצלות בפועל, לאחר שנוצלה במאי 2025.
מה החולשה?
כשתוכנית קורסת, המערכת יודעת לשמור עותק של הזיכרון שלה ברגע הקריסה כדי שיהיה אפשר לברר מה קרה. לקובץ כזה קוראים core dump, והוא צילום של כל מה שהתוכנית החזיקה: מבני נתונים, ערכי משתנים, ושאריות של מה שעבר דרכה לאחרונה. הרשומה מתארת את תוכן הזיכרון של השירות הזה כשקול בערך לקובץ כזה, והסיווג הרשמי שלה הוא חשיפה של קובץ מהסוג הזה.
החלק שהופך את זה למעשי הוא מה שנמצא שם. לפי הרשומה, סיסמה שנשלחה קודם לכן בחיבור HTTP הופיעה בתוך התוכן. שני דברים נפגשים כאן. הראשון הוא ש-HTTP, בניגוד ל-HTTPS, מעביר את התוכן בלי הצפנה, כך שהסיסמה מגיעה לשרת כטקסט קריא. השני הוא שהשרת אינו שוכח אותה ברגע שסיים לטפל בבקשה. הערך נשאר מונח בזיכרון עד שמשהו ידרוס אותו, ולכן הוא עדיין שם כשנלקח העותק.
זאת נקודה ששווה לקחת מכאן גם בלי קשר למוצר. הצפנה של תעבורה מגנה על הסיסמה בדרך. היא אינה משנה את מה שקורה לה אחרי שהיא הגיעה.
וקטור הגישה כאן מקומי, בשונה מחולשות אחרות שדורגו גבוה יותר, ולכן הציון עומד על 4.0. המשמעות היא שמדובר במי שכבר יכול להגיע אל הקובץ עצמו.
מי מושפע?
הרשומה מתייחסת לשירות TeleMessage של Smarsh בגרסאות עד ה-5 במאי 2025, ואינה מפרטת גרסאות מוצר. זהו שירות ארגוני ייעודי, ורוב הקוראים בישראל אינם לקוחות שלו.
מי שהנושא כן נוגע לו הוא כל מי שמפתח או מתחזק שירותים. התבנית שמתוארת כאן, נתון רגיש שנשאר בזיכרון ומגיע לקובץ אבחון, אינה תלויה במוצר מסוים ואינה תלויה בשפה. היא נכונה לכל שרת שמקבל סיסמאות, ובמיוחד לכל שרת שעדיין מקבל אותן בלי הצפנה.
האם מנוצלת בפועל?
כן. הרשומה עצמה מציינת שהחולשה נוצלה בשטח במאי 2025, וב-1 ביולי 2025 היא נכנסה לקטלוג ה-KEV של סוכנות הסייבר האמריקאית CISA, רשימת החולשות שידוע כי תוקפים מנצלים אותן בשטח. המועד שנקבע לגופים פדרליים היה 22 ביולי 2025.
הרשומה ב-NVD פורסמה ב-28 במאי 2025. בין המקורות מופיעה כתבה של Wired שמתארת את האירוע.
מה עושים?
אם הארגון שלכם השתמש בשירות בתקופה שהרשומה מציינת, החליפו כל סיסמה ופרטי אימות שנשלחו אליו. סיסמה שהופיעה בעותק זיכרון שנחשף היא סיסמה שיש להחליף, גם בלי ראיה שמישהו קרא אותה בפועל.
בשאר המקרים, קחו מכאן שתי בדיקות. הראשונה: ודאו שאין בשירותים שלכם מסלול שמקבל פרטי אימות דרך HTTP. הפניה אוטומטית ל-HTTPS אינה מספיקה, כי הבקשה הראשונה כבר יצאה בלי הצפנה.
השנייה נוגעת לקבצי אבחון. קבצי dump וקבצי קריסה הם מידע רגיש לכל דבר. אל תשאירו אותם בתיקייה שהשרת מגיש ממנה, אל תצרפו אותם לכרטיס תקלה בלי לבדוק מה יש בהם, והגדירו להם מחיקה אוטומטית אחרי שסיימתם את הבירור.
ולבסוף, אם אתם יכולים להשפיע על הקוד: הימנעו מהחזקת סיסמאות במשתנים רגילים למשך זמן ארוך יותר מהנדרש לטיפול בבקשה. ככל שהערך חי פחות זמן בזיכרון, כך קטן הסיכוי שהוא ייתפס בעותק כזה.