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)

35 Kommentare zu “Active Directory und Exchange Server über EWS API angreifbar”

  1. 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?

    1. So ist es bei mir auch, DisableLoopbackCheck=>Ja, Throttling Policy=>Nein.
      Die Acronis-Sicherung funktioniert hier allerdings trotzdem…

  2. 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

    1. 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

  3. 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

  4. 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

    1. 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

  5. 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

    1. „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.

    2. 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.

    3. 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

      1. 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

  6. 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

  7. 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?

  8. 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.

  9. 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.

  10. Kann es sein as im Anschluss dein ExchangeMonitor nicht mehr funktioniert und bei send Testmail abbricht mit einer Fehlermeldung?

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

      1. 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

  11. „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?

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.