חולשת אבטחה ב־Microsoft SharePoint Server נוספה לרשימת KEV של CISA לאחר שנצפתה מנוצלת בפועל. החולשה, CVE-2026-65660, מאפשרת לתוקף שכבר מחזיק בהרשאה ברמה נמוכה להריץ קוד דרך הרשת במערכות פגיעות.
הדירוג הוא 8.8 מתוך 10, אבל המספר לבדו אינו הסיבה לדחיפות. הכניסה לרשימת Known Exploited Vulnerabilities מעידה שלא מדובר עוד בתרחיש תיאורטי בלבד. ארגונים שמפעילים SharePoint מקומי צריכים לבדוק גרסה ולהשלים את עדכון האבטחה, גם אם השרת אינו חשוף ישירות לאינטרנט.
אילו מערכות מושפעות?
לפי הודעת האבטחה של Microsoft, החולשה משפיעה על SharePoint Enterprise Server 2016, SharePoint Server 2019 ו־SharePoint Server Subscription Edition בגרסאות שקדמו לעדכונים הרלוונטיים.
חשוב להבחין בין SharePoint Server מקומי לבין SharePoint Online במסגרת Microsoft 365. ההתרעה מתייחסת לשרתים שמותקנים ומנוהלים בידי הארגון. בשירות הענן Microsoft מנהלת את התשתית והעדכונים, ולכן מנהל Microsoft 365 אינו אמור להתקין את תיקוני השרת האלה בעצמו.
מה התוקף צריך כדי לנצל את החולשה?
זהו ליקוי Code Injection. התרחיש המתואר דורש חשבון מאומת בעל הרשאה נמוכה, אך לאחר ניצול מוצלח התוקף עלול להריץ קוד דרך הרשת ולפגוע בסודיות, בשלמות ובזמינות המערכת.
הדרישה לחשבון אינה הופכת את הסיכון לזניח. חשבונות משתמשים נגנבים בפישינג, בסיסמאות חוזרות, בנוזקות לגניבת מידע ובמתקפות MFA. בסביבה שבה SharePoint מחובר ל־Active Directory, חשבון אחד שנפרץ עלול להפוך לנקודת כניסה לתשתית רחבה יותר.
מה צריך לעשות עכשיו?
- מפו את השרתים: ודאו אילו גרסאות SharePoint פועלות בארגון, כולל שרתי פיתוח, בדיקות והתאוששות מאסון.
- בדקו את מספר ה־Build: אל תסתפקו בכך שמופיע עדכון Windows מוצלח. בדקו שהעדכון המתאים לגרסת SharePoint אכן הותקן.
- התקינו את תיקוני Microsoft: עבור SharePoint 2019 פורסם KB5002894, עבור Subscription Edition פורסם KB5002893, ול־SharePoint 2016 פורסם KB5002905.
- השלימו את שלבי התחזוקה: בעדכוני SharePoint לעיתים נדרש להפעיל את אשף התצורה או את PSConfig בהתאם להנחיות Microsoft. התקנת הקובץ לבדה אינה תמיד מסיימת את התהליך.
- בדקו סימני חדירה: עברו על יומני IIS, יצירת תהליכים חריגה, קבצים חדשים בתיקיות היישום ושינויים בלתי מוסברים בהרשאות ובחשבונות שירות.
לא מספיק רק לחסום את השרת מהאינטרנט
צמצום חשיפה חיצונית הוא שכבת הגנה חשובה, אך החולשה דורשת חשבון מאומת ויכולה להיות מנוצלת גם מתוך הרשת או באמצעות תחנה שכבר נפרצה. לכן VPN, Reverse Proxy או Allowlist אינם תחליף לעדכון.
גם מוצר EDR אינו תיקון לחולשה. הוא עשוי לזהות התנהגות חריגה לאחר הניצול, אך אינו מבטל את נקודת הכניסה. הגישה הנכונה היא שילוב של תיקון, ניטור, הרשאות מינימליות והפרדת שרתים.
האם צריך להחליף מפתחות או סיסמאות?
אם אין סימן לניצול, יש לפעול לפי נוהל העדכון והבדיקה של הארגון. אם נמצאו אינדיקציות לחדירה, אין להסתפק בהחלפת סיסמה אחת. צריך להתייחס לאירוע כאירוע אבטחה: לשמר ראיות, לבודד מערכות לפי הצורך, לבדוק חשבונות שירות, אסימונים והרשאות, ולבחון אם נוצרה התמדה במערכת.
לפני מחיקה או בנייה מחדש של שרת, מומלץ לשמור Logs ותמונות דיסק בהתאם ליכולת הארגון. ניקוי מהיר ללא תיעוד עלול למחוק את היכולת להבין מה קרה ולאילו מערכות נוספות התוקף הגיע.
איך למנוע את המרוץ הבא?
SharePoint מקומי הוא מערכת עסקית קריטית שלעתים נשארת מחוץ למחזור העדכונים הרגיל בגלל חשש משיבושים. דווקא משום כך צריך סביבת בדיקות, חלון תחזוקה מוגדר ורשימת Build מאושרת.
מניסיונו של אריאל מרום בתחום ה־IT והסייבר, החשיבות אינה רק בקבלת התראה אלא ביכולת לקשר אותה במהירות לנכס אמיתי בארגון. זהו גם ההיגיון שמאחורי ניטור רציף ושירותי SOC כמו MCS: לזהות מה רלוונטי לסביבה, לתעדף ולוודא שהטיפול הושלם.
לקריאה נוספת: Microsoft מציגה SOC בעידן סוכני AI ו־זיהוי כללי העברה חשודים ב־Microsoft 365.
קרדיט תמונה: צילום: Danial Igdery / Unsplash, ברישיון Unsplash. מקור: https://unsplash.com/photos/FCHlYvR5gJI
