On the evening of March 10, the Mail.ru support service began receiving complaints from users about the inability to connect to Mail.ru's IMAP/SMTP servers through email programs. At the same time, some of the connections did not go through, and some show a certificate error. The error is caused by the "server" giving a self-signed TLS certificate.
In two days, more than 10 complaints came from users on a wide variety of networks and with a wide variety of devices, which made it unlikely that the problem was in the network of any one provider. A more detailed analysis of the problem revealed that the imap.mail.ru server (as well as other mail servers and services) is being replaced at the DNS level. Further, with the active help of our users, we found that the reason was an incorrect entry in the cache of their router, which is also a local DNS resolver, and which in many (but not all) cases turned out to be a MikroTik device, very popular in small corporate networks and from small Internet providers.
What is the problem
In September 2019, researchers several vulnerabilities in MikroTik RouterOS (CVE-2019-3976, CVE-2019-3977, CVE-2019-3978, CVE-2019-3979) that allowed DNS cache poisoning attacks, i.e. the possibility of replacing DNS records in the DNS cache of the router, and CVE-2019-3978 allows the attacker not to wait until someone from the internal network requests a record on his DNS server in order to poison the resolver cache, but to initiate such a request himself through the port 8291 (UDP and TCP). The vulnerability was fixed by MikroTik in RouterOS 6.45.7 (stable) and 6.44.6 (long-term) versions on October 28, 2019, however, according to most users have not installed patches at the moment.
It is obvious that now this problem is actively exploited "live".
Why is it dangerous
An attacker can change the DNS record of any host accessed by an internal network user, thus intercepting traffic to it. If sensitive information is transmitted without encryption (for example, over http:// without TLS) or the user agrees to accept a fake certificate, an attacker can get all the data that is sent over the connection, such as a username or password. Unfortunately, practice shows that if the user has the opportunity to accept a fake certificate, then he will use it.
Why exactly SMTP and IMAP servers, and what saved users
Why did the attackers try to intercept the SMTP/IMAP traffic of mail applications, and not web traffic, although most users go to mail with a browser over HTTPS?
Not all SMTP and IMAP/POP3 mail programs protect the user from error by not allowing him to send a login and password through an insecure or compromised connection, although according to the standard , adopted back in 2018 (and implemented in Mail.ru much earlier), they should protect the user from password interception through any insecure connection. In addition, the OAuth protocol is very rarely used in mail clients (it is supported by Mail.ru mail servers), and without it, the login and password are transmitted in each session.
Browsers can be a little better protected against Man-in-the-Middle attacks. On all critical mail.ru domains, in addition to HTTPS, the HSTS (HTTP strict transport security) policy is enabled. With HSTS enabled, a modern browser doesn't give the user an easy option to accept a fake certificate, even if the user wants to. In addition to HSTS, users were saved by the fact that since 2017, Mail.ru's SMTP, IMAP and POP3 servers prohibit the transmission of a password over an insecure connection, all of our users used TLS for access via SMTP, POP3 and IMAP, and therefore the login and password can be intercept only if the user himself agrees to accept the spoofed certificate.
For mobile users, we always recommend that you use the Mail.ru apps to access your mail. working with mail in them is safer than in browsers or built-in SMTP / IMAP clients.
What should be done
It is necessary to update the MikroTik RouterOS firmware to a safe version. If for some reason this is not possible, it is necessary to filter traffic on port 8291 (tcp and udp), this will make the problem more difficult to exploit, although it will not eliminate the possibility of passive injection into the DNS cache. ISPs should filter this port on their networks to protect corporate users.
All users who accepted a spoofed certificate should urgently change the password of e-mail and other services for which this certificate was accepted. For our part, we will notify users who access mail through vulnerable devices.
PS There is another related vulnerability described in the post "".
Source: habr.com