Dans la soirée du 10 mars, le service d'assistance de Mail.ru a commencé à recevoir des plaintes d'utilisateurs concernant l'impossibilité de se connecter aux serveurs IMAP/SMTP de Mail.ru via des programmes de messagerie. Dans le même temps, certaines connexions n’ont pas abouti et certaines affichent une erreur de certificat. L'erreur est provoquée par le « serveur » qui émet un certificat TLS auto-signé.
En deux jours, plus de 10 plaintes ont été reçues d'utilisateurs sur divers réseaux et avec divers appareils, ce qui rend peu probable que le problème provienne du réseau d'un seul fournisseur. Une analyse plus détaillée du problème a révélé que le serveur imap.mail.ru (ainsi que d'autres serveurs et services de messagerie) est en cours de remplacement au niveau DNS. De plus, avec l'aide active de nos utilisateurs, nous avons découvert que la raison était une entrée incorrecte dans le cache de leur routeur, qui est également un résolveur DNS local, et qui dans de nombreux cas (mais pas tous) s'est avéré être le MikroTik. appareil, très populaire dans les petits réseaux d'entreprise et auprès des petits fournisseurs d'accès Internet.
Quel est le problème
En septembre 2019, les chercheurs plusieurs vulnérabilités dans MikroTik RouterOS (CVE-2019-3976, CVE-2019-3977, CVE-2019-3978, CVE-2019-3979), qui ont permis une attaque par empoisonnement du cache DNS, à savoir la possibilité d'usurper les enregistrements DNS dans le cache DNS du routeur, et CVE-2019-3978 permet à l'attaquant de ne pas attendre que quelqu'un du réseau interne demande une entrée sur son serveur DNS afin d'empoisonner le cache du résolveur, mais d'initier une telle une requête lui-même via le port 8291 (UDP et TCP). La vulnérabilité a été corrigée par MikroTik dans les versions de RouterOS 6.45.7 (stable) et 6.44.6 (long terme) le 28 octobre 2019, mais selon La plupart des utilisateurs n'ont pas encore installé de correctifs.
Il est évident que ce problème est désormais activement exploité « en direct ».
Pourquoi est-ce dangereux
Un attaquant peut usurper l'enregistrement DNS de n'importe quel hôte auquel accède un utilisateur sur le réseau interne, interceptant ainsi le trafic vers celui-ci. Si des informations sensibles sont transmises sans cryptage (par exemple via http:// sans TLS) ou si l'utilisateur accepte un faux certificat, l'attaquant peut obtenir toutes les données envoyées via la connexion, comme un identifiant ou un mot de passe. Malheureusement, la pratique montre que si un utilisateur a la possibilité d'accepter un faux certificat, il en profitera.
Pourquoi les serveurs SMTP et IMAP et ce qui a sauvé les utilisateurs
Pourquoi les attaquants ont-ils tenté d'intercepter le trafic SMTP/IMAP des applications de messagerie, et non le trafic Web, alors que la plupart des utilisateurs accèdent à leur courrier via un navigateur HTTPS ?
Tous les programmes de messagerie fonctionnant via SMTP et IMAP/POP3 ne protègent pas l'utilisateur contre les erreurs, l'empêchant d'envoyer son identifiant et son mot de passe via une connexion non sécurisée ou compromise, bien que ce soit selon la norme. , adoptés en 2018 (et implémentés dans Mail.ru bien plus tôt), ils doivent protéger l'utilisateur contre l'interception du mot de passe via toute connexion non sécurisée. De plus, le protocole OAuth est très rarement utilisé dans les clients de messagerie (il est pris en charge par les serveurs de messagerie Mail.ru), et sans lui, le login et le mot de passe sont transmis à chaque session.
Les navigateurs sont peut-être un peu mieux protégés contre les attaques Man-in-the-Middle. Sur tous les domaines critiques mail.ru, en plus de HTTPS, la politique HSTS (HTTP strict transport security) est activée. Avec HSTS activé, un navigateur moderne n'offre pas à l'utilisateur une option simple pour accepter un faux certificat, même s'il le souhaite. En plus de HSTS, les utilisateurs ont été sauvés par le fait que depuis 2017, les serveurs SMTP, IMAP et POP3 de Mail.ru interdisent le transfert de mots de passe via une connexion non sécurisée, tous nos utilisateurs ont utilisé TLS pour accéder via SMTP, POP3 et IMAP, et par conséquent, le login et le mot de passe ne peuvent être interceptés que si l'utilisateur lui-même accepte le certificat usurpé.
Pour les utilisateurs mobiles, nous recommandons toujours d'utiliser les applications Mail.ru pour accéder au courrier, car... travailler avec le courrier est plus sûr que dans les navigateurs ou les clients SMTP/IMAP intégrés.
Que faire
Il est nécessaire de mettre à jour le firmware MikroTik RouterOS vers une version sécurisée. Si pour une raison quelconque cela n'est pas possible, il est nécessaire de filtrer le trafic sur le port 8291 (tcp et udp), cela compliquera l'exploitation du problème, même si cela n'éliminera pas la possibilité d'une injection passive dans le cache DNS. Les FAI doivent filtrer ce port sur leurs réseaux pour protéger les utilisateurs de l'entreprise.
Tous les utilisateurs qui ont accepté un certificat de substitution doivent changer de toute urgence le mot de passe de la messagerie électronique et des autres services pour lesquels ce certificat a été accepté. De notre côté, nous informerons les utilisateurs qui accèdent au courrier via des appareils vulnérables.
PS Il existe également une vulnérabilité connexe décrite dans le message "".
Source: habr.com