Am Abend des 10. März erhielt der Supportdienst von Mail.ru zahlreiche Beschwerden von Nutzern über die Unmöglichkeit, sich über E-Mail-Programme mit den IMAP-/SMTP-Servern von Mail.ru zu verbinden. Dabei konnten einige Verbindungen nicht hergestellt werden, während andere einen Zertifikatfehler anzeigten. Der Fehler wurde durch die Tatsache verursacht, dass der "Server" ein selbstsigniertes TLS-Zertifikat ausgibt.
Innerhalb von zwei Tagen gingen über 10 Beschwerden von Nutzern aus den unterschiedlichsten Netzwerken und mit den verschiedensten Geräten ein, was ein Problem im Netzwerk eines einzelnen Anbieters unwahrscheinlich machte. Eine genauere Untersuchung des Problems ergab, dass der Server imap.mail.ru (sowie andere E-Mail-Server und -Dienste) auf DNS-Ebene manipuliert wurde. Weiterhin fanden wir mit aktiver Unterstützung unserer Nutzer heraus, dass die Ursache in einem falschen Eintrag im Cache ihres Routers lag, der gleichzeitig als lokaler DNS-Resolver fungiert. In vielen (aber nicht allen) Fällen stellte sich heraus, dass es sich um ein MikroTik-Gerät handelt, das in kleinen Unternehmensnetzwerken und bei kleinen Internetanbietern sehr beliebt ist.
Was ist das Problem
Im September 2019 fanden Forscher untersuchungen Offensichtlich wird dieses Problem derzeit aktiv "in der Wildnis" ausgenutzt.
Warum ist das gefährlich
Ein Angreifer kann den DNS-Eintrag eines beliebigen Hosts, den ein Nutzer im internen Netzwerk aufruft, manipulieren und so den Datenverkehr zu diesem Host abfangen. Wenn sensitive Informationen ohne Verschlüsselung übertragen werden (z.B. über http:// ohne TLS) oder der Nutzer zustimmt, ein gefälschtes Zertifikat zu akzeptieren, kann der Angreifer alle Daten, die über die Verbindung gesendet werden, wie Benutzernamen oder Passwörter, abfangen. Leider zeigt die Praxis, dass wenn ein Nutzer die Möglichkeit hat, ein gefälschtes Zertifikat zu akzeptieren, er dies auch tun wird.
Ein Angreifer kann den DNS-Eintrag eines beliebigen Hosts, auf den ein Nutzer im internen Netzwerk zugreift, ersetzen und damit den Verkehr zu diesem Host abfangen. Wenn sensible Informationen unverschlüsselt übertragen werden (zum Beispiel über http:// ohne TLS) oder der Nutzer bereit ist, ein gefälschtes Zertifikat anzunehmen, kann der Angreifer alle Daten, die über die Verbindung gesendet werden, wie beispielsweise Anmeldedaten oder Passwörter, abfangen. Leider zeigt die Praxis, dass, wenn ein Nutzer die Möglichkeit hat, ein gefälschtes Zertifikat zu akzeptieren, er dies auch tun wird.
Warum gerade SMTP- und IMAP-Server und was schützte die Nutzer?
Warum haben Angreifer versucht, gerade den SMTP/IMAP-Datenverkehr von E-Mail-Anwendungen abzufangen und nicht den Webverkehr, obwohl die meisten Nutzer ihre E-Mails über den Browser mit HTTPS abrufen?
Nicht alle E-Mail-Programme, die über SMTP und IMAP/POP3 arbeiten, schützen den Nutzer vor Fehlern, indem sie ihm nicht erlauben, Benutzername und Passwort über eine unsichere oder kompromittierte Verbindung zu senden, obwohl dies nach dem Standard , der bereits 2018 verabschiedet wurde (und bei Mail.ru viel früher umgesetzt wurde), erforderlich ist. Sie sollten die Nutzer vor dem Abfangen des Passworts über jede ungesicherte Verbindung schützen. Darüber hinaus wird in E-Mail-Clients immer noch sehr selten das OAuth-Protokoll verwendet (es wird von den Mail.ru-Servers unterstützt), und ohne dieses werden Benutzername und Passwort bei jeder Sitzung übertragen.
Browser können etwas besser vor Man-in-the-Middle-Angriffen geschützt sein. Auf allen kritischen mail.ru-Domänen ist zusätzlich zu HTTPS die HSTS-Politik (HTTP Strict Transport Security) aktiviert. Wenn HSTS aktiviert ist, erlaubt es ein moderner Browser dem Nutzer nicht, ein gefälschtes Zertifikat einfach zu akzeptieren, selbst wenn der Nutzer dies möchte. Neben HSTS wurde die Nutzer auch dadurch geschützt, dass seit 2017 die SMTP-, IMAP- und POP3-Server von Mail.ru die Passwortübermittlung über ungesicherte Verbindungen verbieten. Alle unsere Nutzer verwendeten TLS für den Zugriff über SMTP, POP3 und IMAP, und daher kann Benutzername und Passwort nur dann abgefangen werden, wenn der Nutzer selbst zustimmt, ein manipuliertes Zertifikat zu akzeptieren.
Für mobile Nutzer empfehlen wir immer, die Mail.ru-Anwendungen für den Zugriff auf E-Mails zu verwenden, da die Arbeit mit E-Mails darin sicherer ist als in Browsern oder integrierten SMTP/IMAP-Clients.
Was zu tun ist
Es ist notwendig, die Firmware MikroTik RouterOS auf eine sichere Version zu aktualisieren. Wenn dies aus irgendwelchen Gründen nicht möglich ist, muss der Datenverkehr über den Port 8291 (tcp und udp) gefiltert werden, was die Ausnutzung des Problems erschwert, aber die Möglichkeit einer passiven Injektion in den DNS-Cache nicht beseitigt. Internetanbieter sollten diesen Port in ihren Netzwerken filtern, um Unternehmensnutzer zu schützen.
Alle Benutzer, die ein gefälschtes Zertifikat akzeptiert haben, sollten umgehend ihr Passwort für E-Mail und andere Dienste, für die dieses Zertifikat angenommen wurde, ändern. Von unserer Seite aus werden wir die Benutzer benachrichtigen, die über verwundbare Geräte auf ihre E-Mails zugreifen.
P.S. Es gibt noch eine verwandte Sicherheitsanfälligkeit, die im Beitrag beschrieben ist. "".
Quelle: habr.com
