Оновіть RouterOS на вашому MikroTik

Оновіть RouterOS на вашому MikroTik
Увечері, 10 березня, служба підтримки Mail.ru почала отримувати скарги від користувачів на неможливість підключення до IMAP/SMTP серверів Mail.ru через поштові програми. При цьому частина коннектів не проходила, частина показують помилку сертифіката. Помилка викликана тим, що сервер віддає самопідписаний сертифікат TLS.
 
Оновіть RouterOS на вашому MikroTik
За два дні надійшло більше 10 скарг від користувачів з різних мереж і з різними пристроями, що робило малоймовірним проблему в мережі якогось одного провайдера. Більш детальний аналіз проблеми виявив, що йде заміна сервера imap.mail.ru (а також інших поштових серверів і сервісів) на рівні DNS. Далі, за активної допомоги наших користувачів, ми знайшли, що причина в неправильному запису в кеші їх роутера, який за сумісництвом є локальним DNS резолвером, і яким у багатьох (але не всіх) виявився пристрій MikroTik, дуже популярний у невеликих корпоративних мережах та у невеликих провайдерів Інтернет.

В чому проблема

У вересні 2019 року дослідники знайшли кілька вразливостей у MikroTik RouterOS (CVE-2019-3976, CVE-2019-3977, CVE-2019-3978, CVE-2019-3979), які дозволяли проводити атаку DNS cache poisoning, тобто. можливість підміни DNS-записів у DNS-кеші роутера, причому CVE-2019-3978 дозволяє атакуючому не чекати, коли хтось із внутрішньої мережі звернеться по запис на його DNS-сервер, щоб отруїти кеш резолвера, а ініціювати такий запит самому через порт 8291 (UDP та TCP). Вразливість була виправлена ​​MikroTik у версіях RouterOS 6.45.7 (stable) та 6.44.6 (long-term) 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-кеш. Інтернет-провайдерам варто фільтрувати цей порт на своїх мережах, щоб захистити корпоративних користувачів. 

Усім користувачам, які приймали підмінений сертифікат, слід терміново змінити пароль електронної пошти та інших сервісів, для яких цей сертифікат приймався. Зі свого боку, ми сповістимо користувачів, які заходять до пошти через вразливі пристрої.

PS Є ще пов'язана вразливість, описана у пості LukaSafonov "Backport вразливість у RouterOS ставить під загрозу сотні тисяч пристроїв".

Джерело: habr.com

Додати коментар або відгук