Am Abend des 10. März gingen beim Support von Mail.ru Beschwerden von Benutzern ein, dass es nicht möglich sei, über E-Mail-Programme eine Verbindung zu den IMAP/SMTP-Servern von Mail.ru herzustellen. Gleichzeitig konnten einige Verbindungen nicht hergestellt werden und bei einigen wurde ein Zertifikatsfehler angezeigt. Der Fehler wird dadurch verursacht, dass der „Server“ ein selbstsigniertes TLS-Zertifikat ausstellt.
Innerhalb von zwei Tagen gingen mehr als 10 Beschwerden von Benutzern aus verschiedenen Netzwerken und mit verschiedenen Geräten ein, sodass es unwahrscheinlich ist, dass das Problem im Netzwerk eines einzelnen Anbieters lag. Eine detailliertere Analyse des Problems ergab, dass der Server imap.mail.ru (sowie andere Mailserver und -dienste) auf DNS-Ebene ersetzt wird. Darüber hinaus haben wir mit der aktiven Hilfe unserer Benutzer herausgefunden, dass die Ursache ein falscher Eintrag im Cache ihres Routers war, der auch ein lokaler DNS-Resolver ist und der sich in vielen (aber nicht allen) Fällen als MikroTik herausstellte Gerät, das in kleinen Unternehmensnetzwerken und bei kleinen Internetanbietern sehr beliebt ist.
Was ist das Problem
Im September 2019 haben Forscher mehrere Schwachstellen in MikroTik RouterOS (CVE-2019-3976, CVE-2019-3977, CVE-2019-3978, CVE-2019-3979), die einen DNS-Cache-Poisoning-Angriff ermöglichten, d. h. die Möglichkeit, DNS-Einträge im DNS-Cache des Routers zu fälschen, und CVE-2019-3978 ermöglicht es dem Angreifer, nicht darauf zu warten, bis jemand aus dem internen Netzwerk einen Eintrag auf seinem DNS-Server anfordert, um den Resolver-Cache zu vergiften, sondern einen solchen zu initiieren selbst eine Anfrage über den Port 8291 (UDP und TCP). Die Schwachstelle wurde von MikroTik in den Versionen von RouterOS 6.45.7 (stabil) und 6.44.6 (langfristig) am 28. Oktober 2019 behoben, aber laut Die meisten Benutzer haben derzeit keine Patches installiert.
Es ist offensichtlich, dass dieses Problem nun aktiv „live“ ausgenutzt wird.
Warum ist es gefährlich
Ein Angreifer kann den DNS-Eintrag jedes Hosts fälschen, auf den ein Benutzer im internen Netzwerk zugreift, und so den Datenverkehr zu diesem Host abfangen. Wenn vertrauliche Informationen unverschlüsselt übertragen werden (z. B. über http:// ohne TLS) oder der Benutzer der Annahme eines gefälschten Zertifikats zustimmt, kann der Angreifer an alle Daten gelangen, die über die Verbindung gesendet werden, beispielsweise einen Benutzernamen oder ein Passwort. Leider zeigt die Praxis, dass ein Benutzer, wenn er die Möglichkeit hat, ein gefälschtes Zertifikat zu akzeptieren, diese ausnutzt.
Warum SMTP- und IMAP-Server und was Benutzer gerettet haben
Warum versuchten die Angreifer, den SMTP/IMAP-Verkehr von E-Mail-Anwendungen und nicht den Webverkehr abzufangen, obwohl die meisten Benutzer über einen HTTPS-Browser auf ihre E-Mails zugreifen?
Nicht alle E-Mail-Programme, die über SMTP und IMAP/POP3 arbeiten, schützen den Benutzer vor Fehlern und verhindern, dass er Login und Passwort über eine ungesicherte oder kompromittierte Verbindung sendet, obwohl dies dem Standard entspricht Sie wurden bereits 2018 eingeführt (und viel früher in Mail.ru implementiert) und müssen den Benutzer vor dem Abfangen von Passwörtern über jede ungesicherte Verbindung schützen. Darüber hinaus wird das OAuth-Protokoll in E-Mail-Clients sehr selten verwendet (es wird von Mail.ru-Mailservern unterstützt) und ohne es werden der Benutzername und das Passwort in jeder Sitzung übertragen.
Browser sind möglicherweise etwas besser gegen Man-in-the-Middle-Angriffe geschützt. Auf allen kritischen Mail.ru-Domänen ist zusätzlich zu HTTPS die HSTS-Richtlinie (HTTP strict transport security) aktiviert. Wenn HSTS aktiviert ist, bietet ein moderner Browser dem Benutzer keine einfache Möglichkeit, ein gefälschtes Zertifikat zu akzeptieren, selbst wenn der Benutzer dies möchte. Zusätzlich zu HSTS wurden Benutzer dadurch gerettet, dass seit 2017 die SMTP-, IMAP- und POP3-Server von Mail.ru die Übertragung von Passwörtern über eine ungesicherte Verbindung verbieten, alle unsere Benutzer TLS für den Zugriff über SMTP, POP3 und IMAP verwendeten und Daher können Login und Passwort nur abgefangen werden, wenn der Benutzer selbst zustimmt, das gefälschte Zertifikat zu akzeptieren.
Für mobile Benutzer empfehlen wir immer die Verwendung von Mail.ru-Anwendungen für den Zugriff auf E-Mails, weil... Das Arbeiten mit E-Mails ist darin sicherer als in Browsern oder integrierten SMTP/IMAP-Clients.
Was zu tun ist
Es ist notwendig, die MikroTik RouterOS-Firmware auf eine sichere Version zu aktualisieren. Wenn dies aus irgendeinem Grund nicht möglich ist, muss der Datenverkehr auf Port 8291 (TCP und UDP) gefiltert werden. Dies erschwert die Ausnutzung des Problems, schließt jedoch nicht die Möglichkeit einer passiven Injektion in den DNS-Cache aus. ISPs sollten diesen Port in ihren Netzwerken filtern, um Unternehmensbenutzer zu schützen.
Alle Benutzer, die ein Ersatzzertifikat akzeptiert haben, sollten dringend das Passwort für E-Mail und andere Dienste ändern, für die dieses Zertifikat akzeptiert wurde. Wir werden unsererseits Benutzer benachrichtigen, die über anfällige Geräte auf E-Mails zugreifen.
PS Es gibt auch eine entsprechende Sicherheitslücke, die im Beitrag beschrieben wird "".
Source: habr.com