W wieczór 10 marca zespół wsparcia technicznego Mail.ru zaczął otrzymywać skargi od użytkowników dotyczące niemożności połączenia się z serwerami IMAP/SMTP Mail.ru za pomocą programów pocztowych. Część połączeń nie była nawiązywana, a część pokazywała błąd certyfikatu. Błąd ten jest spowodowany tym, że "serwer" zwraca samopodpisany certyfikat TLS.
W ciągu dwóch dni wpłynęło ponad 10 skarg od użytkowników z różnych sieci i na różnych urządzeniach, co czyniło mało prawdopodobnym, że problem dotyczy jednego dostawcy. Bardziej szczegółowa analiza problemu ujawniła, że następuje zmiana serwera imap.mail.ru (oraz innych serwerów pocztowych i usług) na poziomie DNS. Następnie, przy aktywnej pomocy naszych użytkowników, odkryliśmy, że przyczyną jest błędny wpis w pamięci podręcznej ich routera, który jednocześnie pełni rolę lokalnego resolvera DNS, a w wielu (ale nie wszystkich) przypadkach był to router MikroTik, bardzo popularny w małych sieciach korporacyjnych i u małych dostawców Internetu.
W czym problem
W wrześniu 2019 roku badacze kilka luk w MikroTik RouterOS (CVE-2019-3976, CVE-2019-3977, CVE-2019-3978, CVE-2019-3979), które umożliwiały przeprowadzanie ataku DNS cache poisoning, tj. możliwość zmiany wpisów DNS w pamięci podręcznej routera, przy czym CVE-2019-3978 pozwala atakującemu na nieczekanie, aż ktoś z sieci wewnętrznej zwróci się z zapytaniem do jego serwera DNS, aby zatruli pamięć podręczną resolvera, a zamiast tego samemu zainicjować takie zapytanie przez port 8291 (UDP i TCP). Luka została załatana przez MikroTik w wersjach RouterOS 6.45.7 (stable) i 6.44.6 (long-term) 28 października 2019, jednak według większość użytkowników obecnie nie zainstalowała poprawek.
Jest oczywiste, że obecnie problem ten jest aktywnie wykorzystywany "w rzeczywistości".
Jakie są tego konsekwencje
Atakujący może podmienić wpis DNS dowolnego hosta, do którego użytkownik wewnętrznej sieci się zwraca, przejmując tym samym ruch do niego. Jeśli przesyłane są dane wrażliwe bez szyfrowania (np. po http:// bez TLS) lub użytkownik zgadza się na przyjęcie fałszywego certyfikatu, atakujący może uzyskać wszystkie dane, które zostają przesłane przez połączenie, takie jak login lub hasło. Niestety, praktyka pokazuje, że jeśli użytkownik ma możliwość zaakceptowania fałszywego certyfikatu, to z niej skorzysta.
Dlaczego serwery SMTP i IMAP są tak istotne i co chroniło użytkowników
Dlaczego atakujący próbowali przechwycić ruch SMTP/IMAP aplikacji pocztowych, a nie ruch w sieci, mimo że większość użytkowników korzysta z poczty przez przeglądarkę z HTTPS?
Nie wszystkie programy pocztowe działające na zasadzie SMTP i IMAP/POP3 zabezpieczają użytkowników przed błędami, zezwalając na przesyłanie loginu i hasła przez niezabezpieczone lub skompromitowane połączenie, chociaż zgodnie z normą , przyjętą już w 2018 roku (wdrożoną w Mail.ru znacznie wcześniej), powinny chronić użytkownika przed przechwyceniem hasła przez jakiekolwiek niezabezpieczone połączenie. Ponadto, do tej pory w programach pocztowych bardzo rzadko wykorzystywany jest protokół OAuth (jest on wspierany przez serwery pocztowe Mail.ru), a bez niego login i hasło przesyłane są w każdym sesji.
Przeglądarki mogą być nieco lepiej zabezpieczone przed atakami typu Man-in-the-Middle. Na wszystkich krytycznych domenach mail.ru dodatkowo do HTTPS włączona jest polityka HSTS (HTTP Strict Transport Security). Przy włączonym HSTS nowoczesna przeglądarka nie daje użytkownikowi prostej możliwości zaakceptowania fałszywego certyfikatu, nawet jeśli użytkownik by tego chciał. Oprócz HSTS, użytkownicy byli chronieni tym, że od 2017 roku serwery SMTP, IMAP i POP3 Mail.ru zabraniają przesyłania hasła przez niezabezpieczone połączenie, wszyscy nasi użytkownicy korzystali z TLS do dostępu przez SMTP, POP3 i IMAP, a zatem login i hasło można przechwycić tylko, jeśli użytkownik sam zgodzi się zaakceptować podmieniony certyfikat.
Dla użytkowników mobilnych zawsze zalecamy korzystanie z aplikacji Mail.ru do dostępu do poczty, ponieważ praca z pocztą w nich jest bezpieczniejsza niż w przeglądarkach czy wbudowanych klientach SMTP/IMAP.
Co należy zrobić
Należy zaktualizować oprogramowanie MikroTik RouterOS do bezpiecznej wersji. Jeśli z jakiś powodów to niemożliwe, konieczne jest filtrowanie ruchu przez port 8291 (tcp i udp), co utrudni eksploatację problemu, chociaż nie wyeliminuje możliwości pasywnej iniekcji do pamięci podręcznej DNS. Dostawcy Internetu powinni filtrować ten port w swoich sieciach, aby chronić użytkowników korporacyjnych.
Wszyscy użytkownicy, którzy zaakceptowali podrobiony certyfikat, powinni pilnie zmienić hasło do poczty elektronicznej i innych usług, dla których ten certyfikat został zaakceptowany. Z naszej strony powiadomimy użytkowników, którzy logują się do poczty za pomocą podatnych urządzeń.
P.S. Jest jeszcze powiązana podatność opisana w poście "".
Źródło: habr.com
