ביום רביעי, 11 בנובמבר, בסביבות 17:47 לפי שעון UTC (19:47 בישראל), החלו להופיע התקנות לא מוכרות של ScreenConnect, כלי התמיכה מרחוק של ConnectWise, במחשבים של ארגונים שמקבלים שירותי IT מספק חיצוני (MSP). לפי חברת האבטחה Huntress, לפחות 288 מחשבים ב‑ 48 ארגונים מבין לקוחותיה נפגעו בתוך 90 דקות, כשליש מהם כבר בעשר הדקות הראשונות. התוקף לא חדר לכל ארגון בנפרד. הוא השתמש בלוחות הבקרה בענן של ספקי השירות.
90 דקות, 288 מחשבים
דרך לוח הבקרה של ScreenConnect, טכנאי יכול לשלוח פקודה אחת לקבוצה שלמה של מחשבים מנוהלים. זו היכולת שהתוקף ניצל. לפי המחקר של Huntress, נראה שהפקודות רצו כ‑ SYSTEM, חשבון המערכת של Windows, שההרשאות שלו גבוהות מאלו של כל משתמש, כולל מנהל. כל פקודה בדקה אם רכיב הגישה של ScreenConnect – התוכנה שמחברת את המחשב המנוהל לשרת – כבר מותקן, הורידה מתקין שבשליטת התוקף והתקינה אותו בשקט. העותק החדש מתחבר לשרת של התוקף, לא לזה של הספק. התוצאה: שליטה מרחוק במחשב, שממשיכה לפעול גם בלי לוח הבקרה של הספק.
עם רכיב הגישה הזדוני הגיעה ערכת כלים בשם SCKit, 16 קבצים בסך הכול. חלק מהם נועדו להבטיח שהתוקף יישאר, למשל רכיב גישה זדוני נוסף. אחרים נועדו להסתיר, למשל החרגות שנוספו ל‑ Microsoft Defender. החלק האחרון, שמופעל בין השאר דרך משימה מתוזמנת בשם TrapWatch, נועד להחליף: לפי Huntress, הוא עוצר את רכיב הגישה הלגיטימי ותופס את מקומו בחיבור לשרת של הספק, כך שהמחשב ממשיך להיראות תקין. הערכה מגיעה מוצפנת. כל מחשב נגוע שולח לשרת של התוקף את המזהה הייחודי שלו ומקבל בתמורה את נתוני הפענוח.
הדלת, ככל הנראה: הרחבה של צד שלישי
ConnectWise כיבתה חמש הרחבות של צד שלישי בכ‑ 400 סביבות של שותפים, כלומר ספקי שירות שמשתמשים ב‑ ScreenConnect. זה צעד מניעה בלבד: עצם ההתקנה, לדבריה, אינו מעיד על פריצה. שותפים שמריצים את השרת בעצמם צריכים לכבות את ההרחבות לבד. הודעת האבטחה של החברה פורסמה ב‑ 22:45 UTC. בעדכון האחרון שלה, מ‑ 02:45 UTC ב‑ 12 בנובמבר, החברה מצביעה על ההרחבות ולא על ScreenConnect: לא נמצאה חולשה בכלי ולא פריצה לתשתית שלה. ההערכה הזו עדיין נבדקת.
השאלה שנותרה פתוחה הייתה איך הושגה הגישה ללוחות. Huntress מסרה ל‑ BleepingComputer ול‑ The Hacker News שהנתונים שבידיה מצביעים על פרטי התחברות שנגנבו או על חטיפת חיבורים פעילים של משתמשי הלוח, בלי שהיה ברור איך הושגה הגישה. בעדכון למחקר, שפורסם ב‑ 04:34 UTC ב‑ 12 בנובמבר, היא הציעה הסבר אחר: הפעילות נראית קשורה להרחבה אחת מהחמש, RMM+. לדבריה, הפקודות הגיעו למחשבים בכמה סביבות בתוך דקות, בלי התחברות מתאימה ביומנים.
RMM+ היא גשר בין ScreenConnect לבין מערכת ניהול מרחוק אחרת: החיבורים מופעלים מתוך המערכת ההיא, לא מלוח הבקרה. לשם כך יש להרחבה ממשק משלה, עם בדיקת כניסה משלה: מפתח אחד שנשמר בהגדרות שלה. הבדיקה הזו אינה עוברת דרך חשבונות המשתמשים, דרך ההרשאות לפי תפקיד או דרך האימות הרב‑שלבי של ScreenConnect. לפי ConnectWise, הגישה לממשק מוגנת בסיסמה שהשותף קובע בהתקנה. ככל הנראה מדובר באותו מפתח. אלא שלפי Huntress, בגרסאות 1.0.31 ו‑ 1.0.32 המפתח היה ריק כברירת מחדל. אם איש לא הגדיר אותו, בקשה עם מפתח ריק עברה את הבדיקה ויכלה להריץ פקודות.
אם ההסבר יאושר, גם לוח בקרה שנעול בסיסמה ובאימות רב‑שלבי לא היה מגן כאן: ההרחבה פתחה לצידו דלת שאינה עוברת דרך המנעול. Huntress מעריכה שברוב המקרים לא התוקף התקין את ההרחבה. בדרך כלל היא הותקנה לצורך פרויקט ונשארה מותקנת גם אחריו.
התפשטות שתוכננה, אך לא נצפתה בפועל
Huntress מכנה את הערכה "תולעת". החלק המסוכן בקוד מכוון לרגע שבו טכנאי פותח חיבור למחשב נגוע, כדי לבדוק מה קרה בו. לפי ניתוח הקוד, נראה שהתכנון הוא כזה:
- קובץ עובר מהמחשב הנגוע אל תחנת העבודה של הטכנאי ומוריד אליה ערכה נוספת.
- הערכה גונבת מהדפדפן את עוגיית ה‑ .aspxauth, האישור שמעיד שהטכנאי כבר מחובר ללוח הבקרה.
- בעזרת האישור הקוד נכנס ללוח בשם הטכנאי ומאתר את כל המחשבים שהוא מגיע אליהם.
- קובץ שמועלה לארגז הכלים המשותף של הלוח רץ בהרשאות SYSTEM בכל המחשבים האלו. כעבור כדקה הוא נמחק מארגז הכלים.
לפי Huntress, ניסיונות ההשתלטות על לוח הבקרה נכשלו בכל היומנים שבדקה עד כה. היא גם לא ראתה עד כה מעבר מוצלח לתחנה של טכנאי. ConnectWise בודקת דיווחים על פגיעה אפשרית בתחנות כאלו. למרות זאת, ההוראה המעשית ברורה: מחשב חשוד לא פותחים דרך ScreenConnect. בודקים אותו בכלי נפרד, כמו כלי ה‑ EDR או ערוץ ניהול אחר.
ייתכן גם שהאירוע התחיל לפני ש‑ Huntress הבחינה בו. לפי מה שמסרה ל‑ BleepingComputer ול‑ The Hacker News, התוקף ממספר ברצף את הספקים שפרץ, אבל המספרים שנצפו אינם מתחילים בראש הרצף. ההמלצה שלה: לבדוק את היסטוריית הפקודות של הלוח גם בלי התראה.
הסיכון לארגון שלכם
ארגון שהמחשבים שלו מנוהלים בידי ספק IT חיצוני נותן לספק מפתח למערכות שלו. כאן, לפי הספירה המוקדמת של Huntress, לפחות שישה ספקים שנפרצו הספיקו כדי להגיע לעשרות ארגונים. המשמעות המעשית היא גישה מרחוק עם רכיבים שרצים כ‑ SYSTEM, בערוץ שהספק אינו רואה, שעשויה להישאר גם אחרי ניקוי הלוח. Huntress אף ראתה מחשבים שנדבקו מחדש זמן קצר אחרי שהוסר הבידוד שלהם. מה נעשה בגישה הזו לא פורסם. המקורות אינם מפרטים היכן נמצאים הארגונים שנפגעו. ישראל לא הוזכרה באף אחד מהם.
ארגון שאינו יודע אילו הרחבות מותקנות בלוח הבקרה של הספק שלו אינו יכול להעריך את הסיכון הזה. כדאי גם לברר מראש מול הספק באיזה כלי ייבדק מחשב חשוד, אם לא דרך ScreenConnect.
בישראל, ספקי IT הם יעד ידוע. במבזק על מתקפה איראנית נגד ספקי IT ישראליים תואר כאן מחקר של Check Point על קבוצה שמזוהה עם משרד המודיעין האיראני ומכוונת לארגונים בישראל, בעיקר לספקי IT ולגופי ממשל. לפי The Hacker News, שרשרת התקיפה שתועדה שם מתחילה במנגנון העדכונים של SysAid, כלי לניהול שירותי IT. אין קשר ידוע בין הפעילות ההיא לאירוע הנוכחי. המשותף: ספק IT כדרך אל הלקוחות שלו. לפי Check Point, הקבוצה עברה מספק IT שנפרץ לספק נוסף. רק ממנו הגיעה לארגון היעד.
תקנה 15 לתקנות הגנת הפרטיות (אבטחת מידע) מחייבת לבחון את הסיכונים בהתקשרות עם גורם חיצוני שמקבל גישה למאגר מידע. כפי שפורסם כאן במבזק על הגישה של Qubole לחשבונות AWS, ההסכם עם ספק כזה צריך לפרט לאילו מערכות הוא רשאי לגשת. סביר לכלול באותה בחינה גם את השאלה איך בדיוק הוא ניגש: באיזה כלי ועם אילו הרחבות.
010 אבטחת מידע
נתיב החדירה הראשוני עדיין לא נקבע רשמית. ההמלצות שלהלן נשענות על מה שפורסם: לוחות בקרה של ספקי שירות, הרחבה של צד שלישי שעוקפת את מנגנוני הכניסה, רכיבי גישה זדוניים והחרגות שנוספו לכלי ההגנה. השאלות האלו חלות על כל ספק שמחזיק גישה מרחוק לארגון, כולל ספקי אבטחה.
סקר סיכונים. סקר סיכונים ממפה אילו ספקים מחזיקים גישה מרחוק, לאילו מערכות ובאיזה כלי. הוא יכול לכלול שאלות ישירות לספק: אילו הרחבות פעילות בכלי הגישה שלו, מי אחראי עליהן ואיך מוגנת הגישה לממשקים שלהן. ההערכה של Huntress, שהרחבות כאלו נשארות לרוב מותקנות אחרי הפרויקט, מראה למה כדאי לשאול. התשובות תלויות בשקיפות של הספק. הסקר אינו בודק את קוד ההרחבות ואינו מאתר פגם כמו מפתח ריק.
עדכוני תוכנה ואבטחה. לפי Huntress, גם הגרסאות העדכניות ביותר של ScreenConnect נפגעו. הפגם היה בגרסאות מסוימות של ההרחבה, לכן עדכון הכלי הראשי לבדו אינו התשובה כאן. ההרחבות מותקנות בלוח הבקרה של הספק, או בשרת של ארגון שמריץ ScreenConnect בעצמו. רשימת הרכיבים שמעדכנים צריכה לכלול גם אותן ואת ההגדרות שלהן, כמו מפתח גישה שלא הוגדר. הרחבה שאין בה צורך עדיף להסיר. ConnectWise מבקשת לא להפעיל מחדש את ההרחבות שכובו עד להנחיה נוספת. לא פורסם אם קיימת גרסה מתוקנת של RMM+.
SIEM/SOC. ההתראות שהובילו את Huntress לאירוע הגיעו מהמחשבים, כשרכיבי גישה לא מוכרים הופיעו בהם. ניטור רציף נועד להציף סימנים כמו התקנה של כלי גישה מרחוק חדש, שינוי בהחרגות של Defender, משימה מתוזמנת חדשה או פקודה זהה שרצה על עשרות מחשבים בתוך דקות. התנאי הוא שהיומנים נאספים לניטור. יומני לוח הבקרה נמצאים אצל הספק ומגיעים לניטור של הארגון רק אם הספק מעביר אותם. מכיוון ש‑ ScreenConnect הינו תוכנה לגיטימית, ההבחנה בין העותק של הספק לעותק של התוקף נשענת על מזהה הרכיב, על השרת שאליו הוא מתחבר ועל סימנים במחשב עצמו, כמו התיקייה RelayTrap או המשימה TrapWatch. בנוסף, לפי Huntress לא נמצאה התחברות שתואמת את הפקודות. לכן זיהוי שנשען רק על כניסות חריגות עלול להחמיץ אירוע כזה.
מודיעין סייבר. Huntress, ConnectWise ו‑ Sophos פרסמו סימנים לזיהוי, ביניהם כתובות IP, דומיינים ומזהים של רכיבי גישה זדוניים. שילוב שלהם בכלי הניטור מאפשר לבדוק אם הם מופיעים בארגון. לפי Huntress, גיבובי קבצים הם סימן חלש כאן, כי הסקריפטים נבנים מחדש וקובץ המלכודת מהודר בנפרד בכל מחשב. ConnectWise מזכירה שהרשימה חלקית ועוד תשתנה: היעדר התאמה אינו הוכחה שהארגון נקי.
מודעות עובדים לסייבר. אף מקור לא דיווח שהמתקפה הזו החלה בהנדסה חברתית. ההתקנה עצמה הייתה שקטה. הקשר הישיר הוא לצוותי ה‑ IT: כל טכנאי, בארגון ואצל הספק, צריך להכיר את הכלל שלא פותחים דרך ScreenConnect מחשב חשוד. ConnectWise ממליצה לשותפים גם לאמת בערוץ מוכר פניות תמיכה שלא ציפו להן.
ארבעה שירותים אינם נגזרים מהאירוע כפי שפורסם: סינון דוא"ל, הגנה אקטיבית מכופרה, גיבוי והמשכיות עסקית ומניעת דלף מידע (DLP). באירוע הזה, אף מקור לא דיווח על ערוץ דוא"ל, על הצפנה, על השבתה או על גניבת מידע עסקי. הגניבה שתוארה היא של עוגיות התחברות מהדפדפן ושל אסימוני הזדהות.
למקור הידיעה ולקריאה נוספת לחצו כאן
