Active Directory und Exchange Server über EWS API angreifbar

Derzeit gibt es eine Sicherheitslücke in allen Exchange Server Versionen, welche es ermöglicht via EWS an Domain Administrator Berechtigungen zu kommen oder beispielsweise E-Mails umzuleiten. Besonders kritisch macht diese Lücke, dass sie sich Remote ausnutzen lässt. Der Angreifer muss lediglich Zugriff auf ein Postfach des Exchange Servers haben.

Da die EWS API und oft auch das EAC aus dem Internet erreichbar ist, sollte in diesem Fall also schnell reagiert werden.

Es gibt sogar ein HowTo inkl. der nötigen Scripts die den Angriff erläutert:

Die Lücke ist bereits vom Dezember 2018, allerdings gibt es derzeit noch keinen Fix. Ein entsprechendes Update wird voraussichtlich erst im Februar erwartet, zumindest wenn “The Register” richtig liegt:

Hier geht es zum entsprechen Microsoft CVE Eintrag:

Damit die Lücke nicht mehr ausgenutzt werden kann, hilft es den folgenden Registry Key zu löschen:

Active Directory und Exchange Server über EWS API angreifbar

Der Schlüssel “DisableLoopbackCheck” kann mit diesem Befehl gelöscht werden:

reg delete HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa /v DisableLoopbackCheck /f

Ein Neustart des Servers, oder ein Neustart der Dienste ist nicht nötig.

Alternativ kann der Schlüssel auf per GPO gelöscht werden, in einer größeren Umgebung ist dies meist einfacher und schneller:

Active Directory und Exchange Server über EWS API angreifbar

Da die Sicherheitslücke derzeit durch die Medien geht, sollte der oben angegebene Registry Schlüssel möglichst zeitnah gelöscht werden und das zukünftige Update möglichst schnell installiert werden.

Sobald es ein Update zu dieser Sicherheitslücke gibt, werde ich diesen Beitrag aktualisieren.

Update: Das Entfernen des Registry Werts scheint Auswirkungen auf Drittanbieter Tools zu haben. Zumindest G-Data Mailsecurity for Exchange scheint hier Probleme zu haben. Es ist aber nicht auszuschließen, dass weitere Produkte betroffen sind.

Update 12.02.19: Die Februar Updates beheben die Schwachstelle und sollten daher zeitnah installiert werden:

Exchange Server: Neue Updates (Februar 2019)

40 Gedanken zu „Active Directory und Exchange Server über EWS API angreifbar“

  1. Wir haben nach Exchange 2016 CU15 Installation probleme mit Autodiscover von extern festgestellt. Es hat schlicht und einfach nicht mehr funktioniert. Auch die lokalen EWS Tests auf dem Exchange scghlugen fehl.
    Grund war das Fehlen des Registry Keys DisableLoopbackCheck. In dem Moment wo ich ihn wieder erstellt habe mit dem Wert 1 funktionierte Autodiscover wieder.
    Ist ja klasse, wenn MS empfiehlt, den zu löschen und dann eine grundlegende Exchangekomponente wie das Autodiscover nicht mehr funktioniert.

    Antworten
  2. Vielen Dank für den Hinweis! Nach 4h Recherche bin ich auf deinen Blog gestoßen, der mich auf die Lösung gebracht hat.

    Bei mir hat das Update (bzw. löschen des DisableLoopBackCheck) dazu geführt, dass man sich vom Exchange Server selbst nicht mehr per EWS verbinden konnte. Von anderen Servern / Rechnern geht es aber. Damit lief unser Lancom Wireless ePaper Server nicht mehr, bzw. er konnte die Räume nicht aktualisieren. Habe den Eintrag nun manuell wieder gesetzt, werde den ePaper Server bei Gelegenheit umziehen.

    Vielen Dank

    Antworten
  3. Nach Installation des CU 22 im Exchange 2013 lief ein externer Service zur Foldersynchronisation nicht mehr (ExMixedFolders).

    Grund hierfür war, dass das Update-Paket CU 22 den von Dir genannten Eintrag „DisableLoopbackCheck“ gelöscht hat. Da musste man erst einmal drauf kommen! Dank Dir ist mir das gelungen.

    You made my day!

    Antworten
  4. Nach Installation des CU 22 im Exchange 2013 lief ein externer Service zur Foldersynchronisation nicht mehr (ExMixedFolders). Grund hierfür war, dass das Update-Paket CU 22 den von Dir genannten Eintrag „DisableLoopbackCheck“ gelöscht hat. Da musste man erst einmal drauf kommen! Dank Dir ist mir das gelungen.

    You made my day!

    Antworten
  5. Nachdem wir den den Reg key gelöscht haben funktioniert auch das cmd-let test-outlookconnectivity nicht mehr so wie es soll.

    Auszug Start:
    Host: XXX( 1x.1x.1x.1x)
    Service: Test_OutlookConnectivity
    State: CRITICAL
    Date/Time: 2019-02-04 16:29:53 +0100

    Output: Das Cmdlet findet nicht alle Serverinformationen durch Pingen der Dienstanbieter oder anderer Topologieerkennung innerhalb der Dom„ne. Das Cmdlet kann nicht fortgesetzt werden. TopologyDiscoverMode = ‚UseAutodiscover,

    UseAddressbook‘.

    + CategoryInfo : OperationStopped: (Microsoft.Excha…onnectivity

    Task:TestOutlookConnectivityTask) [Test-OutlookConnectivity], TopologyDiscoverException

    + FullyQualifiedErrorId : 1E12242E,Microsoft.Exchange.Monitoring.TestOutlookConnectivityTask

    + PSComputerName : xxx.contoso.com

    Das Cmdlet findet nicht alle Serverinformationen durch Pingen der Dienstanbieter oder anderer Topologieerkennung innerhalb der Dom„ne. Das Cmdlet kann nicht fortgesetzt werden. TopologyDiscoverMode = ‚UseAutodiscover,

    UseAddressbook‘.

    + CategoryInfo : OperationStopped: (Microsoft.Excha…onnectivity

    Task:TestOutlookConnectivityTask) [Test-OutlookConnectivity], TopologyDiscoverException

    + FullyQualifiedEr

    Auszug Ende!

    Nachdem der Reg-Key wieder drin ist, läufts.

    Machen die cmdlets Test-Outlookwebservices und Test-Outlookconnectivity loopback checks? Oder warum schlagen die fehl?

    Antworten
  6. Hallo allerseits

    ich schaue immer nach ob die Sicherheitslücke schon geschlossen wurde, weil durch diese Maßnahme die einzelnen Mailkonten mit Acronis nicht mehr gesichert werden können.

    Gruß Ingo

    Antworten
    • Der hilft nur dagegen, dass man per EWS/OWA eine Impersonation auf einen anderen User machen kann (solange man sich auf den selben Server verbindet) Für den Angriff per AD/LDAP war der schon die ganze Zeit wirkungslos (siehe meinen Post vom 29.1.)

      Grüße
      Daniel

      Antworten
  7. Grad gesehen: https://www.borncity.com/blog/2019/02/07/sicherheitsempfehlung-adv190007-fr-exchange-server/

    „Neu ist, dass Microsoft Administratoren, die von einem hohen Risiko eines solchen Angriffs auf ihre Exchange-Server ausgehen, im Sicherheitshinweis einen anderen Workaround vorschlägt. Diese sollen die Throttling Policy EWSMaxSubscriptions mit einem Wert 0 über den folgenden PowerShell-Befehl definieren.

    New-ThrottlingPolicy -Name AllUsersEWSSubscriptionBlockPolicy -EwsMaxSubscriptions 0 -ThrottlingPolicyScope Organization

    Antworten
  8. Also diverse Scripte die EWS benutzen (Raumbelegung etc) laufen nicht mehr.
    Wenn ich NTLM Authentifizierung ausschalte, wird ja Basic Auth erwartet.
    Ergo gehen beim Login die Accountdaten in Text (unverschlüsselt) über die Leitung.
    Oder habe ich da was falsch verstanden?
    Nur wenn das so ist, was ist schlimmer? Die Lücke oder dass Accountdaten unverschlüsselt über die Leitung geht.
    Ich kann aber ja was falsch verstanden haben.
    Gruß Ralf

    Antworten
    • Ja hast du.
      Es geht nicht um die Authentifizierung eines Clients am Exchange-Server, sondern um einen Callback, bei dem der Exchange Server sich als Client an einem fremden Webserver authentifiziert, was er so nicht machen sollte.
      Außerdem ist Basic-Authentifizierung auf einer TLS-Verschlüsselten Verbindung erstmal kein akutes Problem.

      Grüße
      Daniel

      Antworten
  9. Hallo,
    nach dem löschen des Eintrags „DisableLoopbackCheck“ zeigten sich bei uns folgende Dinge:

    Durchführen des Befehls „“Test-OutlookWebServices -Identity vorname.nachname@domain.de -MailboxCredential Get-Credential domain\ab123)“ resultiert in:
    Source ServiceEndpoint Scenario Result
    MAIL.DOMAIN.DE autodiscover.domain.de AutoErmittlung: Failure

    und die Software „Signature Manager Exchange“ kann die Elemente in den „Gesendeten Elemente“ nicht mehr aktualisieren. Fehler 401.

    Freundliche Grüße
    Jens

    Antworten
    • „und die Software „Signature Manager Exchange“ kann die Elemente in den „Gesendeten Elemente“ nicht mehr aktualisieren. Fehler 401.“

      Kann ich nicht bestätigen. Das funktioniert hier weiterhin problemlos.

      Antworten
    • Test-OutlookWebServices funktioniert bei uns weiterhin so wie es soll, nachdem wir von jedem exchange 2016 CU11 Server im Cluster den Registry Key entfernt haben.

      Antworten
    • Das Problem bei „Test-OutlookWebServices“ kann ich bestätigen, wenn der REG-Key vorhanden ist, sind die Tests erfolgreich, wenn der REG-Key gelöscht wurde schlagen, die Tests fehl. Outlook/OWA scheint aber normal zu funktionieren

      Grüße

      Antworten
      • Ok jetzt liefert Test-OutlookWebServices bei uns auch einen Fehler. Da war ich mit dem Test wohl zu schnell. Scheinbar greift der Workaround erst nach ein paar Minuten

        Antworten
  10. Hat jemand mal ausprobiert, ob nach Entfernen des DisableLoopbackCheck Registry Wertes der PoC Code (per LDAP) wirklich nicht mehr funktioniert?
    Wir haben hier gegenteilige Erfahrungen gemacht und mussten dann sehr zum Leidwesen unserer Mac-User (keine neuen Mails werden angezeigt) die EWS Subscriptions per Throttling Policy einschränken.

    Grüße
    Daniel

    Antworten
  11. Laut Quellcode des Exploids wird die URL >ews_url = „/EWS/Exchange.asmx“< angesprochen.

    Wieso diese URL nicht einfach auf der Firewall für extern sperren?
    Was spricht dagegen, was für Nebenwirkungen hat dies?

    Antworten
  12. Nach dem Entfernen des Keys laufen div. Programme und Tools von Code Two (Exchange-Rules, Out of Office Manager), nicht mehr sauber bzw. überhaupt nicht mehr. Nach dem Wiederherstellen des Wertes laufen die Programme wieder. Eine Änderung des Wertes von 1 auf 0 hat die selbe Auswirkung.

    Antworten
  13. Die Frage ist wirklich, was geht danach nicht mehr. Im SharePoint Server Umfeld setzt man den Eintrag, damit der Suchserver funktioniert, wenn man nicht den Servernamen selbst als Websitenamen verwendet.

    Antworten
    • Läuft der Exchange Monitor auf dem Exchange Server? Funktioniert der Exchange Monitor noch, wenn er auf einem anderen Computer ausgeführt wird?

      Antworten
      • Nein der ExchangeMonitor wie auch der ExchangeReproter funktionieren nach entfernen des Eintrags nicht mehr…
        Fraglich ob dies auch so ist nach einspielen des CU22 beim EX2013

        Antworten
  14. „DisableLoopbackCheck“ wurde doch vorher manuell gesetzt?!? Hab das mal vor gefühl x-tausend Jahren in einer Testumgebung eines SBS2003 gesetzt, um per Hostnamen des Servers auf sich selbst zugreifen zu können (betraf Softwareverteilung per AD, kann aber auch Sharepoint betreffen). Sollte in einer halbwegs aktuellen Produktivumgebung eigentlich nie jemand benötigt haben, oder?

    Antworten

Schreibe einen Kommentar