לא כל מה שמגיע בהודעת דואר הוא הטקסט שאתם רואים. הודעה נושאת גם שדות כותרת, שורות טכניות שמספרות מי שלח, מתי, ומה ההודעה מכילה, והזמנה ליומן מוסיפה שדות משלה. לפי הרשומה, Zimbra Collaboration לא בדקה כראוי את שדה הכותרת של ההזמנה, וקוד שהוטמע בו רץ בסשן של מי שהציג את ההודעה בממשק הקלאסי. הציון הוא 6.1, וזה אחד המקרים שבהם המספר אומר פחות מהעובדה שהיא כבר נמצאת בקטלוג המנוצלות של CISA.
מה החולשה?
כדי להציג הזמנה לפגישה, ממשק הדואר לוקח את השדות הטכניים שמתארים אותה ומצייר מהם את הכרטיס שאתם רואים על המסך: מי מזמין, מתי, מה הנושא. הציור הזה נעשה כ-HTML, כי ככה נראה כל דבר בממשק ווב.
המשמעות היא ששדה שהגיע מבחוץ הופך לחלק מהעמוד שהדפדפן מרכיב. אם השדה מגיע כמו שהוא, בלי בדיקה, אפשר לשתול בתוכו לא טקסט אלא קוד, והדפדפן לא יראה הבדל בין השניים. הוא יריץ את מה שקיבל. לתבנית הזאת קוראים XSS.
הרשומה מדייקת בשלושה דברים. את הכשל היא תולה בבדיקת הקלט של כותרת היומן. את ההפעלה היא תולה ברגע שבו הקורבן מציג את ההודעה בממשק הקלאסי. ואת התוצאה היא מנסחת כהרצה בהקשר הסשן של הקורבן, כלומר הקוד פועל בשם מי שמחובר.
שימו לב שהציון כאן אינו גבוה, 6.1, והסיבה היא שהחולשה מסומנת כפגיעה מוגבלת בסודיות ובשלמות ודורשת שמשתמש יפתח את ההודעה. מה שהציון אינו מספר הוא מה קורה כששרת הדואר של ארגון שלם עובד בממשק הזה.
מי מושפע?
הרשומה מסמנת את Zimbra Collaboration בגרסה 9.0.0, ובטווח שמ-10.0.0 ועד לפני 10.0.7. הגרסה הסוגרת בענף 10 היא 10.0.7. לענף 9 הרשומה מפנה להערות השחרור של P39, כלומר התיקון שם הוא רמת טלאי ולא מספר גרסה חדש.
התנאי השני הוא הממשק. הרשומה מדברת על ממשק הדואר הקלאסי, ולא על כל דרך אחרת לקרוא את אותה תיבה. Zimbra יושבת בארגונים שבחרו להריץ שרת דואר משלהם במקום לעבור לחבילת ענן, ובהם התיבות של כל העובדים נמצאות תחת אותה החלטה.
האם מנוצלת בפועל?
כן. ב-19 במאי 2025 נוספה החולשה לקטלוג ה-KEV של סוכנות הסייבר האמריקאית CISA, רשימת החולשות שידוע שתוקפים משתמשים בהן בפועל, והמועד לתיקון בגופים הפדרליים האמריקאיים נקבע ל-9 ביוני 2025.
הרשומה מצרפת גם פרסום מחקר של ESET בשם Operation RoundPress, ומשם מגיע הקישור בין החולשה הזאת לפעילות בשטח. הייחוס הוא של ESET ולא של הרשומה עצמה.
והנה הפער שכדאי לראות: הרשומה פורסמה ב-NVD באוגוסט 2024, והכניסה לקטלוג הגיעה תשעה חודשים אחריה. כל אותו זמן התיקון כבר היה קיים.
מה עושים?
1. בררו באיזה ענף אתם. בענף 10 עדכנו ל-10.0.7 או מאוחר יותר, לפי הערות השחרור של 10.0.7. בענף 9 התיקון הוא רמת הטלאי, לפי הערות השחרור של 9.0.0 P39.
2. אם אתם על 9.0.0, בדקו את רמת הטלאי ולא רק את מספר הגרסה. שרת שמדווח 9.0.0 יכול להיות מתוקן או לא מתוקן, ומספר הגרסה לבדו לא יגיד לכם.
3. אם אי אפשר לעדכן מיד, הרשומה תולה את ההפעלה בממשק הקלאסי. הרחקת המשתמשים ממנו מסירה את התנאי שהרשומה נוקבת בו, גם אם אינה מתקנת את הבאג עצמו.
4. אחרי העדכון עברו על התיבות. הקוד רץ בשם המשתמש המחובר, ולכן כל שינוי שנעשה דרכו נרשם כפעולה תקינה שלו, ורק מי שמחפש אותו ימצא אותו.