מה קורה כשספק תוכנה שמנהל את מערכות ה-CRM של אוניברסיטאות ומכללות בישראל נפרץ? התוקפים קיבלו גישה לא רק לנתוני הספק - אלא לנתוני כל לקוחותיו בבת אחת. וכשאיש לא הבחין, הם שהו שם ארבעה חודשים.
הסיום לא היה בשקט - אחרי ארבעה חודשים, שלחו התוקפים מייל מחשבון הספק עצמו לכל לקוחותיו, ובו הודיעו על השתלטות מלאה על התשתיות. מבחינתם, המשימה הושלמה. מבחינת המוסדות האקדמיים - הייתה זו ההודעה הראשונה שהם קיבלו על הפריצה.
שחזור האירוע - ספק תוכנה כנקודת כניסה
הקבוצה האיראנית, שנהגה לתקוף מוסדות אקדמיים ישראליים לשם גניבת מחקרים ומידע ביטחוני, זיהתה הזדמנות יעילה יותר: במקום לתקוף כל מוסד בנפרד - לתקוף את ספק התוכנה שמנהל את כולם.
🔴 וקטור הכניסה - פגיעות בממשק הניהול
הכניסה בוצעה דרך ממשק ניהול של מערכת SaaS הספק שהיה חשוף לאינטרנט עם אימות חלש. לאחר השגת גישה ראשונית, נעשה שימוש בהרשאות הניהול של הספק לגישה לסביבות הייצור של לקוחותיו.
🟠 שלב הריגול - גישה למאגרי CRM
תוך שימוש בהרשאות של הספק, הגיעו התוקפים למאגרי ה-CRM של מספר אוניברסיטאות ומכללות. הנתונים שנחשפו: פרטי סטודנטים, עובדים ופרופסורים; מידע על מחקרים ומלגות; קשרים בינלאומיים; ורשימות תורמים.
🔴 הסיום - מייל מטעם הספק
לאחר ארבעה חודשים, ביצעו התוקפים שלב חשיפה פרובוקטיבי: שלחו מייל מחשבון הדואר הלגיטימי של הספק לכל לקוחותיו, ובו הכריזו על השתלטות מלאה. זו הייתה ההודעה הראשונה שהמוסדות קיבלו על הפריצה - ישירות מהתוקפים.
הבעיות המבניות שאפשרו את התקיפה
הרשאות יתר של הספק לנתוני לקוחות
לספק הייתה גישה מלאה לכל נתוני לקוחותיו - גם לנתונים שאינם נדרשים לתפעול השוטף. עיקרון ה-Least Privilege לא יושם.
אימות חלש לממשק הניהול
ממשק ניהול חשוף לאינטרנט ללא MFA (Multi-Factor Authentication) הוא פגיעות בסיסית. במערכות SaaS המנהלות מידע של מוסדות מרובים - זהו כשל קריטי.
חוסר ניטור ודיווח
ארבעה חודשים ללא זיהוי מוכיחים שלא היה ניטור אנומליות בגישה לנתונים. גם כשהתגלה - המוסדות גילו זאת ממייל של התוקפים, לא מהספק.
לקחים - ניהול ספקי SaaS
המוסד האקדמי כלקוח - אחריות שאינה ניתנת להאצלה
כשמוסד אקדמי בוחר בספק SaaS לניהול נתוני הסטודנטים שלו, הוא אינו יכול להאציל את אחריות האבטחה לספק. הנתונים הם שלו - וגם האחריות. חוק הגנת הפרטיות הישראלי וה-GDPR מחייבים את ה-Data Controller (המוסד) לוודא שה-Data Processor (הספק) עומד ברמת אבטחה מספקת.
- דרישת MFA לכל ממשקי ניהול של הספק שיש להם גישה לנתוני המוסד
- הגבלת גישת הספק לנתונים הנדרשים לתפעול בלבד (Least Privilege)
- דרישת Audit Log שמתעד כל גישה לנתוני המוסד - ובדיקתו תקופתית
- הסכם עיבוד נתונים (DPA) עם הספק הכולל SLA לדיווח על אירועי אבטחה
- ביצוע Penetration Test שנתי על מערכות הספק - או דרישת עדות לכך
- תוכנית Incident Response שמכסה תרחיש של פריצה לספק
- גיבויים עצמאיים של נתוני המוסד שאינם תלויים בספק
השורה התחתונה
ספק SaaS המנהל נתוני לקוחות מרובים הוא "מטרה שמנה" - פריצה אחת מפיקה גישה לנתונים של כל לקוחותיו. כל מוסד שמסתמך על ספק כזה צריך לבצע Due Diligence אבטחתי ולוודא שהחוזה מחייב דרישות אבטחה בסיסיות - הגבלת הרשאות, MFA, ניטור ודיווח מהיר על אירועים.
ארבעה חודשים של גישה לנתוני סטודנטים, מחקרים ועובדים - וגילוי ממייל של התוקפים עצמם - הם כשל מוחלט שניתן היה למנוע ברמת הספק ורמת הלקוח.
מקורות
- דיווחי תקשורת על תקיפות ספקי תוכנה אקדמיים בישראל, 2024
- CERT-IL, Advisory - Academic Institution Supply Chain Attacks (2024)
- MITRE ATT&CK - T1195 (Supply Chain Compromise), T1078 (Valid Accounts)
- GDPR Article 28 - Processor obligations and Data Processing Agreements
- חוק הגנת הפרטיות (ישראל) ותקנות אבטחת מידע תשע"ז-2017