Le soir du 10 mars, le service d'assistance Mail.ru a commencé à recevoir des plaintes de la part des utilisateurs concernant l'incapacité de se connecter aux serveurs IMAP/SMTP de Mail.ru via des programmes de messagerie. Une partie des connexions échouait, tandis qu'une autre affichait une erreur de certificat. Cette erreur est causée par le fait que le « serveur » fournit un certificat TLS auto-signé.
En deux jours, plus de 10 plaintes ont été reçues de la part d'utilisateurs provenant de différents réseaux et utilisant divers appareils, rendant improbable un problème lié à 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 de messagerie et services) était falsifié au niveau DNS. Ensuite, avec l'aide active de nos utilisateurs, nous avons découvert que la cause était un enregistrement incorrect dans le cache de leur routeur, qui sert également de résolveur DNS local, et qui, dans de nombreux (mais pas tous) cas, était un appareil MikroTik, très populaire dans les petites entreprises et chez les petits fournisseurs Internet.
Quel est le problème
En septembre 2019, des chercheurs plusieurs vulnérabilités dans MikroTik RouterOS (CVE-2019-3976, CVE-2019-3977, CVE-2019-3978, CVE-2019-3979), qui permettaient de mener une attaque par empoisonnement du cache DNS, c'est-à-dire la possibilité de falsifier des enregistrements DNS dans le cache du routeur, et qui CVE-2019-3978 permet à l'attaquant de ne pas attendre qu'un membre du réseau interne demande un enregistrement à son serveur DNS pour empoisonner le cache du résolveur, mais d'initier lui-même cette requête via le port 8291 (UDP et TCP). La vulnérabilité a été corrigée par MikroTik dans les versions RouterOS 6.45.7 (stable) et 6.44.6 (long terme) le 28 octobre 2019, cependant, selon la plupart des utilisateurs n'ont pas encore installé les correctifs.
Il est évident que cette problématique est actuellement exploitée activement « en direct ».
Quels sont les dangers
L'attaquant peut falsifier un enregistrement DNS de n'importe quel hôte auquel un utilisateur du réseau interne accède, capturant ainsi le trafic destiné à celui-ci. Si des informations sensibles sont transmises sans chiffrement (par exemple, via http:// sans TLS) ou si l'utilisateur accepte un certificat falsifié, l'attaquant peut obtenir toutes les données envoyées par la connexion, par exemple, un identifiant ou un mot de passe. Malheureusement, la pratique montre que si un utilisateur a la possibilité d'accepter un certificat falsifié, il en profitera.
Pourquoi précisément les serveurs SMTP et IMAP, et ce qui a protégé les utilisateurs
Pourquoi les attaquants ont-ils essayé d'intercepter le trafic SMTP/IMAP des applications de messagerie plutôt que le trafic web, alors que la plupart des utilisateurs accèdent à leur messagerie via un navigateur en HTTPS ?
Tous les programmes de messagerie utilisant SMTP et IMAP/POP3 ne protègent pas l'utilisateur contre les erreurs, permettant d'envoyer le nom d'utilisateur et le mot de passe via une connexion non sécurisée ou compromise, malgré la norme. , adoptée en 2018 (et mise en œuvre dans Mail.ru bien plus tôt), devrait empêcher l'utilisateur d'être exposé à l'interception de mots 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 cela, le nom d'utilisateur et le mot de passe sont transmis à chaque session.
Les navigateurs peuvent être légèrement mieux protégés contre les attaques de type Man-in-the-Middle. Sur tous les domaines critiques de mail.ru, une politique HSTS (HTTP strict transport security) est activée en plus du HTTPS. Avec HSTS activé, un navigateur moderne ne permet pas à l'utilisateur d'accepter facilement un certificat falsifié, même s'il le souhaite. En outre, les utilisateurs bénéficiaient du fait que depuis 2017, les serveurs SMTP, IMAP et POP3 de Mail.ru interdisent la transmission de mots de passe via une connexion non sécurisée, tous nos utilisateurs utilisaient TLS pour accéder à SMTP, POP3 et IMAP, et donc le nom d'utilisateur et le mot de passe ne peuvent être interceptés que si l'utilisateur accepte lui-même d'accepter un certificat compromis.
Pour les utilisateurs mobiles, nous recommandons toujours d'utiliser les applications Mail.ru pour accéder à la messagerie, car leur utilisation est plus sécurisée que via des navigateurs ou des clients SMTP/IMAP intégrés.
Que faut-il faire
Il est nécessaire de mettre à jour le système 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), ce qui compliquera l'exploitation du problème, bien que cela n'élimine pas la possibilité d'injection passive dans le cache DNS. Les fournisseurs d'accès Internet devraient filtrer ce port dans leurs réseaux pour protéger les utilisateurs d'entreprise.
Tous les utilisateurs ayant accepté le certificat falsifié doivent changer d'urgence leur mot de passe de messagerie et d'autres services associés à ce certificat. De notre côté, nous informerons les utilisateurs qui accèdent à leur messagerie via des dispositifs vulnérables.
P.S. Il existe également une vulnérabilité associée décrite dans le post. "".
Source : habr.com
