A sera di u 10 di marzu, u serviziu di supportu Mail.ru hà cuminciatu à riceve lagnanze da l'utilizatori nantu à l'incapacità di cunnette à i servitori IMAP / SMTP di Mail.ru per mezu di i prugrammi di e-mail. À u listessu tempu, certi cunnessione ùn anu micca passatu, è certi mostranu un errore di certificatu. L'errore hè causatu da u "servitore" chì emette un certificatu TLS autofirmatu.
In dui ghjorni, più di 10 reclami sò ghjunti da l'utilizatori nantu à una varietà di rete è cù una varietà di dispusitivi, facendu improbabile chì u prublema era in a reta di qualsiasi fornitore. Un analisi più detallatu di u prublema hà revelatu chì u servitore imap.mail.ru (cum'è altri servitori di mail è servizii) hè rimpiazzatu à u livellu DNS. In più, cù l'aiutu attivu di i nostri utilizatori, avemu trovu chì u mutivu era una entrata incorrecta in u cache di u so router, chì hè ancu un risolve DNS locale, è chì in parechji (ma micca in tutti) casi hè diventatu MikroTik. dispusitivu, assai populari in e piccule rete corporative è da i picculi fornitori di Internet.
Chì ghjè u prublema
In settembre 2019, circadori parechje vulnerabilità in MikroTik RouterOS (CVE-2019-3976, CVE-2019-3977, CVE-2019-3978, CVE-2019-3979), chì permettenu un attaccu di avvelenamentu di cache DNS, i.e. l'abilità di spoof records DNS in a cache DNS di u router, è CVE-2019-3978 permette à l'attaccante di ùn aspittà micca chì qualchissia da a reta interna per dumandà una entrata in u so servitore DNS per avvelenà a cache di risolve, ma per inizià tali. una dumanda ellu stessu attraversu u portu 8291 (UDP è TCP). A vulnerabilità hè stata fissata da MikroTik in versioni di RouterOS 6.45.7 (stabile) è 6.44.6 (a longu andà) u 28 ottobre 2019, ma secondu A maiò parte di l'utilizatori ùn anu micca attualmente installatu patches.
Hè ovvi chì stu prublema hè issa sfruttatu attivamente "live".
Perchè hè periculosa
Un attaccu pò spoof u record DNS di qualsiasi òspite accessatu da un utilizatore in a reta interna, interceptendu cusì u trafficu. Se l'infurmazione sensitiva hè trasmessa senza criptografia (per esempiu, nantu à http: // senza TLS) o l'utilizatore accunsenu à accettà un certificatu falsu, l'attaccante pò ottene tutte e dati chì sò mandati per a cunnessione, cum'è un login o password. Sfurtunatamente, a pratica mostra chì, se un utilizatore hà l'uppurtunità di accettà un certificatu falsu, ne prufittarà.
Perchè i servitori SMTP è IMAP, è ciò chì hà salvatu l'utilizatori
Perchè l'attaccanti anu pruvatu à intercepte u trafficu SMTP / IMAP di l'applicazioni di e-mail, è micca u trafficu web, ancu chì a maiò parte di l'utilizatori accede à u so mail via u navigatore HTTPS?
Ùn sò micca tutti i prugrammi di e-mail chì travaglianu via SMTP è IMAP / POP3 prutegge l'utilizatore da l'errori, impediscendu di mandà login è password attraversu una cunnessione micca assicurata o cumprumessa, ancu se secondu u standard. , aduttatu torna in 2018 (è implementatu in Mail.ru assai prima), anu da prutege l'utilizatore da l'intercepzione di password attraversu ogni cunnessione micca sicura. Inoltre, u protocolu OAuth hè assai raramente utilizatu in i clienti di email (hè supportatu da i servitori di mail Mail.ru), è senza ellu, u login è a password sò trasmessi in ogni sessione.
I navigatori ponu esse un pocu megliu prutetti contr'à attacchi Man-in-the-Middle. In tutti i domini critichi mail.ru, in più di HTTPS, a pulitica HSTS (HTTP strict transport security) hè attivata. Cù HSTS attivatu, un navigatore mudernu ùn dà à l'utilizatore una opzione faciule per accettà un certificatu falsu, ancu s'ellu vole. In più di HSTS, l'utilizatori sò stati salvati da u fattu chì da u 2017, i servitori SMTP, IMAP è POP3 di Mail.ru pruibiscenu u trasferimentu di password nantu à una cunnessione micca sicura, tutti i nostri utilizatori anu utilizatu TLS per accessu via SMTP, POP3 è IMAP, è dunque u login è a password ponu intercepte solu se l'utilizatore stessu accunsente à accettà u certificatu spoofed.
Per l'utilizatori mobili, ricumandemu sempre di utilizà l'applicazioni Mail.ru per accede à u mail, perchè ... U travagliu cù mail in elli hè più sicuru ch'è in i navigatori o i clienti SMTP / IMAP integrati.
Cosa da fà
Hè necessariu aghjurnà u firmware MikroTik RouterOS à una versione sicura. Se per qualchì mutivu ùn hè micca pussibule, hè necessariu di filtrà u trafficu in u portu 8291 (tcp è udp), questu complicà a sfruttamentu di u prublema, ancu s'ellu ùn eliminà micca a pussibilità di iniezione passiva in u cache DNS. L'ISP deve filtrà stu portu nantu à e so rete per prutege l'utilizatori corporativi.
Tutti l'utilizatori chì accettanu un certificatu sustituitu anu da cambià urgentemente a password per l'email è altri servizii per i quali stu certificatu hè statu accettatu. Per a nostra parte, avemu da avvisà l'utilizatori chì accede à u mail attraversu i dispositi vulnerabili.
P.S. Ci hè ancu una vulnerabilità ligata descritta in u post "".
Source: www.habr.com