Autodiscover Guardicore

Am 23. Sep 2021 hat die Firma Guardicore einen Blogartikel veröffentlicht, der eine Sicherheitslücke im Autodiscover-Protokoll suggeriert. Da die IT-Welt durch den Hafnium Exploit im Frühjahr 2021 schon aufgeschreckt wurde, hat dieser Artikel in vielen "Fach"-Zeitschriften natürlich eine entsprechende Aufmerksamkeit bekommen.

Aus meiner Sicht zu unrecht, denn die angebliche Lücke ist keine direkte Gefahr für ihre Exchange Umgebung und schon seit 2017 bekannt. Aber ist zeigt das generelle Problem wenn unsichere Clients und Anwender ihre Credentials an fremde Server senden. Und dann könnte doch ein Risiko bestehen, wenn die Angreifer diese Zugänge z.B. per EWS, RDP oder VPN ausnutzen.

Mittwoch, 6. Okt 2021 17:00-18:00 Uhr: Sprechstunde zu "Autodiscover Sicherheit und Guardicore"
Wie schon zum Hafnium Exploit haben wir eine offene kostenfreie Sprechstunde abgehalten. Zukünftige Sprechstunden und Webcasts finden sie unter https://www.netatwork.de/webcasts/ oder melden Sie sich einfach für den Net at Work Newsletter unter https://www.netatwork.de/newsletter-abo/ an, um nichts zu verpassen.

Autodiscover Guardicore Security - Aufzeichnung der Sprechstunde am 6.10.2021
https://www.youtube.com/watch?v=PuGu5WGUMtE
Die Einleitung mit Firmenvorstellung und die Diskussion danach haben wir entfernt.

Guardicore Blog

Es geht im Grund um den Artikel auf der folgenden Seite:

"Autodiscovering the Great Leak"
https://www.guardicore.com/labs/autodiscovering-the-great-leak/

Der Autor behauptet, er haben viele Anmeldedaten bekommen, weil er viele Domains mit den Namen "Autodiscover-<tld>" registriert hat.


Quelle: https://www.guardicore.com/labs/autodiscovering-the-great-leak/ (23.09.2021)

 Er hat daraus gefolgert, dass viele Exchange Clients bei der Autodiscover-Anfrage bereitwillig nicht nur die internen Server oder per Autodiscover-Protokoll vorgegebenen Server gefragt hat sondern auch den DNS-Baum nach oben klettern würde. Ein Angreifer könnte dort nun einen Webserver aufstellen, der einen "401 authentication Required" ausliefert und damit den Client dazu bringt, seine Kennwortdaten gänzlich unverschlüsselt (BasicAuth) oder schwach geschützt zu übertragen.

Im Bereich Introduction zieht er folgenden Schlüsse:


Quelle: https://www.guardicore.com/labs/autodiscovering-the-great-leak/ (23.09.2021)

Korrekterweise bezeichnet er eine Quelle als "poor implementation". Da kann Microsoft nun dann was dazu, wenn es Microsoft Code ist , der die im überlassenen Daten an fremde Server sendet. Neben Outlook gibt es aber noch viele andere Clients anderer Hersteller. Er führt sogar ein Beispiel dazu auf


Quelle: https://www.guardicore.com/labs/autodiscovering-the-great-leak/ (23.09.2021)

Interessanterweise ist hier "curl" als UserAgent enthalten und es ist ein HTTP-Stream. Ich wüsste nicht, dass Microsoft als UserAgent mit CURL arbeitet und auf HTTPS verzichtet. Ich bin sehr sicher, das dieses Bild keine reale Anfrage wiedergibt. Generell wäre hier eine Liste der realen UserAgents interessant, die Guardicore sicher auch hat.

Nach meinen Recherchen gibt es den beschrieben "Back-off" Algorithm in keiner Beschreibung von Microsoft. Eine Quelle wird nicht vom Autor genannt.

Dankenswerterweise verweist er kurz darauf auch auf die Funktion von Autodiscover.

Ich habe all meine Clients und DNS-Server-Logs überprüft aber keinen einzigen Treffer auf "autodiscover.de" oder eine andere Top-Level-Domain gefunden. Zumindest in meiner Umgebung gibt es also keinen Client, der so eine Abfrage versucht hat. Leider ist der Blog-Artikel von "Amit Serper" an der Stelle sehr oberflächlich. Eine Information, welcher Client sich so ungeschickt verhält, bleibt er schuldig. Das sieht eher nach "ClickBait" und FUD (Fear, Uncertainty and Doubt)

Im weiteren Artikel beschreibt der Autor, wie aus seiner Sicht eine Autodiscover-Auflösung funktioniert

Quelle: https://www.guardicore.com/labs/autodiscovering-the-great-leak/ (23.09.2021)

Die Beschreibung und 1. und 2. gehe ich noch mit. Die von mir rot umrandete Aussage kann ich aber nicht generell bestätigen. Wenn dem aber so ist, dann kann ich als Inhaber einer Stammdomäne des jeweiligen Landes natürlich den Client einfangen, wenn keine der vorherigen URLs erreichbar ist.  Wenn die den Artikel weiter lesen, dann kommen sie irgendwann an die letzte Stufe des Angriffs, an dem der Anwender einen Kennwort-Dialog bekommt, in den er seine Anmeldedaten eingeben muss, damit diese dann wirklich an den Angreifer des Webservers übermittelt werden.


Quelle: https://www.guardicore.com/labs/autodiscovering-the-great-leak/ (23.09.2021)

Ich gebe zu, dass viele Anwender hier sich vermutlich ärgern, dass Sie wieder ihre Daten eingeben müssen, aber es letztlich tun. Und dann hat die Falls zugeschnappt. Das Problem ist aber nicht neu und nicht auf Autodiscover beschränkt. Es ist eine generelle Problemstellung, wann und wo die Anwender ihre Kennworte eingeben. Daher ist ja Login ohne Kennwort (Passwordless) in aller Munde und generell auch "integrierte Anmeldung". Idealerweise muss sich ein Anwender nur einmal am Morgen zum Entsperren des Clients authentifizieren und jede weitere Abfrage sollte den Anwender stutzig machen.

Wenn Guardicore wirklich so viele Zugangsdaten gesammelt hat, dann könnten Sie die Mailadressen z.B. https://haveibeenpwned.com/ als kompromittiert melden.

Interessantes Details: Am 29.9 hat Akamai die Firma Guardicore für 600Mio gekauft.

Ich bin sicher, dass diese Verhandlungen schon Monate vorher angefangen haben. Insofern ist die Veröffentlichung des "Great Leak" noch mal zu hinterfragen. Wollte Akamai damit nichts zu tun haben, oder sollte das noch mal die Aufmerksamkeit auf die Firma gelenkt werden?

Client in Kurzfassung

Die Funktion des Clients habe ich auf Autodiscover - Grundlagen und Autodiscover Sicherheit schon ausführlicher beschrieben. In Kurzform macht Outlook aber:

  • LDAP Abfrage nach dem Feld "mail"
    So kann Outlook dem Anwender die Mailadresse vorschlagen und automatisch die Konfiguration erkennen. Wenn das Feld nicht gefüllt ist oder der Anwender keine Verbindung zum DC hat, fragt Outlook nach der Mailadresse. Hier könnte sich ein Anwender natürlich in der Domain vertippen und damit später den falschen Server ansprechen. Was könnte ein Grund sein. Wen ich z.B. "frank@de" als Mailadresse eingebe, dann wäre das ungeschickt
  • LDAP Abfrage zum SCP-Punkte
    Outlook mit Verbindung zum DC holt sich per LDAP-Anfrage die URLs zu den Exchange Servern. Gelingt dies, dann fragt er diese Server und ignoriert dabei sogar das Zertifikat. Wir sind aber komplett intern und ist daher hier nicht zutreffend.
  • Zugriff auf https://<maildomain>/autodiscover/autodiscover.svc
    Der Zugriff auf diese Webseite kann nicht bei Guardicore oder einen Angreifer landen. Es ist meist die eigene öffentliche Webseite unter der Kontrolle des Inhabers. Zumindest sollte Sie es sein, dass hier kein Schadcode lauert. Hier kann Guardicore nichts erhalten haben.
  • Zugriff auf https://autodiscover.<maildomain>/autodiscover/autodiscover.svc
    Dann versucht der Client die Maildomain mit vorangesetztem "autodiscover" per HTTPS. Der Zugriff landet nicht auf einem Server von Guardicore
  • Redirect-Zugriff auf http://autodiscover.<maildomain>
    Der einzige Autodiscover-Zugriff, der unverschlüsselt über HTTP erfolgt, dient nur zur Umleitung. So arbeitet .z.B. Office 365. Der Zugriff landet nicht auf einem Server von Guardicore.
  • Lokale AutoD-Einträge
    Ein Administrator kann zusätzlich auch auf jedem Client per Gruppenrichtlinien, Regedit u.a. entsprechende "Hinweise" zu Autodiscover-Dienste eintragen. Das ist aber eher unwahrscheinlich..

Das Risiko für einen korrekt arbeitenden Client ist daher minimal, dass er hier seine Zugangsdaten an einen nicht vertrauenswürdigen Service abgibt. Dennoch steht die Behauptung im Raum, die aber von Guardicore nicht mit prüfbaren Details weiter untermauert wurde. Allerdings kann man auch Outlook bzw. jede Software mal kritisch hinterfragen, warum Kennwort-Dialoge keine Information über die Gegenstelle liefern. Da ist Outlook auch nicht gerade fortschrittlich. Wenn ich Outlook starte und die Credentials neu eingegeben werden müssen, dann sehe ich auch nur folgende Meldung:

Richtig erkennen kann ich hier aber auch nicht, welcher Server nun die eingegebenen Informationen bekommt. Ein kleiner Hinweise auf das Zertifikat oder den Server wäre schon wünschenswert.

Autodiscover.de

Da die meisten Leser meiner Seite ja in Deutschland sind, hat mich die Domain "Autodiscover.de" besonders interessiert. Hier wären dann ja alle Anfragen angekommen, bei denen die Postfächer in einer DE-Domain liegen Sollte hier jemand dann einen Client starten, der "Autodiscover" versucht und die Vorgaben von Microsoft etwas lockerer sieht, dann könnte auch auf https://autodiscover.de/net/org/com/co.uk/ u.a. landen. Interessanterweise wurde die "autodiscover.de"-Zone am 23.9 geändert.

C:\>nslookup -q=SOA autodiscover.de
Server:  fritz.box
Address:  192.168.178.1

Nicht autorisierende Antwort:
autodiscover.de
        primary name server = root-dns.netcup.net
        responsible mail addr = dnsadmin.netcup.net
        serial  = 2021092380
        refresh = 28800 (8 hours)
        retry   = 7200 (2 hours)
        expire  = 1209600 (14 days)
        default TTL = 86400 (1 day)

root-dns.netcup.net     internet address = 46.38.225.225
root-dns.netcup.net     AAAA IPv6 address = 2a03:4000:0:1::e1e1

Allerdings ist autodiscover.de schon viele Jahre belegt und laut Wayback-Machine enthält die Seite eine ungefährliche Weiterleitung zu Metager.

Die Weiterleitung ging 2013 noch auf https://www.google.de und seit 4. Jan 2018 auf https://www.metager.de.  Ein Check ergab auch einen 404-Fehler, d.h. der Client hat keine Anforderung zur Anmeldung bekommen.

# Stand 28. Sep 2021
(Invoke-WebRequest https://autodiscover.de/autodiscover/autodiscover.svc -SkipHttpErrorCheck).statuscode
404

Achtung:
Mittlerweile kommt kein 404 Fehler sondern ein 401, worauf ein defekter Client einen Kennwort-Dialog anzeigen könnte. Der DNS-Server ist bei netcup.net gehostet, die auf netcup.de weiterleitet und der Provider ist laut https://www.netcup.de/ueber-netcup/partner.php ein ACS-Teilnehmer (https://www.allianz-fuer-cybersicherheit.de)

Dennoch finde ich das aktuell Verhalten eines 401 "befremdlich" oder sogar gefährlich, denn Zugangsdaten können so abgefragt werden.

# Stand 03. Okt 2021
(Invoke-WebRequest https://autodiscover.de/autodiscover/autodiscover.svc -SkipHttpErrorCheck).statuscode
401

Der bisherige Inhaber der Domain "autodiscover.de" hat sich per digital signierter Mail bei mir gemeldet. Um zu beweisen, das er zu dem Zeitpunkt der "Besitzer" der Domain war, hat er sogar einen Eintrag carius.autodiscover.de addiert. Sehr professionell. So abgesichert möchte ich ein paar Hintergründe zur Domain aufführen, die mir genannt wurden.

  • Die Domain wurde vermutlich um 2010 registriert
    So genau wusste er es auch nicht mehr und durch verschiedene Providerwechsel lässt sich das auch so schnell nicht mehr genau ermitteln.
  • Keine böse Absicht
    Die Domain hatte laut Inhaber immer nur die Seite "Hier gibt es nichts zu sehen" mit einer Weiterleitung zu www.google.de und später zu www.metager.de. Lange Zeit war kein Zertifikat gebunden, so dass die HTTPS-Anfragen sowieso nicht angenommen wurden
  • Die Domain wird angeblich an das BSI übergeben
    Der aktuelle Inhaber koordiniert nach eigener Aussage gerade mit dem BSI die Übergabe der Domain. Das BSI würde dazu in Kürze eine Mitteilung veröffentlichen und zukünftig "autodiscover.de" betreiben. Die von mir erkannte DNS-Änderung am 23.9 hängen angeblich damit zusammen.
  • Geringe Anzahl an Requests
    Ich habe keine absolute Zahl und der bisherige Betreiber wird schon aus DSGVO-Gründen die Logs nicht Jahrelang vorhalten. Aber eine Aussage möchte ich zitieren.

...In jedem Fall kann ich anhand der Anzahl realer Autodiscover-Anfragen, die in der Vergangenheit beim Server ankamen, schon direkt sagen, dass das Problem bei weitem nicht so dramatisch ist, wie es derzeit dargestellt wird. Keineswegs landen Anfragen aller Leute, die sich ein Mailkonto in Outlook einrichten für eine ".de"-Maildomain, die keinen Autodiscover-Server hat, dann bei "autodiscover.de". Dafür ist die Anzahl dort eingehender Anfragen einfach viel zu gering...

...Tatsächlich waren es aber allenfalls wenige Dutzend Anfragen am Tag, die (zu normalen Zeiten) beim Server "autodiscover.de" ankamen. Erst als die Artikel in den Medien dazu kamen, stieg die Anzahl an Zugriffen plötzlich stark an, allerdings meistens durch Leute, die per Browser "nur mal gucken" wollten, ...

  • Interessante UserAgenten
    Aus den WebServer-Logs der letzten Zeit sind Rückschlüsse auf die Applikation möglich. Ich gehe nicht davon aus, dass der UserAgent gefälscht,
Microsoft Office/16.0 (Windows NT 10.0; Microsoft Access 16.0.13127; Pro)
Microsoft Office/16.0 (Windows NT 10.0; Microsoft Access 16.0.10361; Pro)
Microsoft Office/16.0 (Windows NT 10.0; Microsoft Access 16.0.4513; Pro)
Microsoft Office/16.0 (Windows NT 10.0; Microsoft Excel 16.0.13127; Pro)
Microsoft Office/16.0 (Windows NT 10.0; Microsoft Excel 16.0.10361; Pro)
Microsoft Office/16.0 (Windows NT 10.0; Microsoft Excel 16.0.10369; Pro)
Microsoft Office/16.0 (Windows NT 10.0; Microsoft Excel 16.0.10356; Pro)
Microsoft Office/16.0 (Windows NT 10.0; Microsoft PowerPoint 16.0.13127; Pro)
Microsoft Office/16.0 (Windows NT 10.0; Microsoft PowerPoint 16.0.4513; Pro)
Microsoft Office/16.0 (Windows NT 10.0; Microsoft PowerPoint 16.0.10368; Pro)
Microsoft Office/16.0 (Windows NT 10.0; Microsoft Publisher 16.0.13901; Pro)
Microsoft Office/16.0 (Windows NT 10.0; Microsoft Word 16.0.13127; Pro)
Microsoft Office/15.0 (Windows NT 6.2; InfoPath Editor 15.0.5172; Pro)
Microsoft Office/16.0 (Windows NT 6.2; NameControlServer 16.0.13127; Pro)
Business/6.28.1.8 CFNetwork/1240.0.4 Darwin/20.6.0
Microsoft Office/16.0 (Windows NT 6.2; MAPI 16.0.13127; Pro)

Wir sehen hier erst einmal sehr viele Microsoft Office Client aber kein natives Outlook. Es sind eher die Applikationen wie Word, Excel, PowerPoint, Access die hier manchmal nicht an die Autodiscover-Vorgabe halten, wenn ein Anwender vermutlich auf "Mail senden" klickt. Der "NameControlServer" ist eine Microsoft Komponente, die in Office Applikationen den Präsenzstatus abfragen kann während CFNetwork/Darwin auf eine Software auf MacOS/IOS hinweist.

Ich finde es aber schon interessant, dass zumindest in der Stichprobe wirklich "nur" Microsoft-Software aufgelistet wird und keine anderen "Autodiscover"-Produkte wie z.B. die "EWS Managed API" oder verschiedene JavaScript/Java/Python/PHP-Klassen, die ebenfalls Autodiscover unterstützen.

Da muss Microsoft wohl doch noch mal genauer schauen, was die Office Entwickler da nicht verstanden haben oder es liegt wirklich am DNS-Server oder Konfiguration des Kunden, der bei fehlender Auflösung den Baum hochwandert: Stichwort "DNS Suffix Liste" in den Einstellungen der Netzwerkkarte

Aber auch dazu hätte man die IP-Adresse des Clients auf eine Firma zuordnen müssen und direkt mit deren Administratoren die Ursache weiter einkreisen.

Die Rolle der Gazetten

Die Lücke ist aber auch ein Beispiel über die Qualität von Berichten im Internet über Sicherheitslücken. In der heutigen schnelllebigen Welt ist es wichtig, Informationen früh zu veröffentlichen um in Suchmaschinen gefunden und über spätere Veröffentlichungen als Quelle genannt zu werden. Das bringt Besucher und damit auch Geld über die geschalteten Werbeanzeigen.

Daher dauerte es nicht lange, bis die üblichen Verdächtigen ganz schnell einen eigenen Artikel zu der Thematik geschrieben haben. Hier ein paar Beispiele:

Über diesen Weg (bei mir war es Heise Newsticker) habe ich auch von dem Blog-Artikel erfahren. Allerdings habe ich mir den Artikel auch komplett durchgelesen und versucht, den Angriffsvektor zu verstehen. Dabei sind mir aber drei Dinge aufgefallen, die jeden Redakteur

  • Responsible Disclosure?
    In der Security-Branche hat es sich eingebürgert, dass erkannte Lücken erst einmal dem Hersteller gemeldet werden. Teilweise wird das sogar honoriert und es ist viel interessanter später im CVE oder Fix auch genannt zu werden. (Siehe auch Intel RootCA Fehler (CVE-2019-11095)) oder der Hersteller sagt, dass die Lücke nicht relevant ist (Siehe BMW 225xe "undicht"). In dem Artikel habe ich keine Hinweise auf eine vorherige Kommunikation mit Microsoft gefunden obwohl Autor und Firma nicht anonym sind. Da müssten schonalle Warnglocken läuten, nachdem ein Stern mal auf Hitler-Tagebücher reingefallen ist.
    Stattdessen haben sie "mit einigen der betroffenen Herstellern" den Prozess begonnen

    Warum nur mit einigen Herstellern und nicht mit allen? Wenn Sie schon drüber bloggen, dann ist es nicht mehr "responsible" und welche Hersteller sind es dann?

ich bin mal gespannt auf das "More details on that aspect will be released as a second part to this paper.". Riecht eher nach ClickBait, denn was soll da noch kommen, was man nicht auch gleich veröffentlichen könnte?

  • Irrführende Daten
    Der Artikel hat kaum Substanz bezüglich belastbarer Belege. Ich hätte mit den gesammelten Zugangsdaten zumindest mal versucht, die ein oder andere Firma anzusprechen und zu warnen. Ein Sample mit CURL ist irreführend.
  • Links zu Blackhat 2017 o.ä.
    Es gibt zwar Link zum Vortrag von "Shape Security" und die Datensätze CVE-2016-9940, CVE-2017-2414 aber mit dem Hinweis, dass die Bugs schon alle von Samsung und Apple gefixt seien.
  • Kein eigener CVE
    Als ich meine Lücke in der Intel Software (Intel RootCA Fehler (CVE-2019-11095)) gemeldet habe, hatte ich schneller eine eigene CVE-Nummer als ich danach fragen konnte. Wenn die Lücke hier so groß wäre, dann wäre ein CVE nur logisch.
  • Cui Bono - Wem nützt es
    Dazu muss man beachten, dass der Autor, zugleich Mitarbeiter von Guardicore ist, und auf die eigene Firewall verweist, die solche DNS-Anfragen an autodiscover.<tld> blocken kann. Schade nur, dass dies natürlich nur die Firmen-Clients schützt, die normalerweise lokal schon eine Autodiscover-Auflösung erfolgreich abgeschlossen haben. Computer im Homeoffice laufen normalerweise ja nicht durch die DNS-Server der Firmenfirewall. Selbst eine Blockade dieser DNS-Abfragen ist nicht wirklich hilfreich.

Der Vorfall "Guardicore" wirft ein unschönes Licht auf die Arbeit verschiedener "Computer-Fachzeitschriften", bei denen die gewünschte Schnelligkeit in Verbindung mit Klickraten und Werbeeinnahmen manchmal die seriöse Bewertung der Quellen, entsprechende Rückfragen und eigene Berichterstattung verdrängt. Selbst mit einigen Tagen Verzögerung wird weiter versucht, Quote zu machen.

Anscheinend hat es sich noch nicht rumgesprochen, dass es keine Sicherheitslücke im "Autodiscover-Protokoll" ist und auch die Exchange Server nicht betroffen sind sondern nur Clients und Benutzer dumm genug sein könnten, ihre Anmeldedaten auszuleiten. Genau genommen sind sogar Firmen ohne Exchange höher gefährdet. Am Ende bleiben verunsicherte Administratoren und IT-Leiter zurück.

Die Rolle des BSI

Der bisherige Betreiber von autodiscover.de hat die Domäne am 29. Sep an das BSI übertragen, die dann ein "Sinkhole" installiert haben. Im Grunde ist das eine gute Idee so die Clients zu finden, die unsicher sind und die Absender zu informieren. Allerdings war das Sinkhole am Anfang noch nicht erreichbar und spätestens ab dem 3. Okt hat es einen 401 geliefert. Der 401 war auch am 7. Okt noch aktiv. Hier ein Fiddler-Mitschnitt:

Unschön ist dabei, dass die defekten Clients ihren Anwender z.B. dazu auffordern könnten, gültige Zugangsdaten zu übermitteln, die dank "BasicAuth" nur BASE64-codiert wären. Dass dabei die Webseite auch unterschlüsselt erreichbar ist und auch da mit einen 401 mit BasicAuth antwortet, macht es noch schlimmer. Natürlich habe ich das BSI auch darauf hingewiesen und meine Beobachtungen wurden bestätigt und der Tipp einen 404 zu senden und die erhaltenen Daten im Payload zu nutzen, wollten Sie auch noch umsetzen

.
Auszug aus meiner Präsentation zu Autodiscover Sicherheit. Konversation auf https://twitter.com/BSI_Bund/status/1445409758048096267 

Die Meldung kam aber schon am 5.10. Ich werde weiter prüfen.

Zusammenfassung

Diese fehlende Information möchte ich hier beisteuern.

  • Keine Lücke im Exchange Server
    Die Exchange Administratoren brauchen keine Nachtschicht zum Patchen von Exchange aufgrund dieser Lücke einplanen. Sie können auch nichts dagegen tun, wenn Clients sich unsicher verhalten. Sie können aber prüfen, dass sie für jede Domain einen "Autodiscover-Eintrag" veröffentlichen, damit die wenigen "defekten" Clients dort landen und nicht weiterziehen.
  • Höheres Risiko, wer kein Exchange hat.
    Dann kann ein defekter Client keine Zugangspunkte per SCP oder Autodiscover finden und bis zu einer Autodiscover-Topdomains durchrutschen. Für diesen Fall könnten Sie auf ihrer Firewall oder dem DNS-Server die Autodiscover-Anfragen für Firmenclients blockieren. Es wäre kein Schutz für Homeuser.
  • Es betrifft keine DE-Domains
    Die "autodiscover.de"-Domain wurde nicht zum Abfischen von Anmeldedaten verwendet und wird durch die Übernahme durch das BSI weiter gesichert. Vielleicht meldet sich aber mal das BSI bei den anfragenden Clients. Wäre ein netter Service, denn sie sehen ja die angefragte Mailadresse.
  • Es betrifft eher wenige Clients
    Wenn des ein grundlegendes Problem wäre, wäre das dem Webhoster von "autodiscover.de" schon viel früher aufgefallen. Aber die Logs zeigen, dass es wenige Fälle sind, die hier auffallen. Aber jeder Fall ist natürlich Einer zu viel.
  • Client-Versionen
    Jede Software auf dem Client, die im Kontext des Benutzers gestartet wird, hat Zugriff auf Anmeldeinformationen. Wenn hier eine Software die Zugangsdaten an unsichere Server sendet, dann hat die Software auf ihrem PC nichts verloren. Wir haben gesehen, dass auch einige Office-Anwendungen dazu gehören, was durch ein Updates von Microsoft gelöst werden sollte.
  • Sichere Authentication
    Normalerweise sendet Outlook an "externe Domains" keine Anmeldedaten. Hier meine Standard-Einstellung im Browser.

    Sie müssten also generell eine "unsichere" Einstellung vorgenommen haben und selbst dann funktioniert dies nur mit Kerberos oder NTLM. Wenn eine andere Webseite eine "Basic Authentication" fordert, denn muss der Benutzer seine Anmeldedaten explizit eingeben.
  • Anmeldung (Anwender)
    Wie immer sollten auch die Anwender geschult werden, dass Sie jeden Kennwortdialog kritisch hinterfragen. Denn solche Dialoge sind immer kritisch und können auch durch andere Methoden provoziert werden.
  • Schutz der Anmeldung per 2FA/MFA
    Es wird immer wieder passieren, dass Anwender ihre Anmeldedaten "verlieren". Daher ist der zussätzliche Schutz durch einen weiteren Faktor immer wichtiger.
  • Kontrolle/Blockade
    Wer einen eigenen DNS-Server betreibt, der die DNS-Abfrage protokolliert (eher selten) oder der Cache ausgelesen werden kann, kann hier prüfen, ob es solche Abfragen gegeben hat.
  • Anmeldungen überwachen
    Es ist recht unwahrscheinlich, dass Angreifer eine "Autodiscover.<tld>"-Domain genutzt haben und wenn Guardicore seriös ist, nutzen sie ihre Anmeldedaten auch nicht weiter. In https://haveibeenpwned.com/ habe ich noch keine Meldung zu dem Leak gesehen. Dennoch ist es immer eine gute Idee, die Anmeldungen speziell aus dem Internet über 2FA/MFA abzusichern und zu überwachen. Aber das ist nicht neu
  •  Webseite auf https://<maildomain>
    Was gerne übersehen wird ist der legitime und definierte Autodiscover-Zugriff auf https://<maildomain>. Ich hoffe, dass sie alle ihre Marketing-Webseiten unter Kontrolle haben. Nicht das hier jemand über eine Lücke im CMS die eine Autodiscover-Logik aushebelt.

Ich werde die Seite entsprechend aktualisieren, wenn die Umstände klarer werden.

Weitere Links

All your emails belong to us: exploiting vulnerable email clients via domain name collision
https://www.blackhat.com/docs/asia-17/materials/asia-17-Nesterov-All-Your-Emails-Belong-To-Us-Exploiting-Vulnerable-Email-Clients-Via-Domain-Name-Collision-wp.pdf
Das PDF beschreibt die Sicht des Clients, d.h. wie kann ich den Client dazu bringen, nicht den vertrauenswürdigen Server in der Firma zu fragen sondern meinen "bösen" Server, der denn hoffentlich die Anmeldeinformationen des Clients in einer Form erhält, die für mich entschlüsselbar ist.