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
