[English]In Exchange existiert von Version 2010 bis 2019 eine Sicherheitslücke, die irgendwann durch ein Update behoben werden soll. Man kann die Schwachstelle aber per Registrierungseintrag deaktivieren – was aber Konsequenzen hat. Nachtrag Januar 2019: Jetzt ist ein 0-day Exploit veröffentlicht worden – einen Fix gibt es noch nicht.
Anzeige
Exchange-Schwachstelle CVE-2018-8581
Bei CVE-2018-8581 handelt es sich um eine Elevation of Privilege-Schwachstelle in Microsoft Exchange Server. Dazu muss der Angreifer ein Postfach auf dem Exchange-Server besitzen. Dann kann er sich Administrator-Rechte verschaffen. Insgesamt bestehen folgende Schwachstellen, die diesen Angriff ermöglichen:
- Exchange Server haben bei Benutzerkonten standardmäßig zu hohe Privilegien
- Die NTLM-Authentifizierung ist anfällig für Relay-Angriffe
- Exchange besitzt eine Funktion, die es einem Angreifer ermöglicht, sich mit dem Computerkonto des Exchange-Servers zu authentifizieren.
Ein Angreifer, der diese Schwachstelle(n) erfolgreich ausgenutzt hat, könnte versuchen, sich als ein anderer Benutzer des Exchange-Servers auszugeben. Um die Schwachstelle auszunutzen, müsste ein Angreifer einen Man-in-the-Middle-Angriff ausführen, um eine Authentifizierungsanforderung an einen Microsoft Exchange Server weiterzuleiten. Dann könnte er sich als ein anderer Exchange-Benutzers ausgeben und dann eine Hochstufung zum Administrator versuchen. Die Schwachstelle betrifft die Exchange-Versionen 2010 bis zur aktuellen Version 2019. Microsoft will irgendwann später diese Schwachstelle mit einem Update fixen.
Workaround zum Beheben von CVE-2018-8581
Als Workaround zum Beheben dieser Schwachstelle schlägt Microsoft vor, die Loopback-Prüfung abzuschalten. Dafür muss der Registrierungschlüssel:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
Anzeige
im Registrierungseditor geöffnet und der Wert DisableLoopbackCheck, der eine Loopback-Prüfung zulässt, gelöscht werden. Microsoft gibt hier die Details an und schlägt dazu den folgenden Befehl vor.
reg delete HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa /v DisableLoopbackCheck /f
Bei administrator.de weist man hier darauf hin, dass dieser Loopback-Check in SharePoint gebraucht wird (siehe diesen Technet-Beitrag).
Nachtrag vom 26.1.2019: 0-day Exploit veröffentlicht
Wir haben nun Ende Januar 2019, und Microsoft hat noch immer keinen Fix für diese Probleme bereitgestellt. Am 21. Januar 2019 hat Dirk-jan Mollema den Beitrag Abusing Exchange: One API call away from Domain Admin veröffentlicht. Dort stellt er einen 0-day Exploit zum Ausnutzen der Schwachstellen vor. Mollema schreibt:
In den meisten Unternehmen, die Active Directory und Exchange verwenden, haben Exchange-Server so hohe Berechtigungen, dass es ausreicht, Administrator auf einem Exchange-Server zu sein. Dann kann man sich zum Domain Admin machen.
Mollema stieß vor kurzem auf einen ZDI-Blog-Beitrag, in dem eine Möglichkeit beschrieben wird, wie sich Exchange-Angreifer, die NTLM über HTTP verwenden, über eine zusätzliche Schwachstelle authentifizieren können. Dies kann mit einem NTLM-Relay-Angriff kombiniert werden, um jedem Benutzer mit einem Exchange-Postfach zu ermöglichen sich zum Domain Admininstrator hochzustufen.
Dann beschreibt Mollema im Blog-Beitrag einen Angriff, einige der technischen Details sowie Abhilfemaßnahmen (in Form des obigen Registry-Eingriffs). Gleichzeitig hat er ein Proof-of-Concept-Tool für diesen Angriff, das er "PrivExchange" genannt hat, veröffentlicht. Da es von Microsoft nach wie vor keinen Patch gibt, lassen sich nur die oben beschriebenen Maßnahmen durch Eingriff in den Registrierung zur Deaktivierung des DisableLoopbackCheck zur Absicherung des Exchange-Systems verwenden.
Seit das Proof of Concept veröffentlicht wurde, geht diese Geschichte durchs Internet. Woody Leonhard weist hier auf den Sachverhalt hin und über diesen heise.de-Kommentar zu einem meiner Artikel, bin ich auf den aktuellen Blog-Beitrag von Frankys Web gestoßen (der deutschsprachige Blog von Frank Zöchling ist übrigens hier rechts in der Seitenleiste in der Blog-Roll verlinkt). Frank beschreibt die Schwachstelle und den Registrierungseingriff ebenfalls.
Anzeige
AUTSCH!
1. Nein, dieser Registry-Schlüssel (bzw. seine Existenz) ermöglicht keine Loopback-Prüfung!
2. Nach Löschen des genannten Registry-Schlüssels ist nicht nur die Sicherheitslücke weg.
Du hättest Deine Qualitätskontrolle ebensowenig wie Microsoft abschaffen dürfen!
Korrekt ist: ein in/unter diesem Schlüssel ggf. vorhandener Eintrag namens DisableLoopbackCheck ist entweder zu Löschen oder auf den DWORD-Wert 0 zu setzen.
Und für die Trottel bei Microsoft: Registry-Einträge sind KEINE -Schlüssel!
Das würde ich aber auch so sehen, immerhin sagt dies auch der veröffentlichte reg-Befehl:
reg delete…DisableLoopbackCheck
Da der Wert unter HKLMachine eingetragen ist, sollte ein Serverneustart nötig werden um hier Abhilfe zu schaffen?
https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2018-8581
"Neither a restart of the operating system nor the Exchange Server is required after the removal of this registry key."
ACHTUNG!
Da existiert nicht nur ein Problem mit SharePoint, sondern auch mit dem "G DATA MailSecurity for Exchange" sobald der Registry Wert geändert wurde bekommt der Service keine Verbindung mehr zum Managementserver.
Die Mails werden dann zwar noch getaggt, aber nicht mehr aktiv verschoben.
Bei einer erneuten Installation wirft das Setup den Fehler raus, dass
"Microsoft Exchange Web Services Managed API 2.0 (EWS)" nicht verfügbar wären.
Guten Morgen,
Ich habe das gleiche Problem.
Haben Sie eine Lösung gefunden?
MfG
Schau dir mal den Beitrag http://heck.online/wordpress01/?knb-category=server16 an. Dort steht, dass man den Wert nicht löschen sondern auf 0 setzen soll. Kann aber nicht beurteilen, ob das irgendwie hilft.
Hallo
Der beschriebene Registry Key ist da um einen Angriffs Vektor zu -öffnen-… Wenn er gesetzt ist ermöglicht er Refelection attacke gegen den Server.
Wenn ein Admin Ihn aktiviert sollte er wissen was da los ist und was er macht.
Microsoft hat schon 2010 gesagt das dies nicht der richtige Weg ist…
Hallo,
durch diese Mitigation können lokale EWS Verbindungen auf die eingetragene internalURL blockiert werden; mit Eintrag eines Werts BackConnectionHostNames unter msv1_0 lässt sich dann aber eine Ausnahme setzen.
Hoffen wir, dass der Patch bald folgt
VG
JS
Hallo,
ist das Problem eigentlich jetzt behoben worden?
Gibt es einen Patch?
Gruß
Markus
Mir ist nichts bekannt – es gibt nur den oben beschriebenen Workaround.
Ist nicht das die Lösung?
https://support.microsoft.com/en-us/help/4490060/exchange-web-services-push-notifications-can-provide-unauthorized-acce