La sera del 10 marzo il servizio di supporto Mail.ru ha iniziato a ricevere lamentele da parte degli utenti riguardo l'impossibilità di connettersi ai server IMAP/SMTP di Mail.ru tramite programmi di posta elettronica. Alcune connessioni non riuscivano, mentre altre segnalavano un errore del certificato. L'errore è causato dal fatto che il "server" restituisce un certificato TLS autofirmato.
In due giorni sono arrivate oltre dieci lamentele da utenti provenienti da diverse reti e con vari dispositivi, rendendo poco probabile che il problema fosse legato a un singolo provider. Un'analisi più dettagliata del problema ha rivelato che c'è stata una sostituzione del server imap.mail.ru (così come di altri server di posta e servizi) a livello DNS. Successivamente, con l'attiva assistenza dei nostri utenti, abbiamo scoperto che la causa era un'errata registrazione nella cache del loro router, che funge anche da resolver DNS locale, e che in molti (ma non tutti) casi si trattava di dispositivi MikroTik, molto popolari nelle piccole reti aziendali e presso piccoli provider Internet.
Qual è il problema
Nel settembre 2019, i ricercatori alcune vulnerabilità in MikroTik RouterOS (CVE-2019-3976, CVE-2019-3977, CVE-2019-3978, CVE-2019-3979), che consentivano un attacco di DNS cache poisoning, cioè la possibilità di sostituire le registrazioni DNS nella cache del router, e CVE-2019-3978 consente all'attaccante di non aspettare che qualcuno della rete interna faccia una richiesta al suo server DNS, per avvelenare la cache del resolver, ma di avviare tale richiesta da solo attraverso la porta 8291 (UDP e TCP). La vulnerabilità è stata corretta da MikroTik nelle versioni RouterOS 6.45.7 (stable) e 6.44.6 (long-term) il 28 ottobre 2019, tuttavia, secondo la maggior parte degli utenti attualmente non ha installato le patch.
È evidente che attualmente questo problema viene sfruttato attivamente "dal vivo".
Quali sono i rischi
L'attaccante può sostituire la registrazione DNS di qualsiasi host al quale si rivolge un utente della rete interna, intercettando così il traffico diretto ad esso. Se le informazioni sensibili vengono trasmesse senza crittografia (ad esempio su http:// senza TLS) o l'utente accetta un certificato falsificato, l'attaccante può ottenere tutti i dati che vengono inviati attraverso la connessione, come il login o la password. Sfortunatamente, la pratica dimostra che, se un utente ha la possibilità di accettare un certificato falsificato, lo farà.
Perché proprio i server SMTP e IMAP, e cosa ha protetto gli utenti
Perché gli aggressori cercavano di intercettare proprio il traffico SMTP/IMAP delle applicazioni di posta e non il traffico web, sebbene la maggior parte degli utenti acceda alla posta tramite il browser in HTTPS?
Non tutti i programmi di posta basati su SMTP e IMAP/POP3 proteggono l'utente dall'errore, impedendo di inviare login e password tramite una connessione non sicura o compromessa, sebbene secondo lo standard , adottato nel 2018 (e implementato in Mail.ru molto prima), dovrebbero proteggere l'utente dall'intercettazione della password attraverso qualsiasi connessione non sicura. Inoltre, finora nei client di posta viene usato raramente il protocollo OAuth (che è supportato dai server di posta Mail.ru), e senza di esso il login e la password vengono trasmessi in ogni sessione.
I browser possono essere leggermente meglio protetti dagli attacchi Man-in-the-Middle. Su tutti i domini critici di mail.ru, oltre a HTTPS, è stata attivata la politica HSTS (HTTP strict transport security). Con HSTS attivato, i moderni browser non permettono all'utente di accettare facilmente un certificato falsificato, anche se l'utente volesse farlo. Oltre a HSTS, ha protetto gli utenti il fatto che dal 2017 i server SMTP, IMAP e POP3 di Mail.ru vietano la trasmissione della password attraverso una connessione non sicura; tutti i nostri utenti utilizzano TLS per l'accesso a SMTP, POP3 e IMAP, e quindi login e password possono essere intercettati solo se l'utente accetta esplicitamente un certificato contraffatto.
Per gli utenti mobili, consigliamo sempre di utilizzare le applicazioni di Mail.ru per accedere alla posta, poiché lavorare con la posta in esse è più sicuro che nei browser o nei client SMTP/IMAP integrati.
Cosa bisogna fare
È necessario aggiornare il firmware di MikroTik RouterOS a una versione sicura. Se per qualche motivo questo non è possibile, è necessario filtrare il traffico sulla porta 8291 (tcp e udp), questo renderà più difficile sfruttare il problema, sebbene non elimini la possibilità di iniezioni passive nella cache DNS. Gli operatori internet dovrebbero filtrare questa porta nelle loro reti per proteggere gli utenti aziendali.
A tutti gli utenti che hanno accettato un certificato contraffatto si consiglia di cambiare immediatamente la password dell'email e di altri servizi per i quali è stato accettato questo certificato. Da parte nostra, informeremo gli utenti che accedono alla posta tramite dispositivi vulnerabili.
P.S. C'è un'ulteriore vulnerabilità correlata, descritta nel post "".
Fonte: habr.com
