La sera del 10 marzo, il servizio di supporto di Mail.ru ha iniziato a ricevere segnalazioni da parte degli utenti riguardo all'impossibilità di connettersi ai server IMAP/SMTP di Mail.ru attraverso i programmi di posta elettronica. Alcune connessioni non sono riuscite, mentre altre hanno mostrato un errore di certificato. L'errore è stato causato dal fatto che il "server" restituisce un certificato TLS autofirmato.
In due giorni sono arrivate più di 10 segnalazioni da utenti di reti diverse e con dispositivi vari, rendendo poco probabile che il problema derivi da un singolo fornitore. Un'analisi più approfondita ha rivelato che c'era una sostituzione del server imap.mail.ru (e di altri server di posta e servizi) a livello DNS. Successivamente, con l'aiuto attivo dei nostri utenti, abbiamo scoperto che la causa risiedeva in una registrazione errata nella cache del loro router, che funge anche da risolutore DNS locale, e che in molti (ma non tutti) casi si è rivelato essere un dispositivo MikroTik, molto popolare nelle piccole reti aziendali e tra i piccoli fornitori di Internet.
Qual è il problema
Nel settembre 2019, i ricercatori sono state trovate diverse vulnerabilità in MikroTik RouterOS (CVE-2019-3976, CVE-2019-3977, CVE-2019-3978, CVE-2019-3979) che consentivano attacchi di avvelenamento della cache DNS, cioè la possibilità di falsificare le registrazioni DNS nella cache del router. In particolare, CVE-2019-3978 consente all'attaccante di non dover attendere una richiesta da qualcuno della rete interna al suo server DNS per contaminare la cache del resolver, ma di avviare tale richiesta autonomamente 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 ora questo problema è attivamente sfruttato "in tempo reale".
Quali sono i rischi?
L'attaccante può alterare il record DNS di qualsiasi host a cui si rivolge un utente nella rete interna, intercettando così il traffico indirizzato a esso. Se informazioni sensibili vengono trasmesse senza crittografia (ad esempio tramite http:// senza TLS) o se l'utente accetta un certificato falso, l'attaccante può accedere a tutti i dati inviati attraverso la connessione, come il nome utente o la password. Purtroppo, l'esperienza dimostra che se un utente ha la possibilità di accettare un certificato falso, lo farà.
Perché sono proprio i server SMTP e IMAP, e cosa salvava gli utenti
Perché gli attaccanti cercavano di intercettare specificamente il traffico SMTP/IMAP delle applicazioni di posta, e non il traffico web, dato che la maggior parte degli utenti accede alla propria posta tramite browser utilizzando HTTPS?
Non tutti i programmi di posta che utilizzano SMTP e IMAP/POP3 proteggono l'utente dall'errore, permettendogli di inviare nome utente e password tramite una connessione non sicura o compromessa, sebbene ciò sia previsto dagli standard. , adottato nel 2018 (e implementato molto prima da Mail.ru), deve proteggere l'utente dall'intercettazione della password attraverso qualsiasi connessione non sicura. Inoltre, finora il protocollo OAuth viene utilizzato molto raramente nei client di posta (è supportato dai server di posta di Mail.ru), e senza di esso login e password vengono trasmessi in ogni sessione.
I browser possono essere leggermente più protetti contro gli attacchi Man-in-the-Middle. Su tutti i domini critici di mail.ru, oltre all'HTTPS, è stata attivata la politica HSTS (HTTP Strict Transport Security). Quando HSTS è attivo, i browser moderni non consentono all'utente di accettare un certificato contraffatto, anche se lo desidera. Oltre all'HSTS, gli utenti sono stati protetti dal fatto che, dal 2017, i server SMTP, IMAP e POP3 di Mail.ru vietano la trasmissione della password attraverso connessioni non sicure; tutti i nostri utenti hanno utilizzato TLS per accedere tramite SMTP, POP3 e IMAP, e quindi login e password possono essere intercettati solo se l'utente accetta di fronteggiare un certificato sostituito.
Per gli utenti mobili, raccomandiamo sempre di utilizzare le app Mail.ru per accedere alla posta, poiché lavorare con la posta in esse è più sicuro rispetto ai browser o ai client SMTP/IMAP integrati.
Cosa fare
È necessario aggiornare il firmware MikroTik RouterOS a una versione sicura. Se per qualche motivo questo non è possibile, è necessario filtrare il traffico sulla porta 8291 (tcp e udp), ciò renderà più difficile l'exploitation del problema, anche se non eliminerà la possibilità di iniezione passiva nella cache DNS. I fornitori di servizi Internet dovrebbero filtrare questa porta nelle loro reti per proteggere gli utenti aziendali.
Tutti gli utenti che hanno accettato il certificato compromesso devono cambiare immediatamente la password della propria 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. Esiste anche una vulnerabilità correlata, descritta nel post "".
Fonte: habr.com
