Wieczorem 10 marca do działu pomocy technicznej Mail.ru zaczęły otrzymywać skargi od użytkowników dotyczące niemożności połączenia się z serwerami IMAP/SMTP Mail.ru za pośrednictwem programów pocztowych. Jednocześnie niektóre połączenia nie zostały zrealizowane, a niektóre pokazują błąd certyfikatu. Błąd jest spowodowany przez „serwer” wystawiający certyfikat TLS z podpisem własnym.
W ciągu dwóch dni wpłynęło ponad 10 skarg od użytkowników różnych sieci i różnych urządzeń, co sprawia, że jest mało prawdopodobne, aby problem dotyczył sieci któregokolwiek dostawcy. Bardziej szczegółowa analiza problemu wykazała, że serwer imap.mail.ru (a także inne serwery i usługi pocztowe) jest wymieniany na poziomie DNS. Co więcej, przy aktywnej pomocy naszych użytkowników odkryliśmy, że przyczyną był nieprawidłowy wpis w pamięci podręcznej ich routera, który jest również lokalnym narzędziem do rozpoznawania nazw DNS i który w wielu (ale nie wszystkich) przypadkach okazał się być MikroTikiem urządzenie, bardzo popularne w małych sieciach korporacyjnych i u małych dostawców Internetu.
W czym jest problem
We wrześniu 2019 r. badacze kilka luk w MikroTik RouterOS (CVE-2019-3976, CVE-2019-3977, CVE-2019-3978, CVE-2019-3979), które umożliwiły atak DNS cache zatruwania, tj. możliwość fałszowania rekordów DNS w pamięci podręcznej DNS routera, a CVE-2019-3978 pozwala atakującemu nie czekać, aż ktoś z sieci wewnętrznej zażąda wpisu na jego serwerze DNS w celu zatrucia pamięci podręcznej mechanizmu rozpoznawania nazw, ale zainicjować takie żądanie samodzielnie przez port 8291 (UDP i TCP). Luka została naprawiona przez MikroTik w wersjach RouterOS 6.45.7 (stabilna) i 6.44.6 (długoterminowa) 28 października 2019 r., ale według Większość użytkowników nie zainstalowała obecnie poprawek.
Jest oczywiste, że problem ten jest obecnie aktywnie wykorzystywany „na żywo”.
Dlaczego jest to niebezpieczne
Osoba atakująca może sfałszować rekord DNS dowolnego hosta, do którego użytkownik uzyskuje dostęp w sieci wewnętrznej, przechwytując w ten sposób ruch do niego. Jeśli poufne informacje są przesyłane bez szyfrowania (na przykład przez http:// bez TLS) lub użytkownik zgodzi się zaakceptować fałszywy certyfikat, osoba atakująca może uzyskać wszystkie dane przesyłane za pośrednictwem połączenia, takie jak login czy hasło. Niestety praktyka pokazuje, że jeśli użytkownik ma możliwość zaakceptowania fałszywego certyfikatu, to z niego skorzysta.
Dlaczego serwery SMTP i IMAP i co uratowało użytkowników
Dlaczego osoby atakujące próbowały przechwycić ruch SMTP/IMAP aplikacji pocztowych, a nie ruch internetowy, mimo że większość użytkowników uzyskuje dostęp do poczty za pośrednictwem przeglądarki HTTPS?
Nie wszystkie programy pocztowe działające poprzez SMTP i IMAP/POP3 chronią użytkownika przed błędami, uniemożliwiając mu przesłanie loginu i hasła przez niezabezpieczone lub zagrożone połączenie, chociaż zgodnie ze standardem , przyjęte w 2018 r. (i wdrożone w Mail.ru znacznie wcześniej), muszą chronić użytkownika przed przechwyceniem hasła za pośrednictwem niezabezpieczonego połączenia. Ponadto protokół OAuth jest bardzo rzadko używany w klientach poczty elektronicznej (obsługuje go serwery pocztowe Mail.ru), a bez niego login i hasło przesyłane są w każdej sesji.
Przeglądarki mogą być nieco lepiej chronione przed atakami typu Man-in-the-Middle. We wszystkich domenach krytycznych mail.ru, oprócz HTTPS, włączona jest polityka HSTS (ścisłe bezpieczeństwo transportu HTTP). Po włączeniu HSTS nowoczesna przeglądarka nie daje użytkownikowi łatwej opcji zaakceptowania fałszywego certyfikatu, nawet jeśli użytkownik tego chce. Oprócz HSTS użytkowników uratował fakt, że od 2017 r. Serwery SMTP, IMAP i POP3 Mail.ru zabraniają przesyłania haseł przez niezabezpieczone połączenie, wszyscy nasi użytkownicy korzystali z protokołu TLS w celu uzyskania dostępu przez SMTP, POP3 i IMAP oraz dlatego login i hasło mogą zostać przechwycone tylko wtedy, gdy użytkownik sam zgodzi się zaakceptować sfałszowany certyfikat.
Użytkownikom mobilnym zawsze zalecamy korzystanie z aplikacji Mail.ru w celu uzyskania dostępu do poczty, ponieważ... praca z pocztą w nich jest bezpieczniejsza niż w przeglądarkach czy wbudowanych klientach SMTP/IMAP.
Co robić
Konieczne jest zaktualizowanie oprogramowania MikroTik RouterOS do bezpiecznej wersji. Jeśli z jakiegoś powodu nie jest to możliwe, konieczne jest filtrowanie ruchu na porcie 8291 (tcp i udp), skomplikuje to wykorzystanie problemu, chociaż nie wyeliminuje możliwości pasywnego wstrzykiwania do pamięci podręcznej DNS. Dostawcy usług internetowych powinni filtrować ten port w swoich sieciach, aby chronić użytkowników korporacyjnych.
Wszyscy użytkownicy, którzy zaakceptowali podstawiony certyfikat, powinni pilnie zmienić hasło do poczty elektronicznej i innych usług, dla których ten certyfikat został zaakceptowany. Ze swojej strony powiadomimy użytkowników, którzy uzyskują dostęp do poczty za pośrednictwem podatnych na ataki urządzeń.
PS W poście opisano również powiązaną lukę "".
Źródło: www.habr.com