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

מה החולשה?

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

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

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

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

מי מושפע?

הרשומה נוקבת בשני קווי מוצר: Sitecore CMS בגרסאות 7.0 עד 7.2 ועד בכלל, ו-Sitecore Experience Platform בגרסאות 7.5 עד 8.2 ועד בכלל.

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

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

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

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

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

מה עושים?

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

2. שדרגו, ואל תחפשו תיקון נקודתי. הרשומה אינה נוקבת במספר גרסה שסוגר את החולשה, היא מפרטת טווחים חשופים. המסקנה המעשית היא לעלות מקו 7.x או 8.x אל גרסה נתמכת, דרך עמוד ההורדות של Sitecore.

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

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

5. את הפירוק הטכני של החולשה, כולל תיאור המודול והפרמטר, פרסמה Synacktiv בהודעת האבטחה שלה.