La sera del 10 marzo, il servizio di supporto di Mail.ru ha iniziato a ricevere reclami da parte degli utenti sull'impossibilità di connettersi ai server IMAP/SMTP di Mail.ru tramite programmi di posta elettronica. Allo stesso tempo, alcune connessioni non sono andate a buon fine e alcune mostrano un errore di certificato. L'errore è causato dal "server" che emette un certificato TLS autofirmato.
In due giorni sono pervenuti più di 10 reclami da parte di utenti su diverse reti e con diversi dispositivi, rendendo improbabile che il problema fosse nella rete di un unico provider. Un'analisi più dettagliata del problema ha rivelato che il server imap.mail.ru (così come altri server e servizi di posta) viene sostituito a livello DNS. Inoltre, con l'aiuto attivo dei nostri utenti, abbiamo scoperto che il motivo era una voce errata nella cache del loro router, che è anche un risolutore DNS locale, e che in molti (ma non tutti) casi si è rivelato essere il MikroTik dispositivo, molto popolare nelle piccole reti aziendali e dai piccoli provider Internet.
Qual è il problema?
Nel settembre 2019, i ricercatori diverse vulnerabilità in MikroTik RouterOS (CVE-2019-3976, CVE-2019-3977, CVE-2019-3978, CVE-2019-3979), che hanno consentito un attacco di avvelenamento della cache DNS, ad es. la capacità di falsificare i record DNS nella cache DNS del router e CVE-2019-3978 consente all'aggressore di non aspettare che qualcuno dalla rete interna richieda una voce sul suo server DNS per avvelenare la cache del risolutore, ma di avviare tale una richiesta lui stesso attraverso la porta 8291 (UDP e TCP). La vulnerabilità è stata risolta da MikroTik nelle versioni RouterOS 6.45.7 (stabile) e 6.44.6 (a lungo termine) il 28 ottobre 2019, ma secondo La maggior parte degli utenti non ha attualmente patch installate.
È ovvio che questo problema viene ora attivamente sfruttato “dal vivo”.
Perché è pericoloso
Un utente malintenzionato può falsificare il record DNS di qualsiasi host a cui accede un utente sulla rete interna, intercettando così il traffico verso di esso. Se le informazioni sensibili vengono trasmesse senza crittografia (ad esempio tramite http:// senza TLS) o l'utente accetta di accettare un certificato falso, l'aggressore può ottenere tutti i dati inviati tramite la connessione, come login o password. Sfortunatamente, la pratica dimostra che se un utente ha la possibilità di accettare un certificato falso, ne trarrà vantaggio.
Perché i server SMTP e IMAP e cosa ha salvato gli utenti
Perché gli aggressori hanno tentato di intercettare il traffico SMTP/IMAP delle applicazioni di posta elettronica e non il traffico web, sebbene la maggior parte degli utenti acceda alla propria posta tramite browser HTTPS?
Non tutti i programmi di posta elettronica funzionanti tramite SMTP e IMAP/POP3 proteggono l'utente da errori, impedendogli di inviare login e password attraverso una connessione non protetta o compromessa, sebbene secondo lo standard , adottati nel 2018 (e implementati in Mail.ru molto prima), devono proteggere l'utente dall'intercettazione della password attraverso qualsiasi connessione non protetta. Inoltre, il protocollo OAuth viene utilizzato molto raramente nei client di posta elettronica (è supportato dai server di posta Mail.ru) e senza di esso il login e la password vengono trasmessi in ogni sessione.
I browser potrebbero essere leggermente più protetti dagli attacchi Man-in-the-Middle. Su tutti i domini critici mail.ru, oltre a HTTPS, è abilitata la politica HSTS (HTTP strict Transport Security). Con HSTS abilitato, un browser moderno non offre all'utente un'opzione semplice per accettare un certificato falso, anche se l'utente lo desidera. Oltre a HSTS, gli utenti sono stati salvati dal fatto che dal 2017 i server SMTP, IMAP e POP3 di Mail.ru vietano il trasferimento di password su una connessione non protetta, tutti i nostri utenti hanno utilizzato TLS per l'accesso tramite SMTP, POP3 e IMAP e pertanto login e password possono essere intercettati solo se l'utente stesso accetta di accettare il certificato falsificato.
Per gli utenti mobili, consigliamo sempre di utilizzare le applicazioni Mail.ru per accedere alla posta, perché... lavorare con la posta al loro interno è più sicuro che nei browser o nei client SMTP/IMAP integrati.
Cosa fare
È necessario aggiornare il firmware MikroTik RouterOS a una versione sicura. Se per qualche motivo ciò non è possibile, è necessario filtrare il traffico sulla porta 8291 (tcp e udp), ciò complicherà lo sfruttamento del problema, anche se non eliminerà la possibilità di iniezione passiva nella cache DNS. Gli ISP dovrebbero filtrare questa porta sulle loro reti per proteggere gli utenti aziendali.
Tutti gli utenti che hanno accettato un certificato sostituito devono modificare urgentemente la password per la posta elettronica e gli altri servizi per i quali questo certificato è stato accettato. Da parte nostra, avviseremo gli utenti che accedono alla posta tramite dispositivi vulnerabili.
PS C'è anche una vulnerabilità correlata descritta nel post "".
Fonte: habr.com