בקובץ הלוג של נתב MikroTik אחד הופיעו בתחילת ספטמבר שתי שורות שאף מנהל רשת לא רוצה לראות. הראשונה מדווחת על ניסיון התחברות שנכשל של משתמש בשם "-2", שם שלא אמור להתקיים בשום מערכת. השנייה מדווחת שמשתמש חדש בשם ops נוסף למכשיר, ושמי שהוסיף אותו הוא אותו "-2". בין שתי השורות האלה עברו הרגעים שבהם מישהו לקח שליטה מלאה על הנתב.

צוות CERT Polska פרסם ב-5 בספטמבר שהוא זיהה ותיאם את החשיפה של שש חולשות ב-RouterOS, מערכת ההפעלה של נתבי MikroTik. צירוף של שתיים מהן, שהצוות קרא לו MikroTrick, מעניק שליטה מלאה במכשיר בלי שום פרטי אימות, בתנאי אחד: ששירות ה-SSH של הנתב נגיש מרשתות ציבוריות. הצוות מאשר שהצירוף הזה כבר מנוצל בתקיפות אמיתיות, ושהעדכונים שיצאו עוצרים אותן. בהמשך נראה איך העדכון של MikroTik יצא בשקט יומיים קודם לכן, איך שתי החולשות מצטרפות זו לזו, מה עוד התגלה באותה סדרת מחקר, ואיך בודקים אם הנתב שלכם כבר נגוע.

עדכון שקט, ותקיפות שכבר רצו יום קודם

ב-3 בספטמבר שחררה MikroTik את גרסה 7.24.2 בערוץ היציב. ההודעה בפורום פתחה במשפט שחזר על עצמו בכל הגרסאות של אותו יום: מדובר בעדכון אבטחה חשוב, רוב התצורות אינן בסיכון, ומומלץ מאוד לעדכן. רשימת השינויים נראתה כמו כל changelog אחר של החברה, תיקון ל-BGP, שיפור בטיפול ב-image של container, ובאמצע שורה אחת על SSH: "refactor SSH internal processes and improved system stability". ההודעה באתר החברה הוסיפה שכדי לתת למשתמשים זמן לעדכן, פרטים לא יפורסמו בשלב הזה.

בפורום לא קנו את זה. שעה ושש דקות אחרי ההודעה כתב שם משתמש בשם eider שהגרסה היציבה כבר מצמצמת מאוד את שטח החיפוש, ושתוך שש שעות אמור להיות בידיים PoC שאפשר לשחזר. משתמש אחר שאל ישירות אם שורת ה-SSH היא החלק ה"ביטחוני" של העדכון, ונציג החברה השיב לו שב-SSH אין חשיפה כברירת מחדל באף מכשיר ביתי, ושכל הפורטים שם חסומים בחומת האש. (ולפי CERT Polska, זו הפעם הראשונה בהיסטוריה של MikroTik שהיא שלחה התראת push לטלפונים של מי שהתקין את האפליקציה שלה.)

התקיפות, בינתיים, לא חיכו לאף PoC. לפי CERT Polska, ההשתלטויות המוצלחות שנצפו עד כה, ובהן יצירת חשבון ה-ops, מגיעות מכתובת ה-IP 82.192.72.4 ונמשכות לפחות מ-2 בספטמבר. יום לפני שהעדכון בכלל יצא. כתובת נוספת, 103.102.31.18, שימשה לניסיונות לנצל את אותה שרשרת.

שתי חולשות שמצטרפות לשליטה מלאה

כשמנהל מגדיר התחברות ל-SSH באמצעות מפתח במקום סיסמה, הוא מעלה לנתב את החלק הציבורי של המפתח, והשרת אמור לוודא שמי שמתחבר מחזיק בחלק הפרטי שמתאים לו. מפתח RSA ציבורי מורכב משני מספרים: מודולוס גדול, ומעריך. RouterOS השווה בין המפתח שהמתחבר שולח לבין המפתח השמור אצלו לפי סוג המפתח והמודולוס בלבד, והתעלם מהמעריך. את החתימה עצמה הוא בדק מול המפתח שהלקוח סיפק, ולכן תוקף שמכיר שם משתמש ואת המודולוס של מפתח מורשה יכול לבנות מפתח משלו עם מעריך 1, לזייף חתימה שנראית תקפה, ולפתוח ערוץ פקודות בתור אותו משתמש. בלי המפתח הפרטי, ובלי לנחש כלום. זו CVE-2026-67276, בציון CVSS 9.2 לפי CERT Polska.

ההרשאות שמתקבלות ככה שוות לאלה של החשבון שנפרץ, ולא בהכרח הרשאות מלאות, וכאן נכנסת לתמונה החולשה השנייה. RouterOS לא טיפל כראוי בשמות משתמש שמתחילים בתו אסור, במסלול ההתחברות של ה-SSH. שם משתמש שבנוי בקפידה מצליח לשנות את מסכת ההרשאות שהמערכת מייחסת לסשן, והתוצאה היא סשן עם הרשאות ניהול מלאות על המכשיר. זו CVE-2026-86060, גם היא בציון 9.2, ולצירוף שלה עם קודמתה קרא CERT Polska בשם MikroTrick.

שש החולשות נוגעות לאותם טווחי גרסאות: כל 7.24 עד 7.24.2, כל 7.0.0 עד 7.23.4, וכל 6.0.0 עד 6.49.21. כלומר, בפועל, כל התקנה שלא עודכנה השבוע.

וארבע נוספות שלא נכנסו לשרשרת

השלישית בחומרתה יושבת בשירות בדיקת רוחב הפס, ה-bandwidth-test. השירות הסכים לקבל חיבור "נלווה" עוד לפני שהסשן הראשי סיים אימות, כלומר לפני שמישהו הוכיח מי הוא. משם נפתחות שתי בעיות נפרדות: כשמבקשים בדיקה בלי נתונים אקראיים, השרת מחזיר זנב של buffer מהקרנל שלא אותחל, ושולח החוצה פיסות זיכרון שלא היו אמורות לצאת; ותחום גודל של פאקטה שהוגדר הפוך ולא נבדק גורם לגלישה כלפי מטה של מספר לא מסומן, לפלט מקוטע חריג בגודלו, ולאתחול של הקרנל. זו CVE-2026-67277, בציון 8.8.

שלוש הנותרות פורסמו בעמוד הייעודי של CERT Polska בלי ציון CVSS, ושתיים מהן מטרידות לא פחות. ב-CVE-2026-67281 יש קריאת קבצים ללא אימות בממשק הניהול WebFig, בנתיב /jsproxy: סשן חדש משאיר אצלו מצביע ישן ולא מאותחל לזהות שמורשית לגשת לקבצים, ותוקף שמסדר את הזיכרון כך שהמצביע יצביע להרשאות מספיקות יכול להוסיף לכתובת רכיבי "תיקייה אחת למעלה" ולצאת מתחום הקבצים שהממשק מגביל אליו. מה שנחשף כך הוא קבצים בבעלות root, ובכללם מאגרי תצורה עם פרטי אימות.

ב-CVE-2026-67279 שרת ה-SSH ממשיך לשלב הבא של הפרוטוקול אחרי שהלקוח מבקש החלפת מפתחות, גם כשאף אחד לא ניסה להזדהות. לקוח לא מאומת יכול לפתוח ערוץ, לשלוח בקשת exec, והשרת בגרסאות שלפני התיקון מעביר אותה הלאה. התוצאה, לפי CERT, היא יצירה, דריסה ושחזור של קבצים במרחב הקבצים המנוהל של RouterOS, כולל קובצי תמיכה שמכילים תצורה ונתוני אבחון.

החולשה השישית לא נוגעת בשרת אלא בצד הלקוח. CVE-2026-67278 קובעת ש-RouterOS קיבל חתימות RSA/PKCS#1 v1.5 פגומות כשבדק תעודות X.509, ושמאגר התעודות המובנה שלו כלל root CA שהמעריך שלו הוא 3. מי ששולט בחיבור TLS שיוצא מהנתב, או מסוגל להסיט אותו, יכול להשתמש בתעודה הציבורית של אותו root CA, בלי המפתח הפרטי שלו, כדי לייצר תעודת ביניים שהמכשיר סומך עליה ולהנפיק ממנה תעודות לכל שם דומיין. בפועל: להתחזות לכל שרת שהנתב מתחבר אליו.

איך תדעו שהנתב שלכם כבר נפרץ?

המנגנון שהוסיפה MikroTik בגרסאות המתוקנות סורק את התצורה בכל עלייה של המערכת, מחפש סימנים מוכרים לשינויים לא מורשים, מכבה את מה שהוא מזהה כחשוד, כותב הודעה קריטית ללוג ומסמן את המכשיר במצב Flagged. התיעוד של היצרן מפרט מה קורה אז: המכשיר חוסם את bandwidth-test, את traffic-generator ואת ה-sniffer, ולא מאפשר להוסיף רשומות חדשות ל-scheduler, ל-SOCKS proxy, ל-PPTP, ל-L2TP, ל-IPsec ול-SMB. יציאה מהמצב דורשת פקודה ייעודית ואחריה לחיצה פיזית על כפתור או אתחול קר.

יש כאן נקודה שקל לפספס, ו-CERT Polska מדגיש אותה. המנגנון מזהה רק חלק מהעקבות שנשארות אחרי פריצה, והיעדר הסימון אינו הוכחה שהמכשיר נקי. "איננו יכולים לשלול קיומן של חולשות שאיננו מכירים ושהיצרן לא תיאר ב-changelog", כתבו החוקרים, ולכן הסימון עצמו הוא אינדיקציה לפריצה אפשרית קודמת, לא ראיה לכך שנוצלה דווקא אחת מהחולשות שהם דיווחו עליהן.

מה כן כדאי לחפש בלוג של המכשיר: שורה שמדווחת על כישלון התחברות של המשתמש "-2" מכתובת חיצונית, ושורה שמדווחת על הוספת משתמש בידי ssh:-2. סימן נוסף הוא נוכחות של חשבון בעל הרשאות גבוהות בשם ops. ולצד זה, מעבר ידני על התצורה: משתמשים שאתם לא מכירים, סקריפטים, משימות ב-scheduler, שרתי proxy ומנהרות. אם משהו מזה נמצא, הסדר חשוב. CERT ממליץ לנתק את המכשיר מהרשת, לשמור את הלוגים ואת התצורה לפני כל איפוס, להחזיר את הנתב להגדרות יצרן ולהגדיר אותו מחדש מתוך תצורה מוודאת, ולהחליף סיסמאות ומפתחות. גיבוי מלא של מכשיר חשוד לא משחזרים כמו שהוא.

מי מצא את החולשות, ואיך

החלק הזה של הפרסום מעניין בפני עצמו. CERT Polska כותב שאת שש החולשות מצא הצוות בעזרת מודלי שפה, GPT-5.5-cyber ו-GPT-5.6-sol, במסגרת תוכנית של OpenAI בשם Government and Trust Agency Collaboration. המודלים הופעלו כסוכנים בסביבת מחקר שהריצה מעבדה אוטומטית: הקמה ושחזור של מכונות MikroTik, הורדה והשוואה של גרסאות, ניתוח של מסמכי RFC ושל קוד בינארי, ובניית סקריפטים שמאשרים שחולשה קיימת. מה שעבד במיוחד, לדברי הצוות, היה למדל את הפרוטוקולים כמכונות מצבים ולבדוק מה קורה כששלב מדולג, חוזר על עצמו או מתבצע בסדר הלא נכון. קשה שלא לשים לב שזה בדיוק הדפוס של כמה מהחולשות ברשימה, מחיבור btest שמתקבל לפני האימות ועד סשן SSH שממשיך הלאה בלי שאיש הזדהה.

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

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

מה זה אומר בפועל

אם אתם מנהלים נתב MikroTik, הגרסאות שסוגרות את כל השש הן 6.49.21, 7.23.4, 7.24.2 ו-7.25beta3. מי שנמצא על ענף 7.23 כדאי שיעדכן ל-7.23.5 ולא ל-7.23.4: ב-4 בספטמבר הודיעה החברה בפורום שרגרסיה ב-DHCPv6 חמקה מהבדיקות בגרסה הקודמת, ושהיא תוקנה תוך שמירה על תיקון האבטחה.

אם אי אפשר לעדכן כרגע, ההמלצה הזמנית של CERT היא לחסום את השירותים החשופים מכל כתובת שאינה ברשת ניהול מהימנה, ובראשם SSH, WWW/WWW-SSL ושרת ה-bandwidth-test, ולהימנע מיצירת חיבורי TLS מהמכשיר או משימוש בלקוחות ה-SSH המובנים שלו. אלה צעדים שמצמצמים את שטח התקיפה, לא תחליף לעדכון. ואם יש אצלכם נתב אחד עם SSH פתוח לאינטרנט כי פעם זה היה נוח, זה הרגע לסגור אותו בכל מקרה.