Get best of the week

Update RouterOS on your MikroTik


On the evening of March 10, Mail.ru support service began to receive complaints from users about the inability to connect to Mail.ru IMAP / SMTP servers through email programs. At the same time, some of the connections did not pass, and some show a certificate error. The error is caused by the fact that the “server” issues a self-signed TLS certificate.
 

In two days, more than 10 complaints came from users from a variety of networks and with a variety of devices, which made it unlikely that a single provider would have a problem on the network. A more detailed analysis of the problem revealed that there is a substitution of the imap.mail.ru server (as well as other mail servers and services) at the DNS level. Further, with the active assistance of our users, we found that the reason was an incorrect entry in the cache of their router, which in combination is a local DNS resolver, and which in many (but not all) cases turned out to be the MikroTik device, which is very popular in small corporate networks and at small Internet providers.

What is the problem


In September 2019, researchers found several vulnerabilities in the MikroTik RouterOS (CVE-2019-3976, CVE-2019-3977, CVE-2019-3978, CVE-2019-3979) that allowed the DNS cache poisoning attack, i.e. the ability to spoof DNS records in the router’s DNS cache, and CVE-2019-3978 allows an attacker not to wait for someone from the internal network to ask for a record on his DNS server to poison the resolver cache, but to initiate such a request through the port itself 8291 (UDP and TCP). The vulnerability was fixed by MikroTik in versions of RouterOS 6.45.7 (stable) and 6.44.6 (long-term) on October 28, 2019, however, according to studies, most users have not installed patches at the moment.

It is obvious that now this problem is being actively exploited “live”.

Why is it dangerous


An attacker can replace the DNS record of any host accessed by a user on the internal network, thus intercepting traffic to him. If sensitive information is transmitted without encryption (for example, via http: // without TLS) or the user agrees to accept a fake certificate, the attacker can receive all the data that is sent through the connection, for example, login or password. Unfortunately, practice shows that if a user has the opportunity to accept a fake certificate, then he will use it.

Why SMTP and IMAP servers, and what saved users


Why did the attackers try to intercept the SMTP / IMAP traffic of the mail applications, and not the web traffic, although most of the users go to the mail via HTTPS browser?

Not all SMTP and IMAP / POP3 mail programs protect the user from errors by not allowing him to send a username and password through an insecure or compromised connection, although according to the RFC 8314 standard adopted back in 2018 (and implemented in Mail.ru much earlier), they should protect the user from intercepting a password through any insecure connection. In addition, while OAuth protocol is very rarely used in email clients (it is supported by Mail.ru mail servers), without it, the login and password are transmitted in each session.

Browsers may be slightly better protected from Man-in-the-Middle attacks. On all critical mail.ru domains, in addition to HTTPS, the HSTS (HTTP strict transport security) policy is included. When HSTS is enabled, a modern browser does not give the user a simple opportunity to accept a fake certificate, even if the user wants it. In addition to HSTS, users were saved by the fact that since 2017, the Mail.ru SMTP, IMAP and POP3 servers prohibit password transmission through an insecure connection, all our users used TLS to access via SMTP, POP3 and IMAP, and therefore you can login and password intercept only if the user himself agrees to accept the spoofed certificate.

For mobile users, we always recommend using Mail.ru applications to access mail, as working with mail in them is safer than in browsers or built-in SMTP / IMAP clients.

What should be done


You need to update the MikroTik RouterOS firmware to a safe version. If for some reason this is not possible, it is necessary to filter out traffic on port 8291 (tcp and udp), this will complicate the operation of the problem, although it will not eliminate the possibility of passive injection into the DNS cache. Internet service providers should filter this port on their networks to protect corporate users. 

All users who accepted a forged certificate should urgently change the password of email and other services for which this certificate was accepted. For our part, we will notify users who enter the mail through vulnerable devices.

PS There is still a related vulnerability described in the postLukaSafonov" Backport vulnerability in RouterOS threatens hundreds of thousands of devices ."

More articles:


All Articles