Autodiscover Sicherheit

Wer immer einen Webservice im Internet bereitstellt, muss sich auch Gedanken über die Sicherheit machen. Schließlich soll nicht nur ein Anwender die gewünschten Informationen erhalten. Ein Angreifer darf keine Informationen bekommen und auch die Angriffsfläche sollte minimal sein.

Am 23. Sep 2021 hat die Firma Guardicore  einen Blogartikel veröffentlicht, der Zeit wie Autodiscover Clients sich verleiten lassen, Zugangsdaten an fremde Server zu senden. Eine vorläufige Einschätzung finden Sie unter Autodiscover Guardicore

Viel kritischer finde ich den möglichen Angriff über das Risiko eigene Webseite

Wer macht Autodiscover?

Für Autodiscover sind die beiden Endpunkte zu betrachten:

  • Server
    Der Server ist in der Regel ein Exchange Server, der die Anfragen der Client annimmt, eine Authentifizierung anfordert und dann das Ergebniss als XML-Struktur zurückliefert
  • Client
    Der Client hingegen fragt ab und sollte schon sehr sicher sein, dass er die ihm angertrauten Anmeldeinformationen auf sichere Weise an den richtigen Server übermittelt

Zwischen den beiden Endpunkten ist nämlich nicht immer ein sicheres Netzwerk sondern oft auch das rauhe ungesicherte Internet mit DNS-Servern.

Der Server

Die Aufgabe des Service ist es, dem Anwender nach Übermittlung einer korrekt formulierten Anfrage samt Authentifizierung die gewünschte Information zu liefern. Exchange fragt dazu dann das lokale Active Directory ab, um zur übermittelten Mailadresse die Zugangsdaten zu liefern. Die angefragte Mailadresse muss nicht mit der Authentifizierung übereinstimmen. Der Client kann sich durchaus als "UserA" anmelden, um die Zugangspunkt für UserB oder z.B. einem Raum oder eine ShareMailbox zu erfragen. Wichtig ist aber, dass eine Authentifizierung erfolgt ist. Damit gibt es mehrere Angriffsvektoren:

  • Authentifizierung Probing
    Wenn ein Angreifer vermutlich gültige Zugangsdaten irgendwie erhalten hat, könnte er per HTTP-Authentifizierung prüfen, ob diese Anmeldedaten korrekt sind und funktionieren. Eine Autodiscover-Anfrage ist in der Regel unverdächtig. Ein Schutz ist hier möglich, wenn auch für Autodiscover eine mehrstufige Anmeldung (2FA, MFA) aktiviert ist und eine Anmeldung per OAUTH-Token erfolgt. Dann kann der Token-Server sich um die Legitimierung einer Anmeldung kümmern.
  • Authentifizierung DoS
    Ein Angreifer kann natürlich auch einfach Zugangsdaten durchprobieren, bis er mit Glück einen Zugang errät. Wenn er allzu forsch dies macht, dann kann er sogar das Anmeldekonto des Anwender sperren. Der Angreifer hat zwar keine Daten erhalten aber stört den Betrieb der Firma nachhaltig. DoS-Attacken sind durchaus eine Gefahr aber können z.B. durch OAUTH und 2FA/MFA verhindert werden.
  • Code-Fehler/Ungültige Daten
    Nicht erst seid dem Hafnium Exploit ist bekannt, dass auch Webanwendungen auf einem Server nicht immer alle Daten korrekt verifizieren und manchmal kommt es zu einem Pufferüberlauf, bei dem der Server dann mit übermittelten Code ausführt.
    Es gibt Reverse-Proxy-Systeme
  • Server/Bandbreiten DDoS
    Natürlich kann ein Angreifer mit einer ganzen Farm von Clients so viele Anfragen stellen, dass ihr Server oder die Bandbreite überlastet wird. Es kostet den Server durchaus einige Ressourcen die Anfrage per LDAP gegen einen Domaincontroller zu beantworten und Ressourcen sind nun mal endlich. Gegenmaßnahmen könnten eigene Server für Autodiscover sein, die vom Postfachserver und Clientzugriff getrennt sind oder Bandbreitendrosseln nach Source-IP auch wenige Kbyte/Minute. Autodiscover-Anfragen sind pro Client-IP eher wenig. Auch OAUTH kann hier helfen, wenn der Server die Authentifizierung direkt durch die lokale Prüfung des Tickets erledigen kann und nicht erst den Anmeldeserver fragen muss

Wie immer ist es also eine Risikoabschätzung, wie wahrscheinlich ein Angreifer ihren Service durch Überlastung oder Probing lahmlegen oder "knacken" kann und welche Vorkehrungen sie über Bandbreitendrosseln, Reverse-Proxy-Server, DoS-Schutz, OAUTH, 2FA/MFA das System besser sichern.

Es kann aber durchaus sinnvoll sein, den Zugriff auf ihre "Marketing-Webseite" auf den Pfad /autodiscover zu überwachen. Ein "404 not found" oder jede andere Antwort ist erlaubt, solange Sie keine Authentifizierung anfordert. Eine Antwort sollte also kein 401.x liefern, weil dann der Client versucht sein könnte, Anmeldedaten zu senden.

Das geht per PowerShell auch recht einfach:

(Invoke-WebRequest "https://msxfaq.de/autodiscover/autodiscover.svc" -SkipHttpErrorCheck).statuscode
404

Der Client

Die Spezifikation, wie ein Client per Autodiscover an seine Information kommt, hat Microsoft schon früh veröffentlicht und auch auf der MSXFAQ gibt es viele Seiten zu dem Thema.

Wenn sich der Client daran hält, dann arbeitet er eine Liste von Optionen ab, um einen erreichbaren und gültigen Autodiscover-Server zu erreichen. Es liegt komplett in der Hand und Verantwortung des Betreibers, diese Möglichkeiten auch betriebsbereit anzubieten. Das sind:

  • SCP-Punkte
    Exchange veröffentlicht im Active Directory die Information zur Autodiscover-URL, die ein Client intern per LDAP erfragen und dann erreichen kann. Wenn der Client über den Weg eine URL bekommt, dann "vertraut" er dieser URL, selbst wenn das Zertifikat ein "Self Signed"-Zertifikat ist. Ein Angreifer wäre also schon im LAN, um diesen Zugriff dann umzuleiten und an die Anmeldedaten zu kommen. Dies ist technisch alles möglich aber dann ist ihre Firma eh schon "geknackt"
  • Zugriff auf https://<maildomain>/autodiscover/autodiscover.svc
    Warum auch immer versucht der Client immer zuerst diese URL. Früher war das ein Problem, wenn die Adresse auf die "Webseite der Firma beim Hoster" gegangen ist und das Zertifikat nur auf www.<maildomain> ausgestellt war. Das ist heute durch ein SAN/Wildcard-Zertifikat in der Regel kein Problem mehr. Wenn es mir als Angreifer aber gelingt, auf ihrer Webseite, z.B. Wordpress, ein Unterverzeichnis "/autodisover" zu platzieren, dann kann ich schon recht einfach die Credentials der Anwender abrufen. Das ist aus meiner Sicht schon ein "kritischer" Angriffspunkt. Viele Firmen sind sich dessen gar nicht bewusst, welches Risiko die eigene "Marketing-Webseite" auf den Betrieb haben kann.
  • Zugriff auf https://autodiscover.<maildomain>/autodiscover/autodiscover.svc
    Wenn der Client nicht per SCP an einen Server kommt, dann ist es im Internet oder unterstützt kein SCP, wie z.B. der Skype for Business Client. Der Client baut dann immer eine HTTPS-Verbindung auf und prüft auch das Zertifikat. Ein Angreifer muss schon viel Aufwand betreiben, um diesen Zugriff umzuleiten, z.B. durch Proxy-Einstellungen, eigene RootCAs. Ja, es ist denkbar aber wenig wahrscheinlich. Allerdings könnte er dann ein Downgrade der in HTTPS verschlüsselten Authentifizierung versuchen um an die Anmeldedaten zu kommen.
  • 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. Microsoft kann ja kaum für jede Kundendomain ein Zertifikat auf autodiscover.<kundendomain> installieren und daher verweist hier der Autodiscover-Eintrag auf einen Hoster, der auf Port 443 nicht erreichbar ist. Outlook erwartet dann einen Redirect auf die richtige Adresse, die der Anwender aber bestätigen muss, wenn die URL nicht als "Trusted" lokal eingetragen ist.
  • Lokale AutoD-Einträge
    Ein Administrator kann zusätzlich auch auf jedem Client per Gruppenrichtlinien, Regedit u.a. entsprechende "Hinweise" zu Autodiscover-Dienste eintragen, die Outlook dann nutzt. Ein Angreifer könnte hier also den Client auf einen eigenen Server umlenken. Bedenken Sie aber, dass der Angreifer schon "Benutzer" auf dem Client ist und damit viel einfachere Wege existieren, an Anmeldedaten und Dateien zu kommen.

Das Risiko für einen korrekt arbeitenden Client ist daher minimal, dass er hier seine Zugangsdaten an einen nicht vertrauenswürdigen Service abgibt.

AutodiscoverV2

Mittlerweile gibt es eine neue Version von Autodiscover, die aber weniger hinsichtlich der Abfrage von Credentials ein Risiko sein könnte. AutodiscoverV2 kann sogar anonym per REST abgefragt werden und wenn Sie eine Mailadresse eines Empfängers wissen, dann können Sie durchaus auch anonym etwas über den Empfänger erfahren, z.B. ob er On-Premises oder in Exchange Online ist.

Damit umgeht Microsoft natürlich das Risiko, dass hier schon Anmeldedaten übertragen werden müssten und der Server hat eine Angriffsfläche weniger. Wenn der Client aber dann die Zielumgebung ermittelt hat, muss er sich dort doch wieder anmelden. Die Authentifizierung wird also nur etwas weiter nach hinten verlagert.

Autodiscover/AutoConfig

Microsoft war nicht die erste Firma, die sich Gedanken über eine "automatische Konfiguration" von E-Mail Clients gemacht hat. Und einige Provider nutzen dies sogar selbst. Alle Ideen basieren aber darauf, dass der Client sich anhand der DNS-Domain der Mailadresse irgendwie zu einem Server verbindet, der nach einer Anmeldung dann die Konfiguration ausliefert.

Jeder vergleichbare Dienst unterliegt den gleichen Anforderungen. Wenn der Anwender, plumpt gesagt, zu blöde ist die richtige Mailadresse einzugeben und ein Angreifer eine Vertipper-Domain samt Autodiscover betreibt, dann kann er die Zugangsdaten erhalten.

Das ist wie das Aufstellen einer Geldautomatenattrappe, in die jemand seine Karte einzieht und die PIN eingibt.

Das Umfeld

Aber es gibt durchaus Szenarien, in denen auch ein Firmenclient einen Fehler machen können, z.B.:

  • Kein Exchange im Einsatz
    Wenn eine Firma z.B.: Notes nutzt und damit "autodiscover.example.com" nicht belegt ist. Ein Angreifer können nun versuchen, den Eintrag "autodiscover.<firma>" im DNS unterzubringen oder per Spoofing vorzugeben. Dann müsste nur noch ein Client (z.B. SmartPhone o.ä.) eine Software starten, die Autodiscover nutzt. Der Angreifer brauch dann "nur" noch einen Webserver, der einen 401 mit geeigneten "Authentication-Header" ausliefert und mit etwas Glück kommt er an gültige Anmeldedaten
  • Falsche Domain
    Es soll Kunden geben, die nutzen als DNS-Domain für ihr Active Directory eine öffentliche Domäne, die ihnen aber nicht gehört. Früher war z.B. die TLD ".ads" nicht in Verwendung und es gibt durchaus Firmen, die "ADS" als Toplevel Domain intern verwenden, z.B. "firma.ads". ADS steht aber nicht für "Active Directory Services" sondern wird nun von Google (ADS = Advertising/Werbung) gehostet, womit viele Anfragen dieser Clients nun bei Google landen und ein passender Webserver könnte dies abfangen.
  • Defekte Software
    Microsoft hat mit Autodiscover klar vorgegeben, dass ein Service die Domain der Mailadresse als Basis heranholen sollte und nach der Domain oder nach autodiscover.<domain> sucht. Es soll Produkte geben, die aber den DNS-Baum nach oben weiter gehen. So könnte diese Software statt nach "autodiscover.mxfaq.de" und "msxfaq.de" vielleicht auch nach "autodiscover.de" und ".de" suchen. Genau das haben wohl ein paar "Sicherheitsexperten" getan und nachgewiesen, dass es solche Produkte gibt.

Wenn eine Software gültige Anmeldedaten erfragt und an einen Webservice gibt, dann sollte Sie schon genau sicherstellen, wohin die Daten gesendet werden. Dazu gehört nicht nur der DNS-Name sondern auch eine Prüfung des Zertifikats und die Blockade eines "Downgrade" der TLS-Sicherung oder Authentifizierungsprotokolle. Meines Wissens sind alle Microsoft-Produkte in der Hinsicht korrekt. Das bedeutet aber nicht, dass anderer Code genauso funktioniert.

Risiko eigene Webseite

Ein Risiko für Autodiscover ist allerdings ihre eigene Webseite. Wenn der AutoDiscover-Client nicht schon per SCP eine Adresse eines internen Servers bekommt, dann fragt er zuerst den Host "https://<maildomain>" ab. Bei den meisten Firmen verweist dieser Name auf die offizielle Webseite, die ansonsten auch unter "https://www.<maildomain>" erreichbar ist.

Leider passiert es relativ häufig, dass diese öffentlichen Seiten ein CMS wie Wordpress nutzen, in denen es auch immer wieder kritische Lücken gibt und damit übernommen werden können. Die meisten Angreifer nutzen solch eine Seite dann zur Ablage von verbotenen Dateien, Formulare zum Abfischen von Zugangsdaten oder als Sprung/Redirect-Service zu eine Malwareseite. Für einen Angreifer ist eine so gekaperte URL hilfreich, da Sie in Phishing-Mails seltener als Spam klassifiziert wird.

Mit dem Wissen um Autodiscover würde ich als Angreifer aber möglichst unerkannt bleiben wollen und einfach einen Autodiscover-Service implantieren, der die Zugangsdaten ausleitet. Sobald ein Angreifer dann solche Daten hat, kann er direkt auf das Postfach zugreifen und quasi "von innen" die Struktur der Firma über das globale Adressbuch ermitteln und individualisierte Mails mit weiterer Malware intern zustellen. Wenn die Firma andere externe Zugänge nicht per 2FA/MFA abgesichert hat, könnte der Angreifer nun per VPN oder RDP seine neuen Zugänge weiter nutzen.

Risiko Anwender

Ein weiteres Risiko ist natürlich der Anwender selbst. Wenn der Administrator das Feld "Mail" im Active Directory mit einer falschen Domäne pflegt oder der Benutzer bei der Einrichtung des Outlook-Profils sich vertippt, dann startet der Client natürlich eine Anfragen gegen diese Domäne, die nicht ihrer Firma gehört. Auch dort könnte ein Angreifer dann warten, eine Anmeldung erzwingen und Zugangsdaten abfischen.

Ich vergleiche das gerne mal mit einem Geldautomat im Urlaubsland, in den Sie ihre EC/Kreditkarte einschieben und die PIN eingeben. Sie sollten schon prüfen, ob der Automat "vertrauenswürdig" aussieht.

Wie leicht fallen ihre Mitarbeiter auf Mail herein die z.B. einen Link auf "https://intranet-example.com" statt "https://intranet.example.com" lautet und geben beim Kennwortdialog ihre Anmeldedaten sein? Hier hilft nur Sensibilisierung der Mitarbeiter. In einem gut gepflegten System muss der Mitarbeiter sich nur einmal aktiv authentifizieren: Die Anmeldung am Computer. Alles andere sollte per Single Sign On erfolgen. Der Mitarbeiter hat es dann einfacher und jede weitere Kennwortabfrage wäre ein Alarmzeichen.

Weitere Links