
На 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 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, защитават потребителя от грешки, като не му позволяват да изпрати потребителско име и парола през незабезопасено или компрометирано свързване, въпреки че по стандарт , приет още през 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 кеш. Интернет доставчиците трябва да филтрират този порт в мрежите си, за да защитят корпоративните потребители.
На всички потребители, които са приели подменен сертификат, следва спешно да сменят паролата на електронната си поща и други услуги, за които е приет този сертификат. От наша страна, ще уведомим потребителите, които влизат в пощата си през уязвими устройства.
P.S. Има още свързана уязвимост, описана в поста "".
Източник: habr.com
