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:
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:
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:
https://www.frankysweb.de/exchange-server-neue-updates-februar-2019/
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.
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
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!
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!
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?
Keine Ahnung, aber zu diesem Thema gibt es seit Deinstag einen Patch von Microsoft!
https://www.frankysweb.de/exchange-server-neue-updates-februar-2019/
So, jetzt isser da der Patch:
https://support.microsoft.com/en-us/help/4490060/exchange-web-services-push-notifications-can-provide-unauthorized-acce
Installation auf der Testumgebung läuft…
DisableLoopbackCheck habe ich angepasst, von Throttling Policy habe ich gestern Abend erst gelesen.
So ist es bei mir auch, DisableLoopbackCheck=>Ja, Throttling Policy=>Nein.
Die Acronis-Sicherung funktioniert hier allerdings trotzdem…
Ich versuche sicherheitshalber gerade einmal nachzusehen ob sich bei mir ein Account zum Admin hochgestuft hat.
Hierzu habe ich folgenden Link gefunden. https://www.faq-o-matic.net/2017/04/18/versteckte-accounts-im-active-directory-aufspren/
Mit Acronis mache ich eine Datenbanksicherung und zusätzlich noch eine Sicherung der einzelnen Postfächer, letzeres klappt seit der Umstellung von DisableLoopbackCheck nicht mehr.
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
Hast Du „nur“ DisableLoopbackCheck oder auch die Throttling Policy angepasst?
Und was ist dann mit “DisableLoopbackCheck”?
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
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
„
Hi zusammen,
im Sicherheitshinweis von Microsoft ist der KB4468741 verlinkt – https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2018-8604.
Ist das Update zuverlässig einsetzbar bzw. hat einer von Euch das Update bereits in einer Umgebung installiert?
VG
André
Das Update vom Dezember wird vom Januar Update ersetzt:
https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2019-0586
Und ja, das läuft bei mir problemlos.
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
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
weiss jemand ob es auf Skype For Business Einfluss nimmt? Das verwendet ja auch sehr viel von EWS
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
„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.
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.
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
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
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
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?
Naja wenn du EWS nicht brauchst (bspw. für Outlook for Mac oder Free/Busy Informationen)…
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.
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.
Kann es sein as im Anschluss dein ExchangeMonitor nicht mehr funktioniert und bei send Testmail abbricht mit einer Fehlermeldung?
Läuft der Exchange Monitor auf dem Exchange Server? Funktioniert der Exchange Monitor noch, wenn er auf einem anderen Computer ausgeführt wird?
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
Danke für den Hinweis. Welche Nebenwirkungen hatten das Löschen des Reglers, gibt es Beeinträchtigungen?
Konnte bisher keine Nebenwirkungen feststellen. Bin auf morgen gespannt, wenn alle da sind.
In unserer Umgebung gab es heute keine Störungsmeldung in dieser Hinsicht.
Es gibt Nebenwirkungen bei Software die EWS nutzt.
Aktuell Probleme bei SER Doxsis und MailStore.
„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?
Hallo Martin,
„DisableLoopbackCheck“ wird vom Exchange Setup erstellt und ist somit auf jedem Exchange Server vorhanden.
Gruß,
Frank
Ist mir tatsächlich nicht aufgefallen. Hab nochmal kurz geschaut, bei borncity.com gab es einen Hinweis darauf im November und in diesem Kommentar dazu werden möglich Auswirkungen genannt: https://www.borncity.com/blog/2018/11/19/sicherheitslcke-in-exchange-server-2010-2019/#comment-65478