Exchange Fail Jan 2019 - CVE-2018-8581

Am 13. November hat Microsoft im Bulletin "CVE-2018-8581 | Microsoft Exchange Server Elevation of Privilege Vulnerability" (https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2018-8581) eine Schwäche veröffentlicht. Leider kommen hier aber drei Probleme zusammen. Achten Sie also bei den Hinweisen und andren Blogs immer darauf, für welches Problem eine Lösung beschrieben wird. Anfang 2019 gab es gleich mehrere Incidents, bei denen man schon mal durcheinander kommen kann. Zumal nicht jedes Problem jede Version betrifft.

Exploit

Beschreibung

Status

CVE-2019-0586

8 Jan 19

CVE-2019-0586 | Microsoft Exchange Memory Corruption Vulnerability
Exchange führt eine entsprechende Mail aus. Hierfür gibt es ein Security Update.

Empfehlung: Update auf jeden Fall installieren.

  • Fix verfügbar

CVE-2019-0588

Über die PowerShell API kann ein Benutzer mehr Rechte nutzen, als vorgesehen

  • Fix verfügbar

CVCVE-2018-8581

NTLM Vulnerability durch den "DisableLoopbackCheck"-Eintrag, den Exchange beim Setup setzt. Die Updates wurden schon im Oktober 2018 für Exchange 2010 und 2016 released. Für Exchange 2013/2019 gab es kein Update. da müssen Sie von Hand den Eintrag entfernen.

Achtung: Diverse 3rd Party Programme, die auf dem Server selbst über Loopback zugreifen, laufen eventuell nicht mehr, z.B. Disclaimer Tools, CodeTwo Exchange Rules, eventuell Faxserver per EWS, 3rd Party UC-Lösungen und anscheinend auch einige Exchange Test-*-Commandlets. . Prüfen Sie nach der Einstellung die Funktion aller Komponenten.
Den Key gibt es auch bei SharePoint und ist da wohl noch erforderlich. Die Entfernung auf Exchange betrifft aber keine Dienste, die über LAN zugreifen.

Es betrifft aber nur Dienste die per Loopback auf Exchange zugreifen. Sie müssen also auf dem Exchange Server selbst zugreifen, um diese Lücke zu nutzen.

Microsoft hat im Oktober 2018 CU für Exchange 2010 und 2016 das Problem schon derart gelöst, dass der Eintrag entfernt wird und das Setup diese nicht mehr addiert. Für Exchange 2013 und 2019 gab es im Oktober 2018 noch kein Update. Hier sollten Sie den Fix manuell durchführen

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

Empfehlung: Registry-Key umgehend entfernen oder auf 0 setzen!

  • Ex2010 Fixed
  • Ex2013 manuell
  • Ex2016 fixed
  • Ex2019 manuell

CVE-2018-8581

CVE-2018-8581 | Microsoft Exchange Server Elevation Privilege Vulnerability

Um den 19. Dezember gab es die ersten Hinweise zur Ausnutzung der Sicherheitslücke in Exchange, die angeblich allein durch eine HTTP-Subscription per EWS zu nutzen war.

Es ist möglich, die EWS-Subscriptions pro Benutzer komplett abzuschalten. Allerdings funktioniert dann der Skype for Business Client ebenso wenig wie Outlook/Mac und andere EWS-basierte Dienste mit ChangeNotifications

Eine andere Lösung ist die Nutzung des "Split Permission modell", welche verhindert, dass die Domain Admin Gruppe durch Exchange verändert werden kann

Dann hat Exchange nicht mehr Berechtigungen aber für einige Aufgaben (z.B. Mailbox anlegen) muss man dann andere Wege nutzen. Möglich aber wenig praktikabel.

  • Fix seit 12. Feb verfügbar

Diese Seite konzentriert sich auf den letzten noch offenen Punkt.

Finaler Stand (12. Feb. 2019)

Am 12 Februar hat Microsoft für Exchange 2010,2013,2016 und 2019 ein entsprechendes Updates heraus gebracht, welches die Berechtigungen im Active Directory reduziert und die EWS-Funktion umstellt.

  • AD-Rechte
    Über die Schalter "setup.exe /PrepareAD" und "setup.exe /PrepareAllDomains" werden die Rechte im AD aktualisiert. Wenn Sie nur Exchange 2010-Server haben, dann müssen Sie dem KB-Artikel folgen. Alle anderen Installationen mit Exchange 2013 oder neuer und gemischte Umgebungen müssen diese Befehle mit dem Setup der höchsten Version machen. Wer also Exchange 2016 und 2010 parallel betreibt, muss das CU von Exchange 2016 nutzen. folgende Zwei Dinge werden geändert:
    • Entfernt "Exchange Trusted Subsystem" vom AdminADHolder Objekt
    • Ändert den WriteDACL Access Control Eintrag auf "User" und "InetOrg" Class auf "inherit only"für die "Exchange Windows Permission"-Sicherheitsgruppe
  • EWS-Funktion
    Das Update bezüglich EWS ändert das Exchange Verhalten. Wenn Exchange per HTTP-Push einen bereitgestellten Webservice anspricht, dann sendet Exchange keine Authentication-Informationen mehr mit. Das bedeutet aber für 3rd Party Lösungen, die mit EWS-Push arbeiten, keine Authentifizierung mehr anfordern dürften und die Anfragen anonym annehmen müssen.
    Hierfür die die Installation des entsprechenden Update erforderlich.

Leider müssen Sie je nach Exchange Version einige Besonderheiten beachten.

Version Download

Exchange 2019

Der Download ist eine >5GB Vollinstallation, die aber nicht öffentliche Verfügbar ist. Exchange 2019 Server gibt es nicht mehr als Kaufversion, sondern wird als Volume License Subscription vertrieben und ist daher im VLSC-Portal zu erhalten. Developer können das ISO-File auch im MSDN finden.

Die Installation ist dann aber eine Vollinstallation und führt auch PrepareAD und PrepareAllDomains aus, wenn der Benutzer ausreichende Rechte hat.

Exchange 2016

Exchange 2016 gibt es ganz offen als ISO-Datei zum Download. Es ist eine Vollversion, d.h. mit der Quelle können neue Server installiert und bestehende Server aktualisiert werden.

Cumulative Update 12 for Exchange Server 2016
https://www.microsoft.com/de-DE/download/details.aspx?id=57827
https://support.microsoft.com/en-us/help/4471392/cumulative-update-12-for-exchange-server-2016

Exchange 2013

Exchange 2013 gibt es ganz offen als ISO-Datei zum Download. Es ist eine Vollversion, d.h. mit der Quelle können neue Server installiert und bestehende Server aktualisiert werden.

Cumulative Update 22 for Exchange Server 2013
https://www.microsoft.com/de-DE/download/details.aspx?id=57826
https://support.microsoft.com/en-us/help/4345836/cumulative-update-22-for-exchange-server-2013

Exchange 2010

Für Exchange 2010 gibt es ein deutlich kleineres "SP3 Rollup 26", welche nur die EWS-Lücke fixt. Wenn Sie kein neuere Exchange Version parallel installiert haben, die ACLs anpasst, dann befolgen Sie bitte genau die Schritte in dem KB-Artikel.

Update Rollup 26 For Exchange 2010 SP3 (KB4487052)
https://www.microsoft.com/de-DE/download/details.aspx?id=57824

Beachten Sie, dass auf Exchange 2016/2019 die VC++ 2012 Runtime erforderlich ist und das Setup bei der Installation dies nicht selbst nachzieht. Wenn die Runtime noch nicht installiert ist, dann sollten Sie diese vorher installieren

Visual C++ Redistributable for Visual Studio 2012 Update 4
https://www.microsoft.com/download/details.aspx?id=30679

Es es nun doch einige Updates sind, habe ich alle Updates dieser vier Versionen mal in einer Tabelle gebracht. Microsoft hat es nämlich geschafft, z.B. im 2016CU12 und 2019CU1 mit leicht unterschiedlichen Artikelbeschreibungen zu arbeiten.

Update 2010 2013 2016 2019

4456241 You receive a meeting request that has a "not supported calendar message.ics" attachment in Exchange Server 2016

 

 

CU12

CU1

4456239 New-MailboxRepairRequest doesn't honor RBAC RecipientWriteScope restrictions in Exchange Server 2016

 

 

CU12

CU1

4468363 MRM does not work for mailboxes that have an online archive mailbox in Exchange Server

 

 

CU12

 

4487591 The recipient scope setting doesn't work for sibling domains when including OUs in the scope in Exchange Server 2019

 

 

CU12

CU1

4487596 Emails are blocked in moderator mailbox Outbox folder when you send large volumes of emails in Exchange Server 2019

 

 

CU12

CU1

4487602 Outlook for Mac users can still expand a distribution group when hideDLMembership is set to true in Exchange Server 2019

 

 

CU12

CU1

4487603 "The action cannot be completed" error when you select many recipients in the Address Book of Outlook in Exchange Server 2013

 

CU22

CU12

 

4488076 Outlook on the Web can't be loaded when users use an invalid Windows language in operating system in Exchange Server 2019

 

 

CU12

CU1

4488077 Can't configure voice mail options when user is in different domain in Exchange Server 2016

 

 

CU12

 

4488079 Exchange Server 2016 allows adding Exchange Server 2019 mailbox server into a same DAG and vice versa

 

 

CU12

CU1

4488261 Event ID 1002 when the store worker process crashes in Exchange Server 2016

 

 

CU12

 

4488263 X-MS-Exchange-Organization-BCC header isn't encoded correctly in Exchange Server 2019/2016

 

 

CU12

CU1

4488080 New-MigrationBatch doesn't honor RBAC management scope in Exchange Server 2019/2016

 

 

CU12

CU1

4488258 OAuth authentication is removed when saving MAPI virtual directory settings in EAC in Exchange Server 2019

 

 

CU12

CU1

4488259 MailTip shows wrong number of users for a distribution group if the users are in different domains in Exchange Server 2019

 

 

CU12

CU1

4488260 New-MailboxExportRequest and New-MailboxImportRequest don't honor RBAC management scope in Exchange Server 2019

 

 

CU12

CU1

4488261 Event ID 1002 when the store worker process crashes in Exchange Server 2019

 

 

 

CU1

4488262 Delivery Reports exception when tracking a meeting request that's sent with a room resource in Exchange Server 2019

 

 

CU12

CU1

4488264 Mailbox that has a bad move request can't be cleaned up from destination mailbox database in Exchange Server 2019

 

 

 

CU1

4488265 "There are problems with the signature" error occurs for digital signature message if attachment filtering is enabled in Exchange Server 2019

 

 

CU12

CU1

4488266 Client application doesn't honor EwsAllowList in Exchange Server 2019

 

 

CU12

CU1

4488267 Test-OAuthConnectivity always fails when Exchange Server uses proxy to connect to Internet in Exchange Server 2019

 

 

CU12

CU1

4488268 Disable the irrelevant Query logs that're created in Exchange Server 2019

 

 

CU12

CU1

4488398 "The Microsoft Exchange Replication service may not be running on server" error when you add a mailbox database copy in Exchange Server 2019

 

 

 

CU1

4490059 Reducing permissions required to run Exchange Server using Shared Permissions Model

 

CU22

CU12

CU1

4490060 Exchange Web Services Push Notifications can be used to gain unauthorized access

RU26

CU22

CU12

CU1

Eine sehr hohe Ähnlichkeit zwischen Exchange 2016/2019 ist nicht zu übersehen.

Hinweis
Es könnte dennoch sein, dass eine Infektion schon stattgefunden habe. Kontrollieren Sie daher alle privilegierten Windows und Exchange RBAC und Berechtigungsgruppen. Auch neue Objekte mit erweiterten Rechten sollten Sie kontrollieren.

#Listet alle neuen Objekte seit 1.1.2019

Get-Adobject -Ldapfilter "(&(objectClass=User)(whenChanged>=20190101000000.0Z))"

Es wird sicher das ein oder andere Objekt geben. Sollte ein erfolgreicher Einbruch aber ein neues Konto angelegt haben, dann finden Sie es hier.

Zwischenstand (05. Feb 2019)

Meine Einschätzung so weit mir der Sachverhalt bekannt ist:

  • Exchange ruft durch einen authentifizierten Anwender hinterlegte beliebige URLs an und meldet sich dort als "LocalSystem" an. Der Hashwert ist dabei im Request enthalten
  • Ein Angreifer kann den NTLM-Handshake als Proxy zu einem Domaincontroller weiter geben und dann "als Exchange" die Rechte missbrauchen

Nach alles, was ich bislang davon verstanden habe, sind folgende Voraussetzungen dazu erforderlich:

  • Der Angreifer kann einen EWS-Zugriff mit Authentifizierung ausführen
    Nur so kann er sich z.B. auf ein Postfach oder Ordner verbinden und eine Push-URL hinterlegen
  • Der Angreifer nimmt Push-Anfragen des Exchange Servers an
    dazu nutzt der wohl die bestehende TCP Connection zum Client
  • Der Angreifer muss den Exchange Server zu einer NTLM-Authentifizierung veranlassen
  • Der Angreifer hat direkten Zugriff auf Zielservice, die mit dem NTLM-Hash verwendet werden können
    Im Beispiel ist immer von einem Domain Controller per LDAP oder AD WebServices zu Sprache, um sich in die Gruppe der Domain Administratoren zu addieren. Denkbar sind aber auch andere Dienste.
  • Der Angriff kann auch aus dem Internet erfolgen und ist nicht auf einen internen Client beschränkt
    Wobei das schon deutlich komplexer auszuführen ist.

Allerdings ist das Risiko schon realer, wenn der Angreifer intern ist und sowohl den Exchange Server als auch einen DC erreichen kann und der Exchange Server dem Client antworten kann.

Ich darf aufgrund eines NDA noch nicht alle schreiben aber Microsoft hat angeblich jede Arbeit an Features und Funktionen eingestellt, um alle Ressourcen auf dieses kritische Problem zu bündeln.
Ich beschreibe weiter unten einige Möglichkeiten

Der Angriffsvektor

Das Active Directory steuert über ACLs die Fähigkeit von Konten, Daten zu ändern. Ein Domain Admin kann relativ viel während ein Domain Benutzer in weiten Bereichen nur lesen kann. Exchange hat das System noch perfektioniert, weil selbst Exchange Administratoren nicht direkt die entsprechenden Felder bei den Active Directory Konten schreiben müssen, sondern dank RBAC - Role Based Access Control der Administrator den Exchange Server beauftragt, eine Aktion durchzuführen. Der eigentliche Schreibzugriff auf das AD-Objekt erfolgt dann über die Exchange Server Berechtigungen. Ein Blick auf die Berechtigungen von Exchange auf die Root Domäne und die Konfiguration liefert einen ersten Einblick:

  • Berechtigungen auf der Root-Domain des Forest
  • Berechtigungen auf dem Exchange Konfiguration Container
  • Berechtigungen auf AdminSDHolder
    Das Active Directory schützt seine Administratoren über einen Hintergrundprozess, der immer wieder die Rechte von "AdminSDHolder" auf die Konten anwendet. Damit Exchange aber auch diese Objekte mit Exchange Eigenschaften verwalten kann, addiert das Exchange Setup auch auf AdminADHolder eine ACL.

    Damit hat das "Exchange Trusted Subsystem" auch Rechte auf administrative Konten und Gruppen. Damit kann Exchange aber auch die Gruppe der Domänen-Administratoren verändern

Wenn es also einem Angreifer gelingt, sich z.B.: als "Exchange Trusted Subsystem" auszugeben, dann kann er mit den Zugangsdaten auch direkt per LDAP entsprechende Einträge im Active Directory vornehmen und sich z.B. in die Gruppe der Domänen-Administratoren aufnehmen.

Der Missbrauch

Damit ein Angreifer natürlich diese Rechte erlangen kann, muss er entweder auf dem Exchange Server sich einschleichen oder z.B. eine Authentifizierung von Exchange abfangen. Das ist erst einmal gar nicht so leicht, da mittlerweile die meisten Kommunikationskanäle zwischen Exchange und anderen Diensten wie z.B. einem Domain Controller verschlüsselt und signiert sind. Früher war es viel einfacher, eine Verbindung passiv mitzuschneiden und dann eine Replay-Attacke zu fahren, wozu sie natürlich schon im LAN angeschlossen sein mussten. Ansonsten laufen ARP-Spoofing etc. ins Leere. Es ist aber nicht unmöglich.

Hinzu kommt, dass eine Funktion von Exchange einen Angriff wohl vereinfacht. Genau geht es um die PUSH-Benachrichtigungen mit EWS. Ein authentifizierter Anwender kann z.B. per EWS seine Mailbox oder einen Ordner im Postfach überwachen lassen. Anstatt nun aber immer wieder die Anfrage zu wiederholen (Polling) oder per Streaming die Anfrage zu stellen und auf die Antwort zu warten, gibt es schon lange auch die Option dem Exchange Server eine CallBack-URL zu hinterlegen. Sobald sich dann an den Daten in Exchange ändert, surft Exchange quasi die hinterlegte URL an. Als guter Entwickler einer 3rd Party Lösung können Sie so einfach einen WebService veröffentlichen, der von Exchange angesprochen wird.

Diese Webseitenaufruf führt Exchange natürlich nicht "anonym" durch, sondern üblicherweise mit den "Default Credentials", die hier dann als "LOCALSYSTEM" erfolgen. Die API ist so ausgelegt, dass der Exchange Server über die bei ihm hinterlegte URLs einen "guten Webserver" erreicht, der den Request bekommt und als "Weckruf" versteht. Allerdings liegt das nicht in der Hand des Exchange Administrators. Der Trick beruht nun darauf, dass der Angreifer Exchange dazu überlistet die NTLM-Challenge einer parallel laufenden LDAP-Anmeldung eines Domain Controllers zu beantworten

Die Reihenfolge stark vereinfacht:

  1. Der Angreifer stellt einen EWS Push ein
    Der Exchange Server wird so angewiesen eine vom Angreifer hinterlegte URL aufzurufen
  2. Änderung passiert
    Der Angreifer muss nur warten oder kann sogar selbst die Änderung per EWS anstoßen, damit Exchange dann die URL erst einmal anonym aufruft
  3. Der Angreifer startet nun eine LDAP-Verbindung mit dem Domain Controller
    Dort will er ja Zugriff erhalten. Der Domain Controller fordert natürlich eine Authentifizierung an, die der Angreifer 1:1 zum Exchange Server durchreicht. Der Exchange Server bekommt also den Challenge des Domain Controllers.
  4. Exchange löst das NTLM-Puzzle und sendet die Antwort
    Der Angreifer nimmt das Ergebnis an, aber sendet es nun als seine Antwort an den Domain Controller
  5. LDAP Login erfolgreich
    Der DC glaubt, dass sich der Exchange Server bei ihm angemeldet hat. Tatsächlich ist aber der Angreifer im Besitz der Session und kann einfach weiter agieren, z.B. indem er die Recht von Exchange nutzt. Er kann z.B. Gruppen verwalten. Da wird es sicher einige Gruppen mit privilegierten Rechten geben. Er kann sic durch das Recht "Synchronize Directory" auch wie ein DC ausgehen und z.B.: die Hashwerte synchronisieren und dann offline nach passenden Kennworten suchen.

Der Exchange Server bekommt natürlich auch noch seine Antwort, damit für ihn der PUSH auch abgeschlossen ist. Für den Angriff ist das aber nicht weiter relevant und könnte auch unterbleiben. Das Problem ist auf NTLM bezogen und selbst Microsoft dokumentiert dies:

NTLM and NTLMv2 authentication is vulnerable to a variety of malicious attacks, including SMB replay, man-in-the-middle attacks, and brute force attacks. Reducing and eliminating NTLM authentication from your environment forces the Windows operating system to use more secure protocols, such as the Kerberos version 5 protocol, or different authentication mechanisms, such as smart cards.
https://docs.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/network-security-restrict-ntlm-outgoing-ntlm-traffic-to-remote-servers

Das hilft uns hier nur nicht weiter, weil der Angreifer absichtlich nur NTLM anbietet und der Server dies dann akzeptiert. Per Gruppenrichtlinie kann natürlich "NTLM ausgehend" generell oder pro Domain unterbunden werden. Die Auswirkungen einer solchen Vorgabe sind aber nicht mal schnell abzuschätzen.

Gegenmaßnahmen

Zuerst müssen wir wissen, dass die Schwäche nur mit NTLM genutzt werden kann. Wenn der Exchange Server sich per Kerberos an dem Host mit der PushURL anmelden würde, dann würde er vom KDC ein signiertes und verschlüsseltes Kerberos-Ticket bekommen, welche dann auch nur dieser Zielhost und kein Relay in der Mitte entschlüsseln kann. Ein deutliches Zeiten für Kerberos. Auf der anderen Seite sollten wir höllisch froh sein dass Exchange sich nicht auf per Basic-Authentication an der Push-URL anmelden kann. Ansonsten hätte der Angreifer sogar das Kennwort im Klartext und könnte damit noch viel mehr Schaden anrichten, z.B. auf Postfächer zuzugreifen. Wobei das durch die NTLM-Lücke eventuell sogar möglich ist. Wer sagt denn, dass der Angreifer einen Domain Controller als Ziel hat. Er könnte sich ja auch direkt wieder an einem Exchange Frontend Server anmelden.

Weg Beschreibung Einschätzung

SMB Signing

Die Schwächen von NTLM sind natürlich nicht neu. Danke dem Challenge Response-Verfahren wird zwar kein Kennwort mehr übertragen, aber die Überprüfung, dass die richtige Gegenstelle mit mir spricht bleibt dem Protokoll überlassen. Für Datei-Sharing per SMB gibt es die entsprechenden Möglichkeiten schon länger.

sollten sie sowieso machen, aber ist kein Schutz gegen den Exploit

NTLM selektiv verbieten

Der Angriff ist nur über das Authentifizierungsverfahren NTLM möglich. Im LAN wird in der Regel NTLM gar nicht mehr verwendet, da Kerberos deutlich besser, sicherer und effektiver ist. Aus dem Internet kann Kerberos aber mangels Verbindung zum KDC nicht genutzt werden. BasicAuth über SSL ist schon recht sicher aber bei NTLM erfolgt die Anmeldung durch Hashwerte, so dass das Kennwort in der Form gar nicht abgegriffen werden kann. Dennoch wird NTLM meist gar nicht angeboten, da Proxy-Server und Firewalls die Nutzung oft vereiteln. Sie könnten aber dem Exchange Server über folgende Einstellungen verbieten, NTLM zu machen.

Nicht einfach umzusetzen

LDAP Signing

Um den Angriff auf den DC zu erschweren, könnten sie hier LDAP-Signing erzwingen, d.h. jeder Client muss die LDAP-Pakete auch signieren. Für aktuelle Windows Clients sollte das kein Problem sein. Allerdings gibt es natürlich viele andere Dienste, die LDAP nutzen und dann vielleicht brechen.

Aktivieren von LDAP-Signaturen in Windows Server 2008
https://support.microsoft.com/de-de/help/935834/how-to-enable-ldap-signing-in-windows-server-2008 

Verhindert die direkte Änderung von Gruppenmitgliedschaften per LDAP aber sperrt ggfls. andere Dienste aus.

EWS Push abschalten

Die Schwäche auf einer Verbindung von Exchange zum Client aufbauen, könnten Sie einfach verbieten, dass ein Client diese API nutzt. Über EWS-Throttling können Sie die Anzahl der "EWSMaxSubscriptions" global und pro Benutzer hinterlegen.


Quelle: EWS-Einschränkung in Exchange
https://docs.microsoft.com/de-de/exchange/client-developer/exchange-web-services/ews-throttling-in-exchange

Sie können diesen Wert natürlich komplett auf "0" setzen. Allerdings kann hier nicht nach "Push" und "Streaming" unterschieden werden. Nun ist es aber so, dass z.B. der Skype for Business Client genau die Streaming-API nutzt. Insofern ist dies auch keine praktikable Lösung. Nebenbei erwischen Sie auch noch Outlook/MAC, welches EWS nutzt und Native Mail App von Apple.

Sichert temporär aber sperrt bestimmte Clients aus

AdminADHolder ACL anpassen

Wenn Sie sehen, das der Angriff die Gruppe "Domain Administratoren" als Ziel hat und dazu die Exchange Rechte auf AdminSDHolder missbrauch werden, dann könnten Sie einfach die Rechte temporär anpassen. Bitte immer gut dokumentieren. Alternativ könnten sie gleich auf das strengere Berechtigungsmodell umsteigen.

Löst einen kritischen Aspekte aber nicht alle Ziele.

Überwachung der kritischen Gruppen

Solange es noch keinen Fix gibt, können sie dennoch z. B. die Mitgliedschaften von bestimmten Gruppen überwachen. Dazu zählen alle Gruppen mit einem "Admincount=1" und natürlich die anderen privilegierten Gruppen mit Berechtigungen im AD. Insbesondere die Exchange Gruppen (Exchange Server, Exchange Trusted Subsystem, Exchange Windows Permissions, u.a.)

Solche Überwachungen sind natürlich ganz allgemein eine gute Idee.

Hilf frühzeitig einen erfolgreichen Angriff zu erkennen.

SOAP Request blockieren

Wer vor seinem Exchange Server einen Reverse-Proxy nutzt, der SSL aufbricht und nach String suchen kann, dann wäre es denkbar, die SOAP-Requests zu blockieren, in denen ein Callback erwartet wird. Hier mal ein Beispielr-Request:

PS C:\> $service.SubscribeToPushNotifications($fldArray,"http://push.msxfaq.de",2,$null,[Microsoft.Exchange.WebServices.Data.EventType]::NewMail)
<Trace Tag="EwsRequestHttpHeaders" Tid="14" Time="2019-02-05 15:26:25Z">
POST /EWS/exchange.asmx HTTP/1.1
Content-Type: text/xml; charset=utf-8
Accept: text/xml
User-Agent: ExchangeServicesClient/15.00.0913.015
Accept-Encoding: gzip,deflate


</Trace>
<Trace Tag="EwsRequest" Tid="14" Time="2019-02-05 15:26:25Z" Version="15.00.0913.015">
  <?xml version="1.0" encoding="utf-8"?>
  <soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                 xmlns:m="http://schemas.microsoft.com/exchange/services/2006/messages" 
                 xmlns:t="http://schemas.microsoft.com/exchange/services/2006/types" 
                 xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
    <soap:Header>
      <t:RequestServerVersion Version="Exchange2010_SP1" />
    </soap:Header>
    <soap:Body>
      <m:Subscribe>
        <m:PushSubscriptionRequest>
          <t:FolderIds>
            <t:DistinguishedFolderId Id="inbox">
              <t:Mailbox>
                <t:EmailAddress>user1@uclabor.de</t:EmailAddress>
              </t:Mailbox>
            </t:DistinguishedFolderId>
          </t:FolderIds>
          <t:EventTypes>
            <t:EventType>NewMailEvent</t:EventType>
          </t:EventTypes>
          <t:StatusFrequency>2</t:StatusFrequency>
          <t:URL>http://push.msxfaq.de/</t:URL>
        </m:PushSubscriptionRequest>
      </m:Subscribe>
    </soap:Body>
  </soap:Envelope>
</Trace>

Wer im HTTP_Request z.B. nach "m:PushSubscriptionRequest" sucht und den Request dann z.B. mit einem "403 Forbidden" abweist, verhindert die Ausnutzung der Lücke

Nur in Verbindung mit Reverse Proxy und SSL Offloading

Ich erwarte eine direkte Lösung in der Gestalt, dass der Exchange Server die Push-Meldung nicht mehr per Authentifizierung absichert, sondern einfach nur "anonym" anspricht und die Webapplikation sich dann eh drum kümmern muss, wie die nun die Daten verarbeitet. Allerdings müssen natürlich 3rd Party Tools dann auch anonyme Anfragen annehmen.
Die zweite Sicherung könnte eine Anpassung der Berechtigungen sein, damit Exchange z.B. die AdminGruppen nicht mehr ändern kann

Details zu EWS

In dem Zuge muss man aber auch einmal überprüfen, welche Protokolle und Methoden hier eigentlich genutzt werden. Es geht nicht um die generelle Nutzung von EWS sondern um eine besondere Funktion, mit der Dienste möglichst aktuell auf Änderungen reagieren können. Microsoft beschreibt dazu drei Wege

  • Polling
    d.h. der Client frage immer wieder "gibt es was" nach. Das ist Ressourcenintensiv und unschön aber unkritisch
  • Streaming
    Der Client fragt nach und hält die Verbindung offen. Der Exchange Server antwortet dann einfach verzögert. Diese Technik nutzt ActiveSync schon von Anfang an, da hier der Server gar keine Verbindung zum Client aufbauen kann. Meist verhindert ja NAT oder eine Firewall dies.
  • Push CallBack
    Nur hier fordert der Client einen Callback vom Server im Falle einer Benachrichtigung an

Kritisch ist hier also nur die dritte Option. Von der schreibt Microsoft aber schon lange selbst:

...However, push notifications have fallen out of favor since the advent of streaming notifications in Exchange 2010. If possible, we recommend that you use streaming notifications instead of push notifications going forward ...
Quelle: Notification subscriptions, mailbox events, and EWS in Exchange https://docs.microsoft.com/en-us/exchange/client-developer/exchange-web-services/notification-subscriptions-mailbox-events-and-ews-in-exchange

Wer es dennoch ausprobieren will, findet noch die folgenden Links:

Wenn aber die Push-Benachrichtigungen schon seit 2010 nicht mehr empfohlen werden, dann besteht ja Hoffnung, dass die gar nicht verwendet werden.

Auditing und Analyse

Es wird noch etwas dauern, bis Microsoft ein Update oder einen Patch für das Problem getestet und bereitgestellt hat. Selbst dann muss der Patch auch noch auf allen Servern installiert werden. Bis dahin könnte schon viel passiert sein. Vielleicht nutzen Sie diese Thematik aber mal dazu, sich über Änderungen an sensiblen informieren zu lassen. Interaktiv geht das z.B. mit:

# Liste der seit 1.1.2019 neu angelegtem Objekte mit einem AdminCount=1
Get-ADObject `
   -LDAPFilter "(&(admincount=1)(whenCreated>=20190101000000.0Z))" `
   -Properties whencreated,whenchanged | ft

Ich habe "whenChanged" mal auf den 1. Januar 2019 gesetzt. Der LDAP-Filter hat das Format "YYYYMMDDhhmmss.0Z."

Alternativ können Sie natürlich auch auf "whenChanged" suchen, wobei hier natürlich viele Benutzer erscheinen werden. Anmeldungen etc. ändern auch die Objekte. Daher habe ich hier noch mal auf Gruppen gefiltert

PS C:\> Get-ADObject -LDAPFilter "(&(admincount=1)(whenchanged>=20190101000000.0Z)(objectclass=group))" -Properties whencreated,whenchanged | ft

DistinguishedName                          Name           ObjectClass whenchanged         whencreated
-----------------                          ----           ----------- -----------         -----------
CN=Domänen-Admins,CN=Users,DC=msxfaq,DC=de Domänen-Admins group       17.01.2019 11:56:35 20.09.2000 21:53:51
CN=ADM-Exchange,OU=Admin,DC=msxfaq,DC=de   ADM-Exchange   group       18.01.2019 13:17:11 19.02.2010 11:19:18

Leider kann ich so aber nicht erkennen, was sich darin geändert hat. Das schaffe ich nur über ein Auditing per Eventlog oder die Überwachung der ChangeNotifications über die DirSync API.

Es gibt aber auch kommerzielle Tools, die solche Änderungen genau protokollieren und alarmieren können. Einige Produkte installieren sogar einen Filtertreiber auf dem DC, um solche Änderungen zu verhindern, selbst wenn der Benutzer eigentlich die Rechte dazu hätte.

Alle Aktionen von Exchange werden natürlich in der ein oder anderen Form protokolliert. Alle EWS-Zugriffe landen natürlich im IISLog. Leider sehen sie hier aber nur "/EWS/Exchange.asmx" als URL. Zusätzlich protokolliert Exchange aber EWS-Aufrufe noch im EWS-Logging des Clients

In diesen Dateien finden sich dann schon die Spuren.

Bitte die PowerShell-Befehle als Admin ausführen, da Sie ansonsten nicht in das Verzeichnis ".\Logging" zugreifen können.

#Einfach zu verstehen aber sehr langsam
get-item C:\Program Files\Microsoft\Exchange Server\V15\Logging\Ews\ews_2019*.log `
| %{ Import-Csv $_} `
| where {$_.Soa pAction -eq "getstreamingevents" -or $_.soapaction -eq "pull"}

Da Import-CSV durch das Zeilenweise lesen und konvertieren in ein Objekt sehr langsam ist. habe ich mir für "select-string" entschieden.

Select-String -pattern "pull","streaming" -Path "C:\Program Files\Microsoft\Exchange Server\V15\Logging\Ews\*.log" -SimpleMatch | select line

80MB EWS-Logs sind so in ca. 4 Sekunden durchsucht. Wer mag, kann die Ausgabe natürlich noch in ein Objekt konveriteren.

$ewspusher= Select-String `
   -Path "$($env:ExchangeInstallPath)\Logging\Ews\Ews_20190201*.log" `
   -Pattern "pull","streaming" `
   -SimpleMatch  `
| select line -ExpandProperty line `
| ConvertFrom-Csv `
   -Delimiter "," `
   -Header @("DateTime","RequestId","MajorVersion","MinorVersion","BuildVersion","RevisionVersion","Ring",
             "ClientRequestId","AuthenticationType","IsAuthenticated","AuthenticatedUser","Organization",
             "UserAgent","VersionInfo","ClientIpAddress","ServerHostName","FrontEndServer","SoapAction",
             "HttpStatus","RequestSize","ResponseSize","ErrorCode","ImpersonatedUser","ProxyAsUser",
             "ActAsUser","Cookie","CorrelationGuid","PrimaryOrProxyServer","TaskType","RemoteBackendCount",
             "LocalMailboxCount","RemoteMailboxCount","LocalIdCount","RemoteIdCount","BeginBudgetConnections",
             "EndBudgetConnections","BeginBudgetHangingConnections","EndBudgetHangingConnections",
             "BeginBudgetAD","EndBudgetAD","BeginBudgetCAS","EndBudgetCAS","BeginBudgetRPC","EndBudgetRPC",
             "BeginBudgetFindCount","EndBudgetFindCount","BeginBudgetSubscriptions","EndBudgetSubscriptions",
             "MDBResource","MDBHealth","MDBHistoricalLoad","ThrottlingPolicy","ThrottlingDelay",
             "ThrottlingRequestType","TotalDCRequestCount","TotalDCRequestLatency","TotalMBXRequestCount",
             "TotalMBXRequestLatency","RecipientLookupLatency","ExchangePrincipalLatency",
             "HttpPipelineLatency","CheckAccessCoreLatency","AuthModuleLatency","CallContextInitLatency",
             "PreExecutionLatency","CoreExecutionLatency","TotalRequestTime",
             "DetailedExchangePrincipalLatency","ClientStatistics","GenericInfo","AuthenticationErrors",
             "GenericErrors","Puid","StartTime","ProcessId","TimeInGC","StartTotalMemory","EndTotalMemory",
             "StartGCCounts","EndGCCounts","TokenBasedThrottlingPolicy","BudgetKey","CoinsCharged",
             "CoinsChargedMethod","SidBudgetInfo","AppBudgetInfo","TenantBudgetInfo","ResourceAccessed",
             "ResourceHealthBasedThreshold","ThrottledBy","BackoffHint","WorkClassification")

Ich habe die Ergebnisse erst mal in einer Variablen abgelegt. Achten Sie dabei aber auf ihren Speicherbedarf. Ein Kundenserver mit ca. 2000 Benutzern hat ca. 1GB Logdateien pro Tag, die 23.000 vorgefilterte Einträge/Tag generieren.

Achten Sie auch auf den Datenschutz, denn Sie könnten ja auch auf Benutzer und deren Nutzungszeit auswerten.

Hier ein Beispiel einer solchen Umgebung. Sie sehen durchaus einige MAC-Clients aber auch viele Anfragen von Skype for Business (OCS) Clients mit unterschiedlichen Versionen. Interessant ist aber auch der Beifang alter und "fremder" Versionen, z.B. einem "Go-http-client", alte Evolution Clients und diverse ältere MacOS-Systeme. Diese Daten sind durchaus auch für eine Qualitätskontrolle der Softwareverteilung nützlich.

#Auswerten nach UserAgent

$ewspusher | group UserAgent -NoElement

Count Name
----- ----
 5539
13528 OC/16.0.4795.1000 (Skype for Business)
 2686 Go-http-client/1.1
 3352 Mozilla/5.0
   97 SkypeRoomSystem/4.0.64.0
   50 OC/16.0.4705.1000 (Skype for Business)
  226 OC/16.0.4780.1000 (Skype for Business)
  795 MacOutlook/16.19.0.181109 (Intelx64 Mac OS X Version 10.14.2 (Build 18C54))
  419 MacOutlook/16.11.0.180311 (Intelx64 Mac OS X Version 10.13.6 (Build 17G2307))
   86 ExchangeServicesClient/0.0.0.0
    1 SkypeRoom/4.0.64.0 (Skype Room)
    4 LYNC/6.0.9319.534/Storage
  645 MacOutlook/16.16.5.181209 (Intelx64 Mac OS X Version 10.12.6 (Build 16G1815))
   55 OC/16.0.4639.1000 (Skype for Business)
   61 OC/16.0.4771.1000 (Skype for Business)
  104 OC/16.0.4732.1000 (Skype for Business)
    1 ASProxy/CrossSite/Directory/EXCH/15.01.1591.012
  149 Evolution/3.28.1
  107 AppleExchangeWebServices/307 Mail/3445.102.3
  303 MacOutlook/16.16.4.181110 (Intelx64 Mac OS X Version 10.14.2 (Build 18C54))
  120 MacOutlook/15.41.0.171205 (Intelx64 Mac OS X Version 10.14.2 (Build 18C54))
  519 OC/16.0.4756.1000 (Skype for Business)
   28 AppleExchangeWebServices/307 Mail/3445.100.39
   54 MacOutlook/16.16.6.190114 (Intelx64 Mac OS X Version 10.14 (Build 18A391))
   38 OC/4.0.7577.4446 (Microsoft Lync 2010)
   28 OC/16.0.4717.1000 (Skype for Business)
    2 Microsoft Office/16.0 (Windows NT 6.1; Microsoft Outlook 16.0.4738; Pro)
   10 OC/4.0.7577.4540 (Microsoft Lync 2010)

$ewspusher | group soapaction -NoElement | ft -AutoSize

Count Name
----- ----
 5533 Sbsc_WrtRspFailed
 7965 GetStreamingEvents
14387 GetEvents
 1109 Subscribe
    4 GetUserPhoto
    1 GetMailTips
    6 Sbsc_[StreamingConnection.EnqueueTask] Connection is disposed.  Rejecting new task.
    2 GetUserAvailability



# Auswertung nach angemeldeter Benutzer
$ewspusher | group AuthenticatedUser -NoElement

Sie können natürlich auch mit LogParser und LogParser Studio solche Dateien sehr schnell auswerten:

Eine Beispielabfrage wäre dann

SELECT *
INTO '[OUTFILEPATH]\ewspusher.CSV'
FROM '[LOGFILEPATH]'
WHERE SoapAction LIKE '%Subscribe%' OR SoapAction = 'Getstreamingevents' or SoapAction LIKE '%pull%'

So können Sie aber einen ersten Einblick erhalten, welche Clients, Benutzer und Produkte aktuell mit EWS-Push arbeiten und vielleicht bei einer Deaktivierung auf Probleme laufen könnten.

Etwas allgemeiner ist die Kontrolle der Nutzung über die Performance Counter

Diese Daten von einem aktiven Server zeigen aber, dass die Funktion hier anscheinend deutlich intensiver genutzt wird als die Streaming Connections. Ich tippe aber hier auch auf interne Call-Backs z.B. zwischen Exchange Servern.

Wenn Sie das Exchange Eventlog Logging hochschrauben, dann erhalten Sie Warnungen einer fehlgeschlagenen Push-Benachrichtigung.

Set-EventLogLevel "MSExchange Web Services\Core" -Level expert
Type: Warning 
Source: MSExchange Web Services 
Category: Core 
EventID: 5 
Date: 2014-01-27 
Time: 22:57:49 
User: N/A 
Computer: EX2016
Description: Unable to send a notification for subscription SDGBGHGZJKDFDG51354FGH. Will retry. 

Alles eine Frage der Firewall?

Ob die hier gemachten Aussagen korrekt sind, konnte ich noch nicht 100% verifizieren. Es gibt Aussagen, dass die Push-Benachrichtigung eine eigene TCP-Verbindung aufmacht. In dem Fall funktionierten die hier vorgestellten Überlegungen. Wenn Exchange aber die gleiche TCP-Connection nutzt, dann versagt diese Filterfunktion.

Aber in dem Zuge sei einfach mal die Frage gestellt, wohin sich ihr Exchange Server denn um Himmels willen einfach per HTTP verbinden darf?. Es gibt schon legitime Kommunikationswege, z.B.

  • Frontend 2 Backend Proxy
    Damit ein Client den Frontend erreicht und dieser die Anfrage natürlich zum richtigen Backend senden kann
  • Free/Busy bei Federation
    Natürlich muss der Exchange Server sowohl das Microsoft Federation Gateway als auch die EWS-Ziele verbundener Organisationen, insbesondere Office 365 beim Hybrid-Mode, erreichen
  • Patternupdates
    Der in Exchange eingebaute Virenscanner muss auch eine Verbindung zu Updatequellen nutzen können
  • Windows Update/Management
    WSUS und Windows Updates werden gerne auch über HTTPS vom Server gezogen

Aber bei all den Kommunikationswegen sind die Gegenstellen eigentlich "bekannte" Server, die anhand von IP-Adressen klar beschrieben werden können. Umgekehrt können natürlich aus jedem Subnetz entsprechend eingehende Verbindungen von Clients zum Server aufgebaut werden. Aber die Richtung eines Verbindungsaufbau kann heute jede Firewall sehr gut auseinander halten. Vielleicht ist genau diese Lücke mal wieder Anlass über Zonen ihres Netzwerks und die Kontrolle von Verbindungen nachzudenken. Wenn der Exchange Server gar nicht erst "fremde" Webseiten ansprechen kann, dann können diese und zukünftige Lücken einfach blockiert werden. Das folgende Bild soll das Thema noch mal aufgreifen:

Jeder Client darf sich natürlich mit dem Exchange Server verbinden. Hierbei startet der Client aber die TCP-Verbindung on einem High-Port auf den Port 443 des Exchange Servers. Der Exchange Server selbst mach seinerseits natürlich auch Verbindungen per HTTP zu anderen Systemen auf. Das kann durchaus auch ein "altes" Archivsystem sein, welches immer noch mit Push-URLs arbeitet. Es ist aber soweit vertrauenswürdig, dass es zumindest im Datacenter steht.

Weitere Links