עדכן את RouterOS ב-MikroTik שלך

בערב ה-10 במרץ, שירות התמיכה של Mail.ru החל לקבל תלונות ממשתמשים על חוסר היכולת להתחבר לשרתי IMAP/SMTP של Mail.ru באמצעות תוכנות דואר אלקטרוני. יחד עם זאת, חלק מהחיבורים לא עברו, וחלק מראים שגיאת אישור. השגיאה נגרמת על ידי ה"שרת" שמנפיק אישור TLS בחתימה עצמית.
 

במשך יומיים, יותר מ-10 תלונות הגיעו ממשתמשים במגוון רחב של רשתות ועם מגוון מכשירים, מה שהופך את זה לא סביר שהבעיה הייתה ברשת של ספק אחד. ניתוח מפורט יותר של הבעיה גילה ששרת imap.mail.ru (כמו גם שרתי דואר ושירותים אחרים) מוחלף ברמת ה-DNS. יתרה מכך, בעזרתם הפעילה של המשתמשים שלנו, מצאנו שהסיבה לכך הייתה כניסה שגויה במטמון של הנתב שלהם, שהוא גם פותר DNS מקומי, ואשר במקרים רבים (אך לא בכולם) התברר כ-MikroTik. מכשיר, פופולרי מאוד ברשתות ארגוניות קטנות ומספקי אינטרנט קטנים.

מה הבעיה

בספטמבר 2019, חוקרים מצאתי מספר נקודות תורפה ב-MikroTik RouterOS (CVE-2019-3976, CVE-2019-3977, CVE-2019-3978, CVE-2019-3979), שאפשרו התקפת הרעלת מטמון DNS, כלומר. היכולת לזייף רשומות DNS במטמון ה-DNS של הנתב, ו-CVE-2019-3978 מאפשרת לתוקף לא לחכות שמישהו מהרשת הפנימית יבקש כניסה בשרת ה-DNS שלו כדי להרעיל את מטמון הפותר, אלא ליזום כזה בקשה בעצמו דרך היציאה 8291 (UDP ו-TCP). הפגיעות תוקנה על ידי MikroTik בגרסאות של RouterOS 6.45.7 (יציב) ו-6.44.6 (לטווח ארוך) ב-28 באוקטובר 2019, אך על פי מחקר רוב המשתמשים לא התקינו כרגע תיקונים.

ברור שהבעיה הזו מנוצלת כעת באופן פעיל "חי".

למה זה מסוכן

תוקף יכול לזייף את רשומת ה-DNS של כל מארח שאליו משתמש משתמש ברשת הפנימית, ובכך ליירט תעבורה אליו. אם מידע רגיש מועבר ללא הצפנה (לדוגמה, דרך http:// ללא TLS) או שהמשתמש מסכים לקבל תעודה מזויפת, התוקף יכול להשיג את כל הנתונים שנשלחים דרך החיבור, כגון כניסה או סיסמה. למרבה הצער, התרגול מראה שאם למשתמש יש הזדמנות לקבל תעודה מזויפת, הוא ינצל אותה.

למה שרתי SMTP ו-IMAP, ומה הציל משתמשים

מדוע ניסו התוקפים ליירט תעבורת SMTP/IMAP של יישומי דואר אלקטרוני, ולא תעבורת אינטרנט, למרות שרוב המשתמשים ניגשים לדואר שלהם דרך דפדפן HTTPS?

לא כל תוכנות הדואר האלקטרוני הפועלות באמצעות SMTP ו-IMAP/POP3 מגנות על המשתמש מפני שגיאות, ומונעות ממנו לשלוח כניסה וסיסמה דרך חיבור לא מאובטח או נפוץ, אם כי לפי התקן RFC 8314, שאומצו עוד בשנת 2018 (ויושמו ב-Mail.ru הרבה קודם לכן), הם חייבים להגן על המשתמש מפני יירוט סיסמה דרך כל חיבור לא מאובטח. בנוסף, פרוטוקול OAuth נמצא בשימוש נדיר מאוד בלקוחות דוא"ל (הוא נתמך על ידי שרתי דואר Mail.ru), ובלעדיו, הכניסה והסיסמה מועברות בכל הפעלה.

דפדפנים עשויים להיות מוגנים מעט יותר מפני התקפות Man-in-the-Middle. בכל הדומיינים הקריטיים של mail.ru, בנוסף ל-HTTPS, מדיניות HSTS (HTTP strict transport security) מופעלת. כאשר HSTS מופעל, דפדפן מודרני אינו נותן למשתמש אפשרות קלה לקבל תעודה מזויפת, גם אם המשתמש ירצה בכך. בנוסף ל-HSTS, משתמשים ניצלו על ידי העובדה שמאז 2017, שרתי SMTP, IMAP ו-POP3 של Mail.ru אוסרים על העברת סיסמאות בחיבור לא מאובטח, כל המשתמשים שלנו השתמשו ב-TLS לגישה דרך SMTP, POP3 ו-IMAP, וכן לכן התחברות והסיסמה יכולות ליירט רק אם המשתמש עצמו מסכים לקבל את האישור המזויף.

עבור משתמשים ניידים, אנו תמיד ממליצים להשתמש ביישומי Mail.ru כדי לגשת לדואר, כי... עבודה עם דואר בתוכם בטוחה יותר מאשר בדפדפנים או בלקוחות SMTP/IMAP מובנים.

מה צריך לעשות

יש צורך לעדכן את הקושחה של MikroTik RouterOS לגרסה מאובטחת. אם מסיבה כלשהי זה לא אפשרי, יש צורך לסנן תעבורה בפורט 8291 (tcp ו-udp), זה יסבך את ניצול הבעיה, אם כי זה לא יבטל את האפשרות של הזרקה פסיבית למטמון ה-DNS. ספקי שירותי אינטרנט צריכים לסנן את היציאה הזו ברשתות שלהם כדי להגן על משתמשים ארגוניים. 

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

נ.ב. ישנה גם פגיעות קשורה המתוארת בפוסט לוקה ספונוב "פגיעות של יציאות אחוריות ב-RouterOS מסכנת מאות אלפי מכשירים".

מקור: www.habr.com