הסיפור של SMB ו‑MS17‑010: למה WannaCry הצליח להתפשט כל כך מהר

אני רוצה לחבר אותך רגע למה שעשית אתמול. עבדת לפי מחזור התגובה של NIST: הכנה→זיהוי→כליאה→מחיקה→שיקום→לקחים. בוא ננשום עמוק ונחמם את השרירים.

• אילו שתי פעולות כתבת לעצמך לשלב "זיהוי" במקרה של כופרה? נסה להיזכר בלי להציץ.
• דמיין שתחנה במשרד מתחילה להצפין קבצים משותפים. מה תהיה פעולת ה"כליאה" הראשונה שלך בפועל תוך דקה?
• בשלב "לקחים" — פרט כלי אחד או כלל עבודה שהיית מוסיף כדי לקצר את זמן הזיהוי בפעם הבאה.

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

במשרד קטן בבניין משותף, עובד פותח בבוקר קובץ רכש מתיקייה משותפת. כמה דקות אחרי — קבצי ה-Shared נהיים עם סיומות מוזרות, והמדפסת ברשת לא מגיבה. אתה על הקו: "האם זה כופרה?"

אני זוכר פעם שלימדתי צוות תמיכה, ומישהי שאלה: "למה המדפסת?" — כי המדפסת יושבת על אותו SMB כמו התיקיות. זה הרגע שבו מבינים שהפרוטוקול הזה מחבר חצי משרד.

השעון דופק: אם זו כופרה בסגנון WannaCry, היא לא רק מצפינה — היא גם מדביקה מחשבים שכנים דרך SMB בלי שתלחץ כלום. צריך לדעת איפה לשבור את השרשרת.

מהו SMB ולמה SMBv1 בעייתי

SMB הוא הפרוטוקול שמגיש תיקיות ומדפסות ברשת. SMBv1 היא גרסה ישנה עם חולשות מוכרות, ולכן ברוב הארגונים בטוח לכבות אותה ולהישען על SMBv2/3.

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

טעות נפוצה: לחשוב ש"כיבוי SMBv1 ישבור את כל השיתופים". בפועל, לקוחות מודרניים מדברים SMBv2/3 אוטומטית.

מהו MS17‑010 ואיך הניצול פועל בקצרה

MS17‑010 הוא עדכון שסוגר שורה של חולשות ב-SMBv1. ניצול החולשה מאפשר להריץ קוד מרחוק ללא הזדהות מלאה, ומשם התקדמות אוטומטית.

כלל עבודה: כשיש עדכון קריטי לשירות רשת, יעד ברירת המחדל הוא "לעדכן כעת" ולבדוק תאימות בדיעבד — לא להפך.

למה WannaCry התפשט מהר כל כך

ל-WannaCry מנגנון תולעת: אחרי הדבקה מקומית, הוא סורק שכנים ומנצל SMB פגיע כדי לקפוץ אליהם בלי פעולה מצד המשתמש. ברשתות ללא סגמנטציה וללא העדכון — זה דומינו.

אזהרה: מהירות ההפצה אינה קבועה; היא תלויה בכמה מארחים נגישים ב-LAN ועל גבי VPNים פתוחים.

שלושה ברקסים שעוצרים את השרשרת

1) עדכון MS17‑010. 2) השבתת SMBv1. 3) סגמנטציית רשת בסיסית שמגבלת גישה בין סגמנטים.

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

כדי שזה יהיה מוחשי, נצייר רשת קטנה עם שני סגמנטים ו"חומת" סינון ביניהם. נראה איך תחנה נגועה בסגמנט A לא מדביקה מיידית את סגמנט B כשהכללים צרים.

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

נבצע יחד: טבלת "לפני/אחרי" קצרה לכל צעד, ואז אתה ממלא בעצמך ומוסיף אינדיקטור זיהוי אחד.

אני תמיד מקדים ואומר: אין כאן קסם — שלושה צעדים סולידיים חוזרים להציל ארגונים שוב ושוב.

הדגמה מונחית

• MS17‑010: לפני — ניצול RCE דרך SMBv1 פתוח; אחרי — חיבור עוין נחסם בשכבת השרת.
• השבתת SMBv1: לפני — לקוחות ישנים כופים פרוטוקול חלש; אחרי — תקשורת נופלת ל-SMBv2/3 עם שיפורי אבטחה.
• סגמנטציה: לפני — כל תחנה רואה את כולן; אחרי — תחנה רואה רק את הסגמנט שלה, וכלל בין-סגמנטלי חוסם 445.

עכשיו תורך — תרגול עצמאי עם בדיקה עצמית

מלא טבלת לפני/אחרי משלך בשלוש השורות הבאות:

בדיקה עצמית: האם בכל שורה תיארת בדיוק איזה חלק בשרשרת נשבר? (ניצול, פרוטוקול חלש, נראות בין-סגמנטלית)

הוסף שורה חופשית: איזה IOC ספציפי היית מחפש כדי לזהות WannaCry בזמן? לדוגמה, חיבורי 445 מתפרצים למספר יעדים תוך דקה, או שם קובץ ייחודי מההתראות הרשמיות.

רמז שימושי: לוגי Firewall עם ניסיונות 445 מרובים בפרק זמן קצר מאותה תחנה — סיגנל טוב להתחלה.

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

• SMBv1 הוא וקטור סיכון מוכר; עדיף להשבית כשהתאימות מאפשרת.
• MS17‑010 סוגר את חלון הניצול המרכזי של WannaCry על גבי SMBv1.
• מנגנון התולעת של WannaCry מנצל נגישות רשתית — סגמנטציה שוברת התפשטות.
• שלושת הברקסים: עדכון, כיבוי SMBv1, וסגמנטציה בין-סגמנטלית.
• IOC התחלתי טוב: דפוס ניסיונות חיבור 445 מרובים מאותה תחנה בפרק זמן קצר.