[English]Sicherheitsforscher von Guardicore sind auf einen Designfehler im von Microsoft Exchange benutzten Autodiscover-Protokoll gestoßen, der es Angreifern ermöglicht, über externe Autodiscover-Domains die Anmeldedaten von Domains abzugreifen. Möglich wird dies, weil sich Autodiscover-Domains außerhalb der Domäne des Nutzers (aber noch in derselben TLD) missbrauchen lassen. Hier einige Hinweise zu diesem Sachverhalt.
Anzeige
Sicherheitsforscher Amit Serper vom Sicherheitsanbieter Guardicore hat seine neuen Erkenntnisse im Blog-Beitrag Autodiscovering the Great Leak veröffentlicht. Ich bin über nachfolgenden Tweet auf das Thema aufmerksam geworden.
Autodiscover in Exchange
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.
Beim Einrichten des Zugangs für ein Microsoft Exchange-Postfach schickt die Mail-App die Zugangsdaten (Benutzername bzw. E-Mail-Adresse, Kennwort) an den Server, und bekommt dann die gültige Konfiguration für den Zugriff zurückgemeldet. Mit diesen Daten wird der Client dann für den betreffenden Exchange Server-Zugang eingerichtet.
Anzeige
Das Protokoll wurde bereits in Outlook 2007 eingeführt. Die Grundlagen wurden z.B. von Frank Carius auf msxfaq.de in diesem Artikel beschrieben. In diesem Artikel geht er auf die Autokonfiguration in Outlook ein. Eine englischsprachige Kurzdarstellung findet sich hier und Microsoft hat die Implementierung von Autodiscover hier beschrieben.
Anmerkung: Oft werden Anmeldedaten für ein Exchange-basierten Posteingang auch als Domänen-Anmeldedaten verwendet. Gelingt es einem Angreifer, die Anmeldedaten für ein Exchange-Postfach über eine Sicherheitslücke abzuziehen, hat er in Folge auch Zugriff auf die Domain der Organisation. Der Angreifer verfügt dann über gültige Anmeldedaten, mit er sich Zugang zur IT eines Unternehmens verschaffen kann.
Der Autodiscover-Protokoll Designfehler
Beim Einrichten eines Exchange-Postfach-Zugangs in einer Mail-App (Client) schickt diese einen Ping mit den Anmeldedaten des Postfachs (Benutzername, Kennwort) an verschiedene Adressen der Art:
- https: // Autodiscover.example.com/Autodiscover/Autodiscover.xml
- http: // Autodiscover.example.com/Autodiscover/Autodiscover.xml
- https: // example.com/Autodiscover/Autodiscover.xml
- http: // example.com/Autodiscover/Autodiscover.xml
Die Domain example.com wird dabei aus der für das Exchange-Postfach angegebenen E-Mail-Adresse @example.com ermittelt. Antwortet keine dieser URLs, startet Autodiscover sein "Back-off"-Verfahren.
Dieser im Protokoll vorgesehene "Back-off"-Mechanismus versucht im Client, den Autodiscover-Teil der Domäne aufzulösen und würde im nächsten Versuch eine URL der Art:
http: // autodiscover.com/Autodiscover/Autodiscover.xml
anfragen. Die Domain besteht dabei aus dem Namen autodiscover und der Top-Level-Domain des zu konfigurierenden Postfachs (.com, .de, .fr etc.). Der Designfehler in Exchange-Autodiscover liegt nun darin, dass die Pings des Clients nicht auf die Domain des abzuprüfenden Postfachs (z.B. borncity.com) begrenzt werden. Vielmehr sind verschiedene Top-Level-Domains für autodiscover denkbar.
Gelingt es einem Dritten, die Domain autodiscover.com, autodiscover.de etc. zu registrieren, würden die Anfragen mit den Zugangsdaten per Ping an diese Domain gehen. Die Sicherheitsforscher waren in der Lage, sich die folgendem Domains zu greifen und zu registrieren:
- Autodiscover.com.br – Brazil
- Autodiscover.com.cn – China
- Autodiscover.com.co – Columbia
- Autodiscover.es – Spain
- Autodiscover.fr – France
- Autodiscover.in – India
- Autodiscover.it – Italy
- Autodiscover.sg – Singapore
- Autodiscover.uk – United Kingdom
- Autodiscover.xyz
- Autodiscover.online
Die so registrierten Domains wurden einem von den Guardicore Sicherheitsforschern kontrollierten Webserver zugewiesen. Dann warteten die Sicherheitsforscher darauf, dass Webanfragen für verschiedene Autodiscover-Endpunkte eintrafen. Zur Überraschung stellten die Guadicore-Leute fest, dass eine beträchtliche Anzahl von Anfragen von verschiedenen Domänen, IP-Adressen und Clients an die kontrollierten Autodiscover-Endpunkte einging. Das Bemerkenswerteste an diesen Anfragen war, dass sie den relativen Pfad /Autodiscover/Autodiscover.xml mit dem Authorisierungs-Header anforderten. Und dort steckten die Anmeldeinformationen für die HTTP-Basisauthentifizierung.
Erschreckend war bei einer großen Anzahl der Anfragen, dass der keinen Versuch unternahm, erst zu prüfen, ob die Ressource überhaupt verfügbar ist oder überhaupt auf dem Server existiert (löst einen HTTP 404-Fehler aus). Vielmehr wurden die Anmeldedaten gleich bei der ersten Anfrage mitgeschickt.
Vom 16. April bis 25. August 2021 erhielten die Sicherheitsforscher mit ihrem Autodiscover-Honeypot Hunderte von Anfragen mit Tausenden von Anmeldedaten von Benutzern, die versuchten, ihre E-Mail-Clients einzurichten, aber ihre E-Mail-Clients konnten den richtigen Autodiscover-Endpunkt des Exchange-Postfachs nicht finden. Betroffenen waren Unternehmen und Organisationen aus unterschiedlichen Bereichen. Dabei waren nicht nur Anmeldedaten im Klartext, sondern auch OAuth-Tokens.
Auch die Warnung vor selbst-signierten Zertifikaten, die am Client eventuell auftauchen kann, ließ sich mit einem LetsEncrypt-Zertifikat unterdrücken. Die Details hat der Sicherheitsforscher in diesem Blog-Beitrag zusammen gefasst. Dort gibt er auch Hinweise, wie das Problem abgemildert werden könnte.
- Wer Exchange-basierte Technologien wie Outlook oder ActiveSync (Microsofts mobiles Exchange-Synchronisationsprotokoll) verwendet, muss sicherstellen, dass Autodiscover-Domänen (wie Autodiscover.com/Autodiscover.com.cn usw.) aktiv in einer Firewall blockiert werden.
- Bei der Bereitstellung/Konfiguration von Exchange-Setups ist sicherzustellen, dass die Unterstützung für die Basisauthentifizierung deaktiviert ist. Die Verwendung der HTTP-Basisauthentifizierung ist dasselbe wie das Senden eines Kennworts im Klartext über die Leitung.
Weiterhin müssen Softwareentwicklern/-anbietern, die das Autodiscover-Protokoll in ihre Produkte implementieren, das Ganze so umsetzen, dass die Anmeldedaten nicht bereits bei der ersten Anfrage mitgesendet werden. Und Microsoft müsste die Anforderungen an das Autodiscover-Protokoll überarbeiten.
Ergänzung: Bezüglich der folgenden Kommentare hat mich gewundert, dass aus dem Text nicht klar ersichtlich war, dass der Fehler nicht in Exchange zu suchen ist, sondern dass ein Design-Fehler im Autodiscover-Protokoll vorliegt und die Clients dann die Zugangsdaten verraten. Frank Carius hat sich des Themas angenommen und in diesem Artikel einen Abriss samt Risiko-Einschätzung abgegeben. Man kann das Ganze auf zwei Sätze reduzieren: Bei den meisten Exchange-Installationen, die sauber aufgesetzt sind, passiert nicht viel. Aber der Teufel liegt wie immer im Detail. Denn es ist glaubhaft, dass Guadicore auf seinen Honeypot Autodiscover-Domains Anfragen mit Zugangsdaten erhielt.
Ergänzung: Microsoft hat damit begonnen, die autodiscover-Domains auf sich zu registrieren, siehe Microsoft versucht Autodiscover-Domains zu registrieren .
Ä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?
Anzeige
WTF? Das hat bis heute niemand bei MS bemerkt? Wir hatten bei NTLM immer die Fehler das Kennworte nicht gespeichert blieben (Outlook Anywhere). Die Lösung war damals "Einfach" also Clear mit SSL. Toll.
Ich möchte gerne mal die Typen kennenlernen, die sowas coden… :(
Vorallem fragt man sich warum man da erst JETZT drauf kommt. Das Verhalten dürfte ja theoretisch auch in Office 365 so funkionieren und da wäre es ja nicht so das sie erst seit gestern eine handvoll Benutzer haben.
Da sich wohl in letzter Zeit mehr Sicherheitsforscher mit Exchange beschäftigen glaub ich wohl das da noch einiges auf uns zukommen wird.
Intern könnte man den Weg nach außen sperren aber mit Geräten außerhalb wäre ja das Problem nicht am Exchange sondern eher am Outlook Client. Frage ist auch in welchem Fall versucht wird die TLD zu erreichen. Generell nicht erreichbar oder auch falsche Anmeldedaten etc.
Jep, intern hab ichs über die Firewall blockiert, bringt nur für alle Smartphones von aussen nix :-/ .
Ps. Na, da hat sich schon mal jemand die Domain geschnappt: https://who.is/whois/autodiscover.de .
In Deutschland ist das ja recht einfach, dies zu unterbinden. Vermute mal, dass Denic ein paar Anfragen erhalten wird, wer hinter der Domain steckt ;-)
IMHO liegt da der Fix bei MS, da dies ja vermutlich vom Client (Outlook) ausgeht. Also einfach ein Outlook/Office-Update – oder?
Hmm, weiß nicht so recht. Autodiscover wird ja für alle ActiveSync-Verbindungen genutzt, eben auch Smartphones usw. Das einfach Outlookseitig zu patchen wird wohl nicht reichen.
Es gibt eine Lautmeldung, dass derjenige, der die Domain besitzt, diese an "vertrauenswürdige Hände" wie das BSI übergeben würde. Möglicherweise bekommt auch Microsoft diese Domain. Ich habe es im Artikel Microsoft versucht Autodiscover-Domains zu registrieren mit angerissen.
Robert der Fix von MS kann wohl etwas dauern. Normalerweise reicht man sowas beim Problemsteller ein und gibt ihm 90 Tage bis zur Veröffentlichung. Das scheint hier nicht der Fall gewesen zu sein.
Trotzdem ist das schon ziemlich unglaublich, und so ein Fall wo sich das kriminelle Gesindel ärgert da nicht selbst drauf gekommen zu sein.
naja wer sagt denn das kriminelles Gesindel das nicht längst wusste? Diese Sorte Hacker hängt ihre Entdeckungen nämlich nicht gerade an die große Glocke.
Das "Gesindel" wusste es ganz bestimmt. Microsoft hätte es auch wissen können. Immerhin ist das Problem seit 2017 bekannt. Aber in typischer MS Manier: Kopf in den Sand und dann auf Mitleid machen. Wer sich hierzu einlesen will verlinke ich mal einen Twitter Post:
https://twitter.com/elinesterov/status/1440764605521797133?s=19
Da gibt es auch eine PDF, die das Verfahren erklärt.
Die Tatsache das die Forscher die oben genannten TLD's noch reservieren konnten besagt das in diesen TLD's noch nichts dergleichen unternommen wurde, aber was ist mit autodiscover.de, die wurde nicht von den Forschern registriert und ist wohl schon vergeben, wer die wohl hat und was der wohl damit macht ???
Sehe ich das richtig, dass, wenn ich einen sauberen, auch aus dem Internet erreichbaren Autodiscover implementiert habe, dies dann nicht relevant ist, da er ja über die Firmen-Domain bereits korrekte Daten erhält und dann nicht mehr weitersuchen muss?
Ich würde jetzt mal besser nicht nach Ausreden suchen um die Sicherheitsempfehlungen nicht umzusetzen. Richtig umgesetzt bieten die Firewallregeln keinen Nachteil. Bis Microsoft einen Patch veröffentlicht hat, würde ich ehrlich gesagt nicht das Risiko eingehen wollen. Es ist nur eine Frage der Zeit, bis das aktiv ausgenutzt wird und dann vielleicht sogar noch smarter als hier beschrieben. Vielleicht wird es das auch bereits…
Ich sehe das auch so, dass wenn mein Exchange sauber Antwort gibt, ich nicht unmittelbar bedroht bin.
Natürlich, eine zusätzliche Sicherheit wären diese Firewall-Regeln schon, aber auch nur für meine internen Clients.
Man könnte aber über einen MIM Angriff die Verbindung zum Exchange und ein Downgrade erzwingen.
Selbst mit einem richtig konfiguriertem und funktionstüchtige Exchange kannst du dagegen nichts tun.
Würdige ich so sehen.
Zumal man bei der Domainnamenwahl geschlampt haben muss, weil man eine TLD als Domainnamen verwendet, bspw example.com. Mit einer Subdomain bspw. ads.example.com klappt es schon nicht mehr.
Ping autodiscover.de liefert IP
ping -a IP liefert: letzte.tankstelle.vor.der.datenautobahn.org
tracert IP
FireFox blockt
Virustotal.com liefert "harmless"
Blöde frage. Kann man die Basic authentication in Exchange 2016 nicht deaktivieren? Ich finde dazu nur etwas zu Exchange Online oder Exchange 2019.
Die moderne Authentifizierung kann ich aber im Exchange 2016 aktivieren per "Set-OrganizationConfig -OAuth2ClientProfileEnabled $true"
MS wusste auf jeden fall vorher nichts davon. Von Bleeping Computer:
Update 9/22/21: After reaching out to Microsoft about the bug, we were provided the following statement:
"We are actively investigating and will take appropriate steps to protect customers. We are committed to coordinated vulnerability disclosure, an industry standard, collaborative approach that reduces unnecessary risk for customers before issues are made public. Unfortunately, this issue was not reported to us before the researcher marketing team presented it to the media, so we learned of the claims today." Jeff Jones, Sr. Director, Microsoft.
Warum reden alle von Exchange?
Mit dem eigenen Exchange hat es doch keine Probleme? Problem sind die Clients – also Outlook, Android, iOS usw.
Das Protokoll ist kaputt – also alle Clients die das Protokoll "korrekt" umgesetzt haben sind betroffen. Alle Outlooks, alle Smartphones usw.
Warum musste eigentlich noch gleich das manuelle Konfigurieren in Outlook ganz abgeschafft werden? Neuere Ostlook-Versionen können ja nur noch Autodiscover und nix anderes mehr…
Da hast Du 100%ig recht – es geht um die Clients und nicht um den Exchange.
Korrekt müsste es heißen: Fehlerhafte Autodiscover Implementierung in zahlreichen Clients (Outlook, Outlook App for iOS/Android, etc.) ermöglicht Abgriff von Zugangsdaten
So hab ich das jetzt auch verstanden nach mehrmaligem durchlesen. Das Problem ist der Client und das dieser dank always-on Autodiscover auch nicht so leicht ausgehebelt werden kann. Intern kein Problem, von extern allerdings…
Doch. In einem Netzwerk mache ich die Autodiscover Adresse nicht verfügbar oder ändere sie zu einem anderen Server.
Damit zwinge ich den Client das Raten zu beginnen…
Richtig, es geht um die Clients.
Daran erkennt man, dass 99% der Leute das Problem nicht verstehen.
Kann jemand von euch das Problem mit einem Outlook Client nachvollziehen. Im MCSE Board https://www.mcseboard.de/topic/220656-das-n%C3%A4chste-exchange-security-thema/?tab=comments#comment-1425270 konnte mit Office 2016 und Android die Sicherheitslücke nicht reproduziert werden.
Ich konnte das bislang auch nicht reproduzieren. Weder mit Outlook 365 noch Outlook 2016. Laut Screenshots der vermeintlichen Finder müsste Outlook in Version 16.0.13901 betroffen sein.
Was ich komisch finde: Auf keinem der Screenshots ist ein erfolgreicher Angriff zu sehen. Antwortender Server ist immer windomain.local und für die Domain wird auch der Account eingerichtet.
Das Autodiscover Protokoll sieht diesen sog. Back-off doch gar nicht vor. Laut Definition muss das AutoD Request scheitern, wenn keine der vorgesehen Mehtoden funktioniert. Und zumindest bei Outlook ist das ja wohl auch der Fall.
Das ist also kein Designfehler sondern eine fehlerhafte Implementierungen in non-microsoft CLients.
Zumindest scheinen ältere Outlook-Clients das auch fehlerhaft implementiert zu haben – in den Screenshots des Entdeckers taucht Outlook 2016 mit Pings auf …
Auf welchem Screenshot sieht man wirklich Outlook 2016?
Auf dem Log-Snippet unterhalb von "Autodiscover clients were trying to authenticate to, along with their respected username and passwords:" im Originaltext sieht man Outlook 2016. Man sieht aber nicht welche Domäne angefragt wurde.
Auf dem Screenshot "Successful ol' switcheroo attack" sieht man wie ein Client, dessen Mail-Adresse @windomain.local ist, sich bei einem Server autodiscover.windomain.local meldet. Das ist das gewünschte Verhalten.
Haben die Autoren vielleicht fehlerhaft implementierte Clients gesehen oder Fälle bei denen die Nutzer das Feld mit der Mail-Adresse falsch befüllt haben? Wie schon vorher gefragt wurde: Wer konnte das bislang reproduzieren?
Exakt – die aussagekraft der ganzen Screenshots tendiert gegen null.
Ich bezweilfe nicht, dass es ein Problem mit ferhlerhaften AutoD Clients gibt – ich hab nur den Eindruck der Blog geht dabei (ggf. bewusst) in die falsche Richtung. Und er stellt nicht wirklich die Fakten dar
Eine wichtige Frage: Trifft autodiscover auch auf andere E-Mail-Anwendungen wie beispielsweise Thunderbird zu? Denn Thunderbird macht das Leben des Nutzers einfach, indem er auch nur seine E-Mail-Anschrift eintragen muss, der Rest erledigt Thunderbird von selber.