Вечером 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 оберегают пользователя от ошибки, не позволяя ему отправить логин и пароль через небезопасное или скомпрометированное соединение, хотя по стандарту 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-кэш. Интернет-провайдерам стоит фильтровать этот порт на своих сетях, чтобы защитить корпоративных пользователей. 

Всем пользователям, которые принимали подмененный сертификат следует срочно сменить пароль электронной почты и других сервисов, для которых этот сертификат принимался. Со своей стороны, мы оповестим пользователей, которые заходят в почту через уязвимые устройства.

P.S. Есть еще связанная уязвимость, описанная в посте LukaSafonov "Backport уязвимость в RouterOS ставит под угрозу сотни тысяч устройств".