[English]Nachdem ein Designfehler in dem von Microsoft Exchange verwendeten Autodiscover-Protokoll bekannt wurde, versucht Microsoft jetzt auf die Schnelle alle Autodiscover-Domains zu registrieren. Denn Clients leaken über das Autodiscover-Protokoll Zugangsdaten zu Exchange-Konten an solche Autodiscover-Domains, falls die eigentliche Domain nicht erreichbar ist. Hier einige Informationen zum Sachverhalt.
Anzeige
Das Autodiscover-Problem
Autodiscover ist ein von Microsoft Exchange verwendetes Protokoll zur automatischen Konfiguration der für E-Mail-Konten von Clients wie Microsoft Outlook. Ziel des Protokolls ist es, dass ein Endbenutzer seinen Outlook-Client vollständig konfigurieren kann, indem er lediglich seinen Benutzernamen (die E-Mail-Adresse) und sein Kennwort angibt und den Rest der Konfiguration dem Autodiscover-Protokoll von Microsoft Exchange überlässt.
Sicherheitsforscher von Guardicore sind aber auf einen Designproblem in dem von Microsoft Exchange benutzten Autodiscover-Protokoll gestoßen, der es Angreifern ermöglicht, über externe Autodiscover-Domains die Anmeldedaten von Domains abzugreifen. Problem ist, dass die Clients bei der Einrichtung eines Kontos einen Ping mit den Anmeldedaten (Benutzername, Kennwort, Domain) an verschiedene Adressen schicken.
Normalerweise ist die abgefragte Domain, unter der der Exchange-Server betrieben wird. Diese wird aus der E-Mail-Adresse für das Exchange-Konto abgeleitet. Antwortet keine dieser URLs, startet Autodiscover sein „Back-off"-Verfahren und versucht einen Ping auf Adressen, die nach dem Schema:
http: // autodiscover.<tld>/Autodiscover/Autodiscover.xml.
Anzeige
gebildet werden. Bei einer E-Mail-Adresse <name>@<domain>.de würde dann irgendwann autodiscover[.]de angefragt. Wer diese Domain besitzt, könnte die Pings der Clients abfangen und auf Anmeldedaten für Konten prüfen. Sicherheitsforscher von Guardicare haben sich auf Basis dieser Erkenntnisse eine Reihe autodiscover-TLD-Domains registriert – und in diesem Kommentar behauptet jemand, die autodiscover[.]de zu besitzen. Dann wurde ein AutoDiscover-Dienst unter den Domains aufgesetzt. Amit Serper vom Sicherheitsanbieter Guardicore hatte seine Erkenntnisse die Tage im Blog-Beitrag Autodiscovering the Great Leak veröffentlicht. Dort finden sich auch Hinweise, was man tun könnte (die Möglichkeiten sind aber begrenzt, da das Ganze die Clients betrifft).
Frank Carius diskutiert in diesem Kommentar den Ansatz, keine Domain der Art <name>[.]de für E-Mails und AD zu verwenden (was aber umstritten scheint). Hinweise, um eine bessere Authentifizierung für Outlook-Clients unter Windows zu erzwingen, finden sich in diesem Kommentar.
Autodiscover-Abfragen an Honeypot, Quelle: Guardicore
Vom 16. April bis 25. August 2021 erhielten die Sicherheitsforscher mit ihrem Autodiscover-Honeypot Hunderte von Anfragen mit Tausenden von Anmeldedaten von Benutzern (siehe obiges Bild). Deren Clients versuchten ein Exchange-Konto einzurichten, konnten aber den richtigen Autodiscover-Endpunkt des Exchange-Postfachs nicht finden. Bei verwendeter Basic-Authentifizierung wurden von den Clients die Zugangsdaten bei jedem Ping im Klartext mitgeschickt. Betroffenen waren Unternehmen und Organisationen aus unterschiedlichen Bereichen.
Ich hatte das Thema im Blog-Beitrag Microsoft Exchange Autodiscover-Designfehler ermöglicht Abgriff von Zugangsdaten aufgegriffen. Was mich etwas wunderte, war einerseits, dass vielen Lesern nicht klar war, dass das Problem beim Client lag. Dann gab es in den Kommentaren sehr schnell einen Link auf diese Diskussion im MCSE-Board und Frank Carius hat sich in diesem Artikel ein paar Gedanken zum Ganzen gemacht. Der Tenor, den ich da herauslese, ist: Das das Ganze nicht nachvollziehbar sei. Ist unter dem Strich aber ein Schluss mit Risiko.
Microsoft registriert autodiscover-Domains
Meine Schlussfolgerung aus dem letzten Satz scheint auch Microsoft zu teilen. Auch wenn bisher kein Missbrauch bekannt ist, lauert dort ein potentielles Sicherheitsproblem. Jedenfalls meldet Bleeping Computer, dass Microsoft eilig damit begonnen habe, Domains mit dem Schema autodiscover.[TLD] zu registrieren, da diese Windows-Anmeldedaten leaken könnten.
In diesem Artikel zitiert Bleeping Computer Microsoft, dass man den Sachverhalt, den Guardicore offen gelegt habe, aktiv untersuche und Maßnahmen plane, die Gefahr zu minimieren. Dazu gehört auch, die betreffenden Domains zu übernehmen. Laut obigem Tweet sind bisher 68 dieser Domains inzwischen im Besitzt von Microsoft, während dies bei 38 Domains nicht verifiziert werden konnte (die Eigentümer werden bei einer WhoIs-Abfrage aus Datenschutzgründen nicht genannt). Die Liste der Domains ist im Bleeping Computer Artikel zu finden.
Die Microsoft-Aktion wird zwar die Möglichkeit des Missbrauchs reduzieren. Problem stellen aber die (Mail-)Clients dar, die fehlerhaft implementiert sind und die Anmeldedaten bei der Kontenkonfigurierung unverschlüsselt senden. Bleeping Computer führt dabei auch Microsoft E-Mail-Clients wie Microsoft Outlook und aus Office 365 auf – das größere Problem dürften aber Clients von Drittanbietern sein. Die Kuh ist meiner Meinung nach nicht vom Eis.
Ähnliche Artikel:
Office365: Update ändert Autodiscover, Outlook-Anmeldung scheitert
Exchange Server: Authentifizierungs-Bypass mit ProxyToken
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
Exchange-Schwachstellen: Droht Hafnium II?
Microsoft Exchange Autodiscover-Designfehler ermöglicht Abgriff von Zugangsdaten
Anzeige
@Die Kuh ist meiner Meinung nach nicht vom Eis.
Ja warum denn auch – schließlich hat dann MS die Anmeldedaten! ;-)
Habe die doch sowieso schon…
Aber erschreckend wie einfach das abgreifen funktioniert
Seit es private TLDs gibt (gut die sind recht teuer) sind dies doch unendlich viele.
z.B.: Autodiscover.Born
also was soll das bringen.
Nun ja, eine Organisation, die sich eine Domain borncity.born leistet, könnte dann noch autodiscover.born dazu ordern. Dann wäre der Käse für diese TLD gegessen. Und die restlichen nicht privaten TLDs sind dann hoffentlich in der Obhut Microsofts – ob das klappt, weiß ich nicht.
die brauchen doch nur autodiscover.borncity.born als Subdomain, sofern sich Outlook an die beschriebene Reihenfolge hält (und nicht weiter nachfragt, wenn es eine Autodiscover gefunden hat).
Das ist das gleiche wie bei wpad. Wenn Du einen DoS auf autodiscover.borncity.born fährst (oder DNS-Interception z.B. in öffentlichen WLANs bist Du wieder an der gleichen Stelle. MS hat damals auch hektisch wpad.de eingerichtet. In manchen Ländern reicht sorar die 3.Ebene (z.B. autodiscover.co.uk)
Die Anmeldedaten gehen doch dann auch unverschlüsselt lesbar über VPN Anbieter, sonstige Proxies und alle Netzwerkknoten im gesamten Routing auf dem Weg zur externen Autodiscover-Domain, auch wenn die dann von Microsoft o.ä. registriert ist?
Ja, sofern die Clients beim Autodiscover auf das „Back-off"-Verfahren und http-Pings zurückfallen. Ist auch für Man-in-the-middle ein Thema.
Aber unter dem Strich juckt es doch keinen – wenn ich meinen Beitrag Outlook App speichert Passwörter in der Cloud und analysiert Mails vom Januar 2021 betrachte. In den Blogs und Webseiten wird doch maximal "das Icon xyz wurde jetzt rot gepinselt" als Jubelmeldung verbreitet …
"Aber unter dem Strich juckt es doch keinen"
Betrachte es schlichtweg als gegenwärtigen Bildungsspiegel unserer Gesellschaft, die zu absoluter Konsumierung und Verblödung gedrillt worden ist.
Würde uns die ältere Generation von heute auf morgen wegsterben, brächte uns das fast in die Steinzeit zurück, weil die gegenwärtige und neue Generation – abseits von heißen Phrasen dreschen – nur verdammt wenig auf dem Kasten hat.
Ich für meinen Teil lese Deine Beiträge, reagiere aber nicht immer darauf. Zumeist deshalb, weil ich nicht direkt betroffen bin (Microsoft kann sich sein Exchange/Outlook-Gedöns hinstecken, wo die Sonne nicht scheint – beide Frickel-Produkte fasse ich mit der Kneifzange privat nicht an).
Das die gegenwärtige Generation pauschal nichts kann, die ältere jedoch im breiten Maße halte ich für eine sehr einfache Weltanschauung…
em, werden ICMP (ping) daten eigentlich auf verschlüsselten Verbindungen verschlüsselt? Oder wie wird verhindert das ein böser VPN-Betreiber die pings mitliest?
Achso. Da wird kein ICMP-Ping gemacht, sondern eine Anfrage in HTML.
Diese muss aber nicht in HTTPS erfolgen, sondern erfolgt bei Nicht-Anwort auch in HTTP und enthält Klartext.
Also ist am Kabel sniffen doch eine Option?
Kurze Verständnisfrage: Das Backoff-Verfahren funktioniert ja dann nur wenn keine autodiscover.meinefirma.tld angelegt wurde, ohne dies ja neuere Outlookclients ohnehin kein Outlook Anywhere machen könnten.
Die meisten nicht konfigurierten Autodiscover-Subdomains dürften heut zu Tage wohl am Hoster aufprallen, weil dort meist ein Wildcard (*) – DNS-Eintrag gesetzt wird da dies ja schicker ist als www. einzutippen. So arg seh ich das Problem also irgendwie nicht.
Ps. Wie ist das mit NTLM statt Basic? Ich weiß die Outlooks sind auf "Aushandeln" und wählen dann eines der beiden Protokolle, wie ist das aber wenn man Serverseitig von Basic auf NTLM umstellt? Kriegen das alle Clients ohne Probleme mit oder killt man sich das den Sync? Gibt es darüber hinaus immer noch die Probleme das gespeicherte Anmeldedaten im Outlook in einer Schleife trotzdem immer wieder abgefragt werden?
autodiscover.deinefirme.tld antwortet aber vielleicht auch nicht weil er gerade einer ddos attacke unterlegen ist, so habe ich es zumindest verstanden
Mit 2 Tagen abstand und einigen Tests würde ich den Artikel von Guardicore eher als Clickbait und FUD (Fear, Uncertainty and Doubt) klassifizieren.
– Der Exchange Server hat kein Problem und Änderungen auf dem Server z.B. bei der Authentifizierung helfen nichts. (sollten natürlich grundlegend schon sicher sei, d.h. TLS-Zwang und kein BasicAuth zulassen). Aber das ist nicht wichtig hier.
– Der Outlook Client fragt nur nach " oder autodiscover. aber nicht nach autodiscover..
Was anderes ist von Microsoft in der Autodiscover-Doku auch nicht beschrieben. Ein "Back-Off"-Verhalten steht dort nicht drin.
Es gibt aber wohl andere Clients die so blöde sind und eben auch autodiscover.tld fragen UND auf "BasicAuth" ihre Anmeldedaten hinsenden.
Leider liefert der Autor keine Informationen über den Useragent, den er gesehen hat noch sonst was. Und nachstellen konnte ich das Verhalten auch im internen DNS und Proxy nicht. keiner meiner Clients mit "de-Domains" hat je nach autodiscover.de gefragt.
Es gibt aber durchaus "Risiken" bei Autodiscover, die real sind
https://www.msxfaq.de/exchange/autodiscover/autodiscover_sicherheit.htm
Dankeschön!! Hatte bis jetzt leider keine Zeit gehabt, dies selbst zu testen…
Ah, Antwort vom Exchaneguru Nummer 1 😃 . Gut, nach dem Lesen des Links klingt das dann alles nicht mehr sooo wild wie anfangs dargestellt.
Mich wundert das auch. Aber warum versucht dann Microsoft, all diese Domains zu bekommen?
Schadenskontrolle. Auch wenn vielleicht Exchange nicht der "Fehler" ist, wenn sich die Clients so verhalten fällt das dann am Ende doch auf Microsoft zurück.
Der Vorfall zeigt mal wieder deutlich wie Microsoft eins ums andere Mal verkackt. Wer immer noch glaubt mit Microsoft Produkten ein sicheres Netzwerk aufbauen zu können sollte spätens jetzt über seine eigene Urteilsfähigkeit nachdenken.
Das ist kein Microsoft-spezifisches Problem. Alle Netzwerke, egal auf welche Art und Weise sie realisiert werden, sind auf die eine oder andere Art und Weise angreifbar.
Eines der Hauptprobleme ist die Notwendigkeit der Aushandlung von Anmeldeinformationen. Dieser Vorgang ist notwendig, egal wie Du es realisierst, genau das ist auch ein Angriffsvektor bei jeder Anwendung und jedem Betriebssystem.
Und wenn alle Stricke reißen… man hat immer noch den Benutzer am anderen Ende der Leitung, den man abgreifen kann.
Massenware (Hardware, Software) kann *nicht* 100 % sicher sein.