[English]Im April 2021 hat Microsoft mit den kumulativen Updates eine Schwachstelle in seinen on-premises Exchange Servern beseitigt, über die Angreifer ohne Authentifizierung die Konfigurierung verändern konnten. So wäre es für einen nicht authentifizierten Angreifer möglich gewesen, die Konfiguration für Postfächer beliebiger Benutzer zu ändern. Damit hätten alle an ein E-Mail-Konto adressierten E-Mails kopiert und an ein vom Angreifer kontrolliertes Konto weitergeleitet werden können. Die Schwachstelle ist erst jetzt offen gelegt worden.
Anzeige
Entdeckt wurde die ProxyToken genannte Schwachstelle CVE-2021-33766, die einen CVE-Score von 6,5 aufweist, von Le Xuan Tuyen, einem vietnamesischen Sicherheitsforscher des VNPT ISC. Dieser hat das Ganze dann über die ZeroDay-Initiative gemeldet, wie aus nachfolgendem Tweet hervorgeht.
Im ZDI-Blog-Beitrag wird die Schwachstelle detaillierter beschrieben. Microsoft Exchange erstellt zwei Websites in IIS, ein Frontend und ein Backend.
- Frontend: Dies ist die Standard-Website, die die Ports 80 für HTTP und 443 für HTTPS überwacht und mit der sich alle Clients für den Webzugriff (OWA, ECP) sowie nach außen gerichtete Webdienste verbinden.
- Backend: Das "Exchange Back End" überwacht die Ports 81 für HTTP und 444 für HTTPS.
Das Frontend fungiert als Proxy, welches Anfragen an das Backend weiter reicht. Um den Zugriff zu ermöglichen, der eine Formularauthentifizierung erfordert, stellt das Frontend Seiten wie /owa/auth/logon.aspx zur Authentifizierung bereit. Bei allen Anfragen nach der Authentifizierung besteht die Hauptaufgabe des Frontends darin, die Anfragen neu zu verpacken und sie an die entsprechenden Endpunkte auf der Exchange-Backend-Site weiterzuleiten. Anschließend sammelt es die Antworten vom Back-End und leitet sie an den Client weiter.
Anzeige
Problem ist, dass Exchange eine Funktion namens "Delegierte Authentifizierung" für die Cross-Forest Topologien unterstützt. In solchen Bereitstellungen ist das Frontend nicht in der Lage, Authentifizierungsentscheidungen eigenständig zu treffen. Stattdessen leitet das Frontend Anforderungen direkt an das Backend weiter und verlässt sich darauf, dass das Backend feststellt, ob die Anforderung ordnungsgemäß authentifiziert ist. Diese Anfragen, die mithilfe der Backend-Logik authentifiziert werden sollen, werden durch das Vorhandensein eines SecurityToken-Cookies identifiziert.
Nun hat der Sicherheitsforscher Konstellationen gefunden, wo das Frontend anhand des SecurityToken-Cookie die Authentifizierung dieser Anfrage dem Backend überlässt. Das Backend weiß in bestimmten Situationen aber nicht, dass es einige eingehende Anfragen auf der Grundlage des SecurityToken-Cookies authentifizieren muss, da das DelegatedAuthModule in Installationen, die nicht für die Verwendung der speziellen delegierten Authentifizierungsfunktion konfiguriert wurden, nicht geladen ist. Das Ergebnis ist, dass Anfragen durchgehen können, ohne dass sie einer Authentifizierung auf dem Front- oder Back-End unterzogen werden.
Unter dem Strich hätte ein nicht authentifizierten Angreifer die Konfigurierung der Postfächer beliebiger Benutzer verändern und dessen Mails an ein vom Angreifer kontrolliertes Konto weitergeleitet werden können. Das setzt aber voraus, dass der Angreifer Kontrolle über das Zielkonto auf dem Exchange Server hat. Die komplexeren Details lassen sich im ZDI-Blog-Beitrag nachlesen. Die Schwachstelle wurde im März 2021 vom Sicherheitsforscher Le Xuan Tuyen der ZDI gemeldet, die das Ganze an Microsoft weitergereicht hat.
Die Schwachstelle wurde dann laut ZDI im Juni 2021 durch die Exchange CUs (Cumulative Updates) geschlossen. Microsoft hat in den betreffenden Supportartikeln selbst (siehe meinen Blog-Beitrag Kumulative Exchange Updates Juni 2021 veröffentlicht) keine Details genannt.
Allerdings gibt es diesen Kommentar von Microsoft-Mitarbeiter Nino Bilic, der darauf hinweist, dass CVE-2021-33766 bereits im April 2021 beseitigt wurde. Die Schwachstelle unterstreicht wieder einmal, wie wichtig es ist, seine Exchange Server-Installationen auf dem neuesten Patchstand zu halten.
Ähnliche Artikel:
Sicherheitsupdates für Exchange Server (Juli 2021)
Kumulative Exchange Updates Juni 2021 veröffentlicht
Exchange Server Security Update KB5001779 (13. April 2021)
Wichtige Hinweise Microsofts und des BSI zum Exchange-Server Sicherheitsupdate (März 2021)
Exchange-Probleme mit ECP/OWA-Suche nach Sicherheitsupdate (März 2021)
Exchange Sicherheitsupdates von Juli 2021 zerschießen ECP und OWA
Exchange 2016/2019: Outlook-Probleme durch AMSI-Integration
Angriffswelle, fast 2.000 Exchange-Server über ProxyShell gehackt
Exchange Server 2016-2019: Benutzerdefinierte Attribute in ECP nach CU-Installation (Juli 2021) nicht mehr aktualisierbar
Anzeige
Ich frage mich nur, welche Qualifikation die Entwickler im Exchange Team haben? Absolut erschreckend, welche Fehler ständig aufgedeckt werden.
Ich glaube das Problem sind nicht die Entwickler….sondern eher der gewucherte Code, der über die Jahre entstanden ist. Sehe es teilweise selbst. Der Entwickler kann noch so gut sein, aber der Zeitdruck, möglicherweise schlechte Koordination und das was vorher gemacht wurde, hinterlassen teilweise einen Programmhaufen, der unsauber ausschaut.
Man kann nur dringend an alle Entscheider appellieren Alternativen zu Exchange zu nutzen. Es gibt einige. Kolab (Open Source!) sei z.B. genannt. Monokultur sucks.
Wenn man sich den Verlauf der Twitter Unterhaltung anschaut, wurde das Problem sogar schon mit dem April Update gefixt.
Die Meldung hatte ich auch bekommen – ich hatte mich an die Verlautbarung des ZDI gehalten, die klar sagen, dass erst das Juni 2021 CU die Schwachstelle beseitigt. Inzwischen habe ich aber die Korrektur mit Verweis auf die Infos des MS-Mitarbeiters nachgetragen – danke für den Hinweis.