11
Exchange Autodiscover Extern
Guten Morgen,
bei Heise wird aktuell über eine Problematik berichtet, bei der es bei einem nicht nach Microsoft-Vorgaben konfiguriertem Autodiscover zu einem Sicherheitsproblem kommt:
https://www.heise.de/news/Autodiscover-Exchange-Protokoll-leakt-Windows- ...
Konkret werden Outlook-Anmeldedaten ungewollt an externe Server (z.B. autodiscover.tld) gesendet, wenn das eigene Autodiscover nicht korrekt konfiguriert ist.
Frage: Wie sollte ich Autodiscover extern konfigurieren, wenn der Exchange nicht von Extern erreichbar ist? Für die Funktionalität wird Autodiscover extern nicht benötigt, sollte ich dennoch vorsorglich die interne Autodiscover-Konfiguration extern bereitstellen?
bei Heise wird aktuell über eine Problematik berichtet, bei der es bei einem nicht nach Microsoft-Vorgaben konfiguriertem Autodiscover zu einem Sicherheitsproblem kommt:
https://www.heise.de/news/Autodiscover-Exchange-Protokoll-leakt-Windows- ...
Konkret werden Outlook-Anmeldedaten ungewollt an externe Server (z.B. autodiscover.tld) gesendet, wenn das eigene Autodiscover nicht korrekt konfiguriert ist.
Frage: Wie sollte ich Autodiscover extern konfigurieren, wenn der Exchange nicht von Extern erreichbar ist? Für die Funktionalität wird Autodiscover extern nicht benötigt, sollte ich dennoch vorsorglich die interne Autodiscover-Konfiguration extern bereitstellen?
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 1304440815
Url: https://administrator.de/contentid/1304440815
Ausgedruckt am: 24.11.2024 um 04:11 Uhr
11 Kommentare
Neuester Kommentar
Moin,
bitte lies den Artikel erneut. Es geht darum, das bei dem Autodiscover Prozess ein Mechanismus angestoßen wird, der unter Umständen auch "autodiscover.tdl" zusammen baut.
Deine Clients sollen auf diese Adressen im besten Fall nicht zugreifen können. Daher sollst du diese Adressen als workaround sperren. Im Artikel war glaub ich auch ein link zu einer github Liste mit den Adressen.
Gruß
Spirit
bitte lies den Artikel erneut. Es geht darum, das bei dem Autodiscover Prozess ein Mechanismus angestoßen wird, der unter Umständen auch "autodiscover.tdl" zusammen baut.
Deine Clients sollen auf diese Adressen im besten Fall nicht zugreifen können. Daher sollst du diese Adressen als workaround sperren. Im Artikel war glaub ich auch ein link zu einer github Liste mit den Adressen.
Gruß
Spirit
Guten Morgen
Das Problem wird hier und da missverständlich beschrieben.
Der Fehler liegt nämlich nicht beim Exchange sondern beim Client. Einige davon (bspw. wohl Outlook) bauen sich verschiedene Domains zusammen wenn die Standard-Autodiscover-URL nicht erreichbar ist. Mit diesen - von weit her geholten - Autodiscover-URLs versuchen sie dann dort die gewünschten Informationen zu laden.
Wenn du jetzt an so eine Domain kommst und dort auf die verirrten Anfragen antwortest kommst du an allerlei Zugangsdaten. Vielleicht sogar ganz ohne Antwort sondern einfach mit einem Blick ins Log des Webservers.
Wie man auf die Idee kommen kann sowas zu programmieren ist mir allerdings schleierhaft.
Manuel
Das Problem wird hier und da missverständlich beschrieben.
Der Fehler liegt nämlich nicht beim Exchange sondern beim Client. Einige davon (bspw. wohl Outlook) bauen sich verschiedene Domains zusammen wenn die Standard-Autodiscover-URL nicht erreichbar ist. Mit diesen - von weit her geholten - Autodiscover-URLs versuchen sie dann dort die gewünschten Informationen zu laden.
Wenn du jetzt an so eine Domain kommst und dort auf die verirrten Anfragen antwortest kommst du an allerlei Zugangsdaten. Vielleicht sogar ganz ohne Antwort sondern einfach mit einem Blick ins Log des Webservers.
Wie man auf die Idee kommen kann sowas zu programmieren ist mir allerdings schleierhaft.
Manuel
Zitat von @Spirit-of-Eli:
bitte lies den Artikel erneut. Es geht darum, das bei dem Autodiscover Prozess ein Mechanismus angestoßen wird, der unter Umständen auch "autodiscover.tdl" zusammen baut.
Deine Clients sollen auf diese Adressen im besten Fall nicht zugreifen können. Daher sollst du diese Adressen als workaround sperren. Im Artikel war glaub ich auch ein link zu einer github Liste mit den Adressen.
bitte lies den Artikel erneut. Es geht darum, das bei dem Autodiscover Prozess ein Mechanismus angestoßen wird, der unter Umständen auch "autodiscover.tdl" zusammen baut.
Deine Clients sollen auf diese Adressen im besten Fall nicht zugreifen können. Daher sollst du diese Adressen als workaround sperren. Im Artikel war glaub ich auch ein link zu einer github Liste mit den Adressen.
Einen Workaround brauche ich nur, wenn ich mich nicht an die Microsoft-Vorgaben halte und ein entsprechendes Autodiscover veröffentliche. Wenn Autodiscover erreichbar ist (z.B. autodiscover.domain.tld), dann wird der Client keine anderweitigen Versuche unternehmen.
Das führt mich wieder zu meiner Ausgangsfrage, inwieweit es sinnvoll ist, einen internen Exchange per externem Autodiscover zu konfigurieren. Was macht der Client, wenn er den per Autodiscover konfigurierten Exchange nicht erreicht, weil dieser extern nicht erreichbar ist?
Alle anderen Ansätze sind Workaround, hier könnte ich Outlook entsprechend per Registry verbieten HTTP-Authentifizierung zu nutzen oder den Zugriff auf die Domains auf den Clients verbieten.
Da gibt es eigentlich nur eine Konsequenz: MS-Produkte rauswerfen. 
lks
lks
Moin,
Bei Ersterem würde ich einfach den FQDN auf einem Webserver zeigen lassen. Dort muss natürlich die entsprechende Struktur und die Datei autodiscover.xml vorhanden sein.
Bei letzerem bleibt wohl nichts anders übrig als
a) Autodiscover entsprechend sicher zu veröffentlichen
b) per GPO die möglichen Domains in der Windows Defender Firewall zu sperren.
Gruß,
Dani
Das führt mich wieder zu meiner Ausgangsfrage, inwieweit es sinnvoll ist, einen internen Exchange per externem Autodiscover zu konfigurieren. Was macht der Client, wenn er den per Autodiscover konfigurierten Exchange nicht erreicht, weil dieser extern nicht erreichbar ist?
reicht es, wenn Microsoft Outlook den Pfad erreichen kann oder muss auch die Authentifizierung erfolgreich sein?#Bei Ersterem würde ich einfach den FQDN auf einem Webserver zeigen lassen. Dort muss natürlich die entsprechende Struktur und die Datei autodiscover.xml vorhanden sein.
Bei letzerem bleibt wohl nichts anders übrig als
a) Autodiscover entsprechend sicher zu veröffentlichen
b) per GPO die möglichen Domains in der Windows Defender Firewall zu sperren.
Gruß,
Dani
Zitat von @Dani:
reicht es, wenn Microsoft Outlook den Pfad erreichen kann oder muss auch die Authentifizierung erfolgreich sein
Ähnliches habe ich mich auch gefragt:reicht es, wenn Microsoft Outlook den Pfad erreichen kann oder muss auch die Authentifizierung erfolgreich sein
1) Erfolgreiche DNS-Auflösung
2) Erfolgreiche Kommunikation
3) Erfolgreiche Authentifizierung
Bei mir läuft nämlich DNS noch weil der Exchange bis HAFNIUM extern erreichbar war. Jetzt nur noch durch VPN und das kann natürlich auch einfach mal aus sein. Also wäre meine Frage was passiert wenn autodiscover.domain.tld durch Outlook aufgelöst werden kann aber keine Kommunikation zu Stande kommt. Wird weiter probiert?
Ich habe zum Glück keinen externen Client mit Outlook aber das wäre dann doppelt dämlich.
Moin,
soweit wir es inzwischen überblicken, ist es weder ein Problem von Microsoft Exchange Server noch von Microsoft Office Outlook. Letzteres deckt sich auch mit unseren Tests. Nämlich dass wir die Problematik mit Outlook 2019 nicht nachstellen konnten. Daher trifft es womöglich die alternativen E-Mail-Clients am Markt.
Gruß,
Dani
soweit wir es inzwischen überblicken, ist es weder ein Problem von Microsoft Exchange Server noch von Microsoft Office Outlook. Letzteres deckt sich auch mit unseren Tests. Nämlich dass wir die Problematik mit Outlook 2019 nicht nachstellen konnten. Daher trifft es womöglich die alternativen E-Mail-Clients am Markt.
Gruß,
Dani
Zitat von @Dani:
Moin,
soweit wir es inzwischen überblicken, ist es weder ein Problem von Microsoft Exchange Server noch von Microsoft Office Outlook. Letzteres deckt sich auch mit unseren Tests. Nämlich dass wir die Problematik mit Outlook 2019 nicht nachstellen konnten. Daher trifft es womöglich die alternativen E-Mail-Clients am Markt.
Moin,
soweit wir es inzwischen überblicken, ist es weder ein Problem von Microsoft Exchange Server noch von Microsoft Office Outlook. Letzteres deckt sich auch mit unseren Tests. Nämlich dass wir die Problematik mit Outlook 2019 nicht nachstellen konnten. Daher trifft es womöglich die alternativen E-Mail-Clients am Markt.
Es ist das Problem des Autodiscover-Protokolls.
lks
PS: Habe gerade keine Zeit, sonst würde ich das man mit diversen Clients ausprobieren.
Es ist das Problem des Autodiscover-Protokolls. face-smile
Hm. Scheint wohl eher an dessen Implementierung zu liegen. Sonst würde Outlook das selbe Verhalten aufzeigen wie überall beschrieben. face-smileFYI: TLDs vulnerable to autodiscover leaks
Hallo,
ich habe zu meiner Überraschung festgestellt, dass die Windows Defender Firewall ausschließlich mit IP-Adressen und nicht mit DNS-Namen umgehen kann. Oder habe ich etwas übersehen?
Zitat von @Dani:
Bei letzerem bleibt wohl nichts anders übrig als
b) per GPO die möglichen Domains in der Windows Defender Firewall zu sperren.
Bei letzerem bleibt wohl nichts anders übrig als
b) per GPO die möglichen Domains in der Windows Defender Firewall zu sperren.
ich habe zu meiner Überraschung festgestellt, dass die Windows Defender Firewall ausschließlich mit IP-Adressen und nicht mit DNS-Namen umgehen kann. Oder habe ich etwas übersehen?
Noch ein Update:
Ich habe gerade versucht das mit einem Outlook 2016 Client nachzustellen und habe die Pakete im Wireshark mitgeschnitten, hier konnte ich das Verhalten nicht nachvollziehen, obwohl der autodiscover.domain.tld nicht existiert.
Ich habe gerade versucht das mit einem Outlook 2016 Client nachzustellen und habe die Pakete im Wireshark mitgeschnitten, hier konnte ich das Verhalten nicht nachvollziehen, obwohl der autodiscover.domain.tld nicht existiert.
