ב- 29 ביולי פרסמה Broadcom עדכון חירום לפגיעות קריטית ב- VMware vCenter. חמישה ימים לאחר מכן, ב- 3 באוגוסט, החלו שרתים פרוצים ליצור קשר עם תשתית התוקפים. ב- 4 באוגוסט נצפו 151 כתובות IP חדשות של קורבנות. ב- 5 באוגוסט המספר טיפס ל- 343. עד 7 באוגוסט נספרו 361 כתובות ב- 47 מדינות, כשגרמניה, ארצות הברית, טורקיה, איראן וצרפת מהוות יחד יותר ממחצית מהפריצות.
הפגיעות עצמה
פגיעות CVE-2026-59310 היא פגיעות Directory Traversal קריטית ברכיב Syslog Server של vCenter. היא מאפשרת לתוקף לא מאומת, שברשותו גישה רשתית לרכיב הפגיע, להריץ קוד שרירותי על השרת. אין צורך בשם משתמש. אין צורך בסיסמה.
פגיעויות ממשפחה זו נובעות מכך שרכיב תוכנה מקבל נתיב קובץ מקלט חיצוני מבלי לוודא שהנתיב נשאר בגבולות התיקייה המיועדת לו. התוצאה היא גישה לאזורים במערכת הקבצים שהיו אמורים להיות מחוץ לתחום.
למה דווקא vCenter הופך את זה לחמור
vCenter היא תוכנת הניהול המרכזית של תשתית הווירטואליזציה בארגון: שליטה, ניטור והגדרה של מכונות וירטואליות, שרתי ESXi, קונפיגורציות והרשאות גישה. זו אינה עוד מערכת ברשת. זו המערכת ששולטת בכל שאר המערכות.
השתלטות על vCenter פירושה בפועל אחיזה בכל חוות השרתים הווירטואלית בבת אחת — כל מכונה וירטואלית, כל שרת מארח וכל הגדרת הרשאות. מכאן, קצרה מאד הדרך לפעולה הרסנית בקנה מידה ארגוני.
מה עשו התוקפים לאחר הפריצה
על השרתים שנפרצו הותקן reverse_ssh – כלי קוד פתוח המייצר אחיזה קבועה במערכת וערוץ שליטה ובקרה יוצא. הכיוון היוצא הוא לב העניין: תעבורה שיוצאת מהשרת אל השרת של התוקף עוקפת בקלות רבה יותר חומות אש והגנות רשת שמתמקדות בסינון תעבורה נכנסת.
את מתקפת הסייבר חשפה חברת DFIR QUIRSO. החוקרים פרסמו חוק YARA גנרי לזיהוי הבינארי של לקוח reverse_ssh, תוך אזהרה מפורשת שגם שימוש לגיטימי בכלי יפעיל את ההתראה. הערכתם היא שתוקף APT עומד מאחורי הפעילות, אך הם מציינים במפורש שאין בידיהם ראיות לכך. מדדי פריצה ספציפיים לא פורסמו בשל תיאום מתמשך עם רשויות אכיפת החוק והובטח דוח המשך מפורט.
מצד הספק, המסר חד: אין מעקף ואין פתרון עוקף. הדרך היחידה היא עדכון — vCenter 9.1 לגרסה 9.1.0.0300, vCenter 9.0 לגרסה 9.0.2.0100 ו- vCenter 8.0 לגרסאות 8.0 U3k או 8.0 U2f. אנשי אתר BleepingComputer פנו ל- Broadcom לקבלת תגובה. עד מועד הפרסום לא התקבלה תשובה.
הסיכון לארגונים: חלון התיקון מתכווץ
המספר החשוב כאן אינו 361. הוא חמישה. חמישה ימים חלפו בין פרסום עדכון החירום לבין תחילת הניצול בפועל, ותוך ארבעה ימים נוספים קפץ מספר הקורבנות מאפס ל- 361. מרגע שפגיעות קריטית מתפרסמת, הטלאי עצמו הופך למפת דרכים עבור התוקפים.
לכך מתלווה סיכון שני, בסיסי לא פחות: ממשק ניהול תשתית שאמור להיות סגור לחלוטין נגיש מספיק כדי שתוקף לא מאומת יגיע אליו. שרתים ב- 47 מדינות מלמדים שזו אינה תקלה נקודתית אלא דפוס.
הסיכון השלישי הוא ההתמדה. reverse_ssh נשאר על השרת גם לאחר העדכון. ארגון שיתקין את הטלאי בלי לבדוק אם כבר נפרץ עלול להישאר עם דלת אחורית פתוחה במערכת הקריטית ביותר שלו, מתוך תחושה מוטעית שהטיפול הושלם.
איך סוגרת 010 את הפער
עדכוני תוכנה ואבטחה הם המענה הישיר. במקרה כזה, ניהול טלאים אינו משימה חודשית אלא תגובה מדודה בשעות. שירות ניהול העדכונים של 010 מוודא שעדכוני חירום למערכות תשתית קריטיות מותקנים בתוך חלון הזמן הרלוונטי, לא אחריו.
מודיעין סייבר מספק את ההתראה המוקדמת — זיהוי פגיעויות שכבר נמצאות בניצול פעיל, כדי לתעדף אותן מעל עשרות עדכונים אחרים שממתינים בתור. ההבדל בין "קריטי" ל"מנוצל כרגע בשטח" הוא ההבדל שקובע מה מתקנים הלילה.
סקר סיכונים נדרש כדי למפות את השאלה שקדמה לכל: אילו ממשקי ניהול תשתית חשופים בארגון, למי ומאיפה. הפרדת רשת הניהול מיתר הרשת ומהאינטרנט היא הבקרה שהופכת פגיעות קריטית לפגיעות שקשה יותר לנצל.
SIEM/SOC נותן את שתי התשובות הנותרות: זיהוי תעבורה יוצאת חריגה משרת ניהול — שרת vCenter שפותח ערוץ יוצא קבוע ליעד לא מוכר הוא חריגה מובהקת — וכן חיפוש יזום אחר סימני פריצה קיימים ולא רק המתנה להתראה.
לבסוף, גיבוי והמשכיות עסקית יחד עם הגנה אקטיבית מכופר הם רשת הביטחון. גיבוי שנשמר בתוך אותה סביבת וירטואליזציה שנפרצה אינו גיבוי. תוקף ששולט ב- vCenter שולט גם בו.
השורה התחתונה: פגיעות שתוקנה אינה פגיעות שנסגרה. היא נסגרת רק כשהטלאי הותקן, החשיפה צומצמה ומישהו בדק שלא נכנסו קודם.
למקור הידיעה ולקריאה נוספת לחצו כאן
