Das nächste Exchange Security Thema

[NorbertFe 2.067]

https://www.borncity.com/blog/2021/09/22/microsoft-exchange-autodiscover-designfehler-ermglicht-abgriff-von-zugangsdaten/

https://therecord.media/microsoft-exchange-autodiscover-bug-leaks-hundreds-of-thousands-of-domain-credentials/

 

Warten wir mal ab, was an Empfehlungen usw. kommen wird (abgesehen von O365 ist nicht betroffen ;)) Wobei ich mir das auch nicht vorstellen kann.

[winmadness 79]

Ich kann das Verhalten nicht nachvollziehen. Ich habe mit dem Profil-Manager von Outlook 2016 sowohl ein Exchange als auch ein ActiveSync Profil mit Testdaten und unserer Domain firma.com angelegt. Über den ESET Virenscanner die Firewall auf "Interaktiver Modus" eingestellt, so dass alle angefragten Domain zur Freigabe angezeigt werden. Unsere Autodiscover Domain autodiscover.firma.com entsprechend blockiert, damit keine Einrichtung des Kontos möglich ist.

Es wurde in keinem Testfall die Domain autodiscover.com angefragt, immer nur Domain / Subdomain firma.com. Mache im beim Testen etwas falsch bzw. kann jemand von euch die Sicherheitslücke nachvollziehen? Könnte es sein, dass nur ältere Versionen von MS Outlook betroffen sind?

 

[cj_berlin 1.329]

Bisher konnte ich das Verhalten hier mit Outlook 2016 und einem Android-Smartphone nicht nachstellen.

[NorbertFe 2.067]

Hi,

ich vermute mal, dass das auch nicht unbedingt nur Outlook betrifft, sondern beliebige Autodiscover Clients. Im Artikel ist ja auch bspw. auf 2017 verlinkt wo dieser Fehler schon in Samsungs und Apples Mailapp aufgetreten ist. Wäre also wirklich interessant, welche Clients da so ankommen und betroffen sind.

[winmadness 79]

Danke für das Feedback. Ich habe eine ausführliche Beschreibung der Sicherheitslücke unter https://www.guardicore.com/labs/autodiscovering-the-great-leak/  gefunden. In dem Auszug aus dem Webserver Protokoll ist die Outlook Version zu sehen - Windows 10 mit MS Office 2016 bzw. 2019 bzw. Microsoft 365 (sofern ich das richtig interpretiere):

Zitat

Windows+NT+10.0;+Microsoft+Outlook+16.0.13901;+Pro

 

Nachtrag:

Unter https://docs.microsoft.com/de-de/officeupdates/update-history-office-2019 habe ich Infos bzgl. der Buildnummer 13901 gefunden. Diese betreffen die MS Office 2016 / 2019 Version im Zeitraum April / März 2021

bearbeitet 23. September 2021 von winmadness
Versionsinfo

[NorbertFe 2.067]

Stellt sich halt die Frage, was die anders machen, als ihr aktuell? :)

 

 

Mal als Frage in die Runde: Das Blocken von autodiscover.tld-irgendwas an der Firewall dürfte ja eh für die Katz sein. Im internen Netz müßte schon einiges kompromittiert sein, dass das dann noch hilft. Und fremde Clients sind mir im Zweifel egal. Also ginge das wenn überhaupt nur per Endpoint Security (auf den Geräten die man in der Verwaltung hat), aber alle anderen Clients und Gerätschaften, auf denen man Passwort und Mailadresse/Username eintragen kann, sind dann immer noch dabei.

bearbeitet 23. September 2021 von NorbertFe

[winmadness 79]

vor 6 Minuten schrieb NorbertFe:

Stellt sich halt die Frage, was die anders machen, als ihr aktuell? :)

Wenn ich mir die Screenshots des Profil Managers und die Beschreibung anschaue, finde ich keinen Unterschied zu meinem Tests. Bzw. spiegeln meine Tests unsere Routine beim Einrichten eines Exchange Kontos wieder. Lediglich die MS Office Version unterscheidet sich. Ich benutze natürlich den aktuellen Build 16.0.5215, die Sicherheitsforscher 16.0.13901.

Ich habe bei meinen Tests auch die unverschlüsselte Einrichtung des Profils getestet. Darauf bezieht sich die Sicherheitslücke mit der Übermittlung der Account-Daten über Port 80. Beim Einrichten eines Exchange Profils würde man natürlich die Abfrage nach einem unverschlüsselten Einrichten des Kontos (nach Fehlschlag der verschlüsselten Verbindung) nicht durchführen, sondern auf Fehlersuche gehen.

bearbeitet 23. September 2021 von winmadness

[NorbertFe 2.067]

Wäre ja nicht das erste Mal, dass MS das schon fixt während es hochkommt. ;) Ich denke Outlook und MS Clients sind vermutlich sowieso die einzigen Stellen an denen MS kurzfristig ansetzen kann. Der "arme Exchange" kann ja eigentlich gar nix dafür. ;)

 

Ich zitiere mal auf dem Heise Artikel:

Zitat

Admins, die nicht auf die, erfahrungsgemäß eher zähen, Versuche zur Absicherung des Protokolls durch Microsoft warten wollen (vergleiche die Konsequenzen beim großen Exchange-Hack Anfang des Jahres), sollten die Konfiguration ihrer Netzwerke absichern. Die Guardicore-Forscher empfehlen, Firewall-Regeln so anzupassen, dass alle Anfragen an autodiscover.TLD-Domains geblockt werden. Dafür stellen die Forscher eine Liste entsprechender gefährlicher Domains auf GitHub bereit.

Außerdem sollte bei der Konfiguration von Exchange die einfache HTTP-Authentifizierung deaktiviert werden, damit Anmeldedaten nicht im Klartext verschickt werden.

Ja Standard-Auth is doof, aber das löst doch das Problem nicht, wenn ich das an meinem Exchange deaktiviere. Und die Firewall-Rules, siehe oben. Das bringts doch auch nicht unbedingt, oder?

bearbeitet 23. September 2021 von NorbertFe

[cj_berlin 1.329]

vor 8 Minuten schrieb NorbertFe:

Stellt sich halt die Frage, was die anders machen, als ihr aktuell? :)

Die wollen in die Zeitung  

[winmadness 79]

vor 2 Minuten schrieb NorbertFe:

Wäre ja nicht das erste Mal, dass MS das schon fixt während es hochkommt. ;) Ich denke Outlook und MS Clients sind vermutlich sowieso die einzigen Stellen an denen MS kurzfristig ansetzen kann. Der "arme Exchange" kann ja eigentlich gar nix dafür. ;)

Sehe ich genau so. Deshalb bin ich etwas verwundert über die "Alarmmeldung". Entweder das Testszenario ist nicht sauber beschrieben oder der Fehler wurde bereits behoben.

[NorbertFe 2.067]

Ich vermute Alarm wegen Exchange!!!11EinsElf

Was definitiv nicht das Problem kleinreden soll. Denn das Verhalten ist definitiv ein Problem, hat aber meiner aktuell Meinung nach nur deswegen überhaupt mit Exchange zu tun, weil Autodiscover genutzt wird.

vor 43 Minuten schrieb winmadness:

Danke für das Feedback. Ich habe eine ausführliche Beschreibung der Sicherheitslücke unter https://www.guardicore.com/labs/autodiscovering-the-great-leak/  gefunden. In dem Auszug aus dem Webserver Protokoll ist die Outlook Version zu sehen - Windows 10 mit MS Office 2016 bzw. 2019 bzw. Microsoft 365 (sofern ich das richtig interpretiere):

 

Nachtrag:

Unter https://docs.microsoft.com/de-de/officeupdates/update-history-office-2019 habe ich Infos bzgl. der Buildnummer 13901 gefunden. Diese betreffen die MS Office 2016 / 2019 Version im Zeitraum April / März 2021

Im anderen Screenshot ist noch 16.0.9029 zu sehen, was nochmal deutlich älter sein dürfte.

bearbeitet 23. September 2021 von NorbertFe

[winmadness 79]

Im Heise-Artikel findet sich ein Hinweis auf das verwendete Autodiscover Protokoll:

Zitat

Dass Outlook und Exchange hier einfache, HTTP-authentifizierte Klartext-Anmeldedaten an irgendwelche unbekannten Server verschicken ist ein riesiges Problem. Zwar untersuchten die Forscher nur eine Version (basierend auf Plain Old XML oder POX) von vielen des Autodiscover-Protokolls und es gelang ihnen auch bei weitem nicht in allen möglichen Konfigurationen Daten auszulesen, der Erfolg ihrer Datenspionage im öffentlichen Netz mit den selbst registrierten Domains sollte allerdings zu denken geben.

Kann einer beurteilen, bei welchen Clients POX im Autodiscover Protokoll verwendet wird? Anscheinen nicht bei MS Outlook 2016. Ich habe noch einen weiteren Test durchgeführt. Outlook verbindet sich bei meinem Client über eine VPN Verbindung. Also Outlook gestartet und mit Exchange verbunden, VPN Verbindung getrennt und dann den in Outlook integrierten "E-Mail-Autokonfigurations-Test" durchgeführt. Auch hier werden nur Domain / Subdomain von firma.com abgefragt, keine Anfrage an autodiscover.com.

 

Nachtrag:

Ich habe in der MS Dokumentation eine Beschreibung des POX Formates inkl. folgenden Hinweis gefunden:

Zitat

Für Clients, die auf Versionen von Exchange ab Exchange Server 2010 abzielen, wird empfohlen, den SOAP-AutoErmittlungsdienst anstelle des POX-AutoErmittlungsdiensts zu verwenden. Clients, die auf Exchange 2007 Zielen, müssen den POX-AutoErmittlungsdienst verwenden. Es wird empfohlen, dass Clients, die das .NET Framework verwenden, den verwaltete EWS-API verwenden, da er einen robusten und bewährten POX-Auto Ermittlungs Client enthält. Weitere Informationen zum verwaltete EWS-API finden Sie unter Erste Schritte mit verwaltete EWS-API-Clientanwendungen

 

bearbeitet 23. September 2021 von winmadness
POX Spezifizierung

[NorbertFe 2.067]

vor 26 Minuten schrieb winmadness:

Kann einer beurteilen, bei welchen Clients POX im Autodiscover Protokoll verwendet wird?

Also ich nicht, aber selbst wenn, wirst du dann deinen Usern sagen, das dürft ihr aber nicht verwenden? Verhindern kannst du es ja technisch nicht. ;)

[winmadness 79]

vor 1 Minute schrieb NorbertFe:

wirst du dann deinen Usern sagen, das dürft ihr aber nicht verwenden

Nein, aber man könnte einschätzen, welche Clients betroffen sind und entsprechende Absicherungsmaßnahmen treffen.

[NorbertFe 2.067]

Gerade eben schrieb winmadness:

entsprechende Absicherungsmaßnahmen treffen

Welche denn? Abgesehen von deinen Maschinen hast du ja kaum Einfluss darauf, wo deine User ihr Kennwort einhacken.