Exchange Hybrid Absicherung

Für die Koexistenz von Exchange OnPremises mit Microsoft 365-Diensten wie Exchange Online und insbesondere Microsoft Teams ist ein "Hybrid-Mode" erforderlich. Wer in Teams auch auf Kalender von lokalen Postfächern zugreifen will, muss "Classic Hybrid" einrichten, bei dem die lokalen Exchange Server von Exchange Online per Autodiscover, EWS und MRSPROXY erreichbar sind. Diese Seite behandelt die Absicherung dieses Zugangs.

Risiken

Schon vor der Cloud habe ich mit Exchange OnPremises immer zwei Gruppen von Kunden gehabt. Die eine Gruppe hat Exchange OnPremises per HTTPS aus dem Internet erreichbar gemacht und darauf vertraut, dass Exchange sich schon gut "wehrt" und die Anwender ihr Zugangsdaten sicher aufbewahren. Nur ganz kleine Firmen haben dazu ihren Exchange Server über Port 443 per NAT oder sogar direkt erreichbar gemacht. In der Regel ist schon eine Firewall/Portfilter davor und die Sicherheit konnten wir durch einen ReverseProxy weiter steigern, welcher eine Preauthentifizierung durchgeführt hat. Auch MDM-Lösungen haben den ActiveSync-Zugang zusätzlich abgesichert.

Dennoch ist es auch heute damit immer noch möglich, z.B.: per Username/Kennwort-Attacken entweder interne Konten zu sperren oder Zugänge zu erraten oder abgephishte Zugangsdaten direkt zu missbrauchen. Auch haben uns der Hafnium Exploit u.a. gezeigt, dass jede Software Fehler haben kann, die teils ohne Authentifizierung missbraucht werden können.

Die andere Firmengruppe hat ihren Exchange Server nicht direkt veröffentlicht, sondern nur von "intern" erreichbar gemacht. Das schützt zwar nicht generell, da es auch viele internen Angriffe gibt aber der Angreifer musste erst einmal ins LAN kommen. Benutzer im Homeoffice oder auf Reisen haben dann ein VPN aufgebaut, um als "intern" und vertrauenswürdiger zu zählen.

Exchange Erreichbarkeit

Für den Exchange Hybrid Mode kann ich aber kein VPN nutzen und muss meinen Exchange Server zumindest für bestimmte Subnetze aus dem Internet erreichbar machen. Microsoft beschreibt dies auch:

In der ersten Tabelle wird recht allgemein beschrieben, welche eingehenden Verbindungen erforderlich sind:


Quelle: https://docs.microsoft.com/en-us/exchange/hybrid-deployment-prerequisites

Das ist aber eine sehr verallgemeinerte Übersicht und führt nur die "Exchange Online Endpoints" auf. Diese Liste ist auch durchaus stattlich und kann auf folgender Seite eingesehen werden:

Aber auf der gleichen Seite gibt es weiter unten noch eine detailliertere Tabelle zu den einzelnen URLs, auf der ich schon mal die Exchange 2010/2013-Einträge entfernt habe:


Quelle: https://docs.microsoft.com/en-us/exchange/hybrid-deployment-prerequisites

Aber auch so ist sichtbar, dass es für keinen Weg eine "PreAuth" gibt und die Mailbox Migration sogar NTLM/Basic erfordert. Dennoch können wir nun weitere Absicherungen diskutieren können.

Source IP

Der erste Verteidigungsring ist natürlich die Filterung auf die Quell-IP-Adresse. Da der komplette Verkehr über HTTPS (oder SMTP) abgewickelt wird, findet immer ein TCP-Handshake (TCP SYN ACK RES) statt. Ein Angreifer könnte daher maximal einen TCP-SYN-Flooding gegen die veröffentliche öffentliche IP-Adresse absenden, deren ACK-Antwort dann die missbrauchte Adresse treffen würde. Eine Verbindung käme aber nie zustande.

Das Problem bei dieser Konfiguration ist aber, dass die Liste der IP-Adressen durchaus mächtig ist. Früher gab es mal ein PowerShell-Commandlet, um die Exchange Datacenter IPs für einen Tenant zu ermitteln aber die Funktionen sind mittlerweile entgefallen oder depreciated:

Auf der andern Seite kann man natürlich annehmen, dass jeder Exchange Frontend Server nicht von den Clients selbst eingehend angesprochen wird, sondern seinerseits auch ausgehende Verbindungen zu anderen Exchange Servern in Exchange Online aber eben auch über Hybrid zur OnPremises-Umgebung aufbauen. Allein für Exchange hat Microsoft mehrere IDs

PS C:\> $o365range=Invoke-RestMethod https://endpoints.office.com/endpoints/worldwide?clientrequestid=b10c5ed1-bad1-445f-b386-b919946339a7
PS C:\> $o365range | where {$_.serviceArea -eq "Exchange"} | ft id,urls,tcpports,notes

 id urls                                                               tcpPorts notes
 -- ----                                                               -------- -----
  1 {outlook.office.com, outlook.office365.com}                        80,443
  2 {smtp.office365.com}                                               587
  3 {r1.res.office365.com, r3.res.office365.com, r4.res.office365.com} 80,443
  5 {*.outlook.office.com, outlook.office365.com}                      143,993  Exchange Online IMAP4 migration
  6 {*.outlook.office.com, outlook.office365.com}                      995      Exchange Online POP3 migration
  8 {*.outlook.com, attachments.office.net}                            80,443
  9 {*.protection.outlook.com}                                         443
 10 {*.mail.protection.outlook.com}                                    25
154 {autodiscover.*.onmicrosoft.com}                                   80,443

Allerdings waren beim letzten Check die IP-Adressen von ID1, 5 und 6 identisch und interessant sind auch nur die Bereich mit 80/443. Aber auch diese Liste ist durchaus lang:

PS C:\> ($o365range | where {$_.id -eq 1}).ips
13.107.6.152/31
13.107.18.10/31
13.107.128.0/22
23.103.160.0/20
40.96.0.0/13
40.104.0.0/15
52.96.0.0/14
131.253.33.215/32
132.245.0.0/16
150.171.32.0/22
204.79.197.215/32
2603:1006::/40
2603:1016::/36
2603:1026::/36
2603:1036::/36
2603:1046::/36
2603:1056::/36
2620:1ec:4::152/128
2620:1ec:4::153/128
2620:1ec:c::10/128
2620:1ec:c::11/128
2620:1ec:d::10/128
2620:1ec:d::11/128
2620:1ec:8f0::/46
2620:1ec:900::/46
2620:1ec:a92::152/128
2620:1ec:a92::153/128
2a01:111:f400::/48

Allein wenn ich nur die IPv4-Adressen anschaue, sind ein /13-Subnetz schon über 500.000 IP-Adressen und das /14 noch 256000-Adressen , so dass die /16, /20, /22-Subnetze gar nicht mehr auffallen. Bei den knapp 1 Mio IPv4-Adressen sind die IPv6-Adresse noch gar nicht berücksichtigt. Allein ein Subnetz wie "2603:1026::/36" sind "4,951,760,157,141,521,099,596,496,896" Hosts. Die Frage bleibt, ob diese IP-Adressen wirklich alle von Exchange Online Servern benutzt werden und nicht auch fremde Dienste, z.B. AzureVMs o.ä. im gleichen IP-Bereich angesiedelt sein könnten.

Eine Aussage von Microsoft, dass hier nur Exchange Server stehen, habe ich noch nicht. Für die Microsoft Teams IP-Bereiche der Transport-Relays gibt es so eine Aussage. Siehe auch IP-Adressen vertrauen

Dennoch ist natürlich die Filterung auf diese IP-Adressen die erste Schutzfunktion, wenn die eigenen Exchange Server nicht aus dem Internet erreicht werden sollen.

URLs

Ich kann zwischen Exchange Online und meine OnPremises Exchange Server natürlich einen Reverse Proxy schalten. Wenn ich mehrere Server nutze, dann ist ein Loadbalancer sinnvoll. Beide Systeme können nun einfach TCP-Verbindungen durchleiten oder sie können die HTTPS-Verbindungen selbst terminieren. Wenn die externe Anfrage hier terminiert wird, kann das System die Inhalte untersuchen und z.B. nach URLs filtern. Wenn Sie die Liste weiter oben betrachten, dann sehen Sie schon, dass allein für den Hybrid-Mode nur einen Auswahl an URLs erforderlich ist.

ALLOW /autodiscover/autodiscover.svc/wssecurity
ALLOW /autodiscover/autodiscover.svc
ALLOW /ews/exchange.asmx/wssecurity
ALLOW /ews/mrsproxy.svc
BLOCK / *

Ich brauche für den Hybrid-Mode z.B. weder "/owa", "/mapi" noch "/rpc" oder "oab". Diese Zugänge kann ich von extern blockieren oder gar nicht erst veröffentlichen und damit entsprechende Lücken besser absichern. Und selbst der Zugriff auf "/EWS" kann ich auf den MRSPROXY als auch die Unterverzeichnisse "wssecurity" beschränkten. Damit verhindere ich, dass z.B. Mac-Benutzer per EWS mit einfacher Anmeldung überhaupt erst den Server erreichen und eine Anmeldung versuchen können. Denken Sie daran, dass dieses Zwischensystem seinerseits die Zugriff zum nachgelagerten Exchange Server wieder per HTTPS verschlüsseln muss.

Dieser Schutz ist schon sehr gut aber noch ist es möglich, dass von den Microsoft IP-Adressen anonyme Anfragen den Exchange OnPremises Server erreichen und eine Lücke von Exchange ausnutzen. Seit dem Hafnium Exploit sind die Exchange Administratoren zurecht vorsichtig.

Authentication

Anhand der Tabelle haben wir gesehen, dass Exchange Online sich gegen den lokalen Exchange, mit Ausnahme des MRSProxy bei einer Postfachmigration, eine Authentifizierung per "WS-Security Authentication" durchführt. Die Besonderheit dieser Authentifizierung ist, dass keine Benutzernamen oder Kennworte übertragen werden, sondern OAUTH-Tokens. Exchange Online hat ja sowieso kein "Dienstkonto" für den Zugriff auf den lokalen Exchange Server. Stattdessen vertraut der lokale Exchange Server der "Azure AD Authentication Service", der entsprechend digital signierte Tokens ausstellt. Zudem ist die Payload selbst digital signiert aber nicht verschlüsselt. Für die Verschlüsselung der übertragenen Daten sorgt die Transportverschlüsselung per HTTPS.

Wenn wir aber schon für die URL-Prüfung die Daten unverschlüsselt vorliegen haben, dann kann auch dieses System vielleicht auch die Payload auf "Gültigkeit" prüfen. Wenn jeder Request immer mit einem Bearer-Token (Siehe auch Bearer Decoding, Authentifizierung im Wandel der Zeit und HTTP Authentication) kommt, dann kann auch die Applikationsfirewall diese Informationen prüfen. Da nur die "richtigen Exchange Server" auch einen korrekt signierten Request senden können, ist damit eine weitere Schutzfunktion gegen fremden Code umsetzbar. Allerdings hilft das natürlich nicht, wenn der Angreifer die Exchange Online Server gekapert hätte oder als Man in the Middle die Authentifizierungs-Token mitliest.

Die Schutzfunktion muss natürlich alle Varianten der Exchange Online Zugriffe "verstehen". Schon beim ersten Handshake kann es passieren, dass Exchange Online erst einmal einen Request ohne "Bearer" sendet und die Erreichbarkeit zu prüfen und im zweiten Paket ein "leerer Bearer-Header" kommt. Der muss schon durchgelassen werden, damit Exchange OnPremises überhaupt mitteilen kann, von welchem Authentication Service er ein Ticket akzeptiert. Erst mit der dritten Anfrage kommt dann ein gültiges Bearer-Token. Diese Kommunikation habe ich auf Exchange Hybrid Absicherung schon analysiert.

Für eine zusätzliche Sicherheit sollte die Application Firewall natürlich nur Anforderungen zum Exchange OnPremises Server durchlassen, die korrekt authentifiziert sind. Das bedeutet aber auch, dass die Application Firewall natürlich die vorherigen Schritte nachbilden, damit der Exchange Online Server überhaupt eine Anmeldung per Bearer-Token ausführt.

Die Herausforderung hierbei ist natürlich, dass Microsoft das Verhalten auch immer wieder "anpassen" kann.

Für die Prüfung des Bearer-Tokens und anderer Signaturen muss die Application Firewall natürlich zumindest den PublicKey des Signiereres kennen. Microsoft hat die Zusammenhänge bei der Authentifizierung durchaus dokumentiert:

Aus der Beschreibung habe ich folgende URL abgeleitet, welche mir die XML-Datei mit den Zertifikaten gibt.

Invoke-WebRequest https://login.microsoftonline.com/msxfaq.mail.onmicrosoft.com/federationmetadata/2007-06/federationmetadata.xml

Die URL kommt ihnen vielleicht von der Seite ADFS Monitoring oder PRTG Check ADFS bekannt vor, wo ich per Code ebenfalls das Zertifikat auslese, um das Ablaufdatum zu erhalten. Ich habe aus der XML-Datei dann das erste X509-Zertifikat geholt:

Das geht natürlich auch per PowerShell.

Hinweis: Bei mir war das erste Zeichen ein CHR(65279), was auch als "BOM" = "Byte Order Mark" bekannt ist. Daher habe ich es mit einem "Substring" abgeschnitten.

# Abruf der Metadaten meines Tenant
$metadata = Invoke-WebRequest `
                         -method GET `
                         -uri "https://login.microsoftonline.com/msxfaq.mail.onmicrosoft.com/federationmetadata/2007-06/federationmetadata.xml" `
                         -Headers @{"Host"="login.microsoftonline.com"}
# Konvertieren des Body in eine XML-Datei und Extraktion des Siging Zertifikats
$certbase64=([xml]($metadata.content.substring(1))).EntityDescriptor.Signature.KeyInfo.X509Data.X509Certificate

# Konvertrieren des Base64 codierten Zertifikats in ein Byte-Array
$certarray = [System.convert]::FromBase64String($certbase64)

# Instanzieren des Zertifikats anhand des Byte-Arraya
$cert = new-object System.Security.Cryptography.X509Certificates.X509Certificate2 -ArgumentList @(,$certarray)

#Export als CER-Datei fuer weitere Verwendung.
Export-Certificate -Cert $cert -FilePath c:\temp\oauth.cer -Type CER

Nach der Decodierung konnte ich folgende Properties sehen.

$cert | fl *

EnhancedKeyUsageList : {}
DnsNameList          : {accounts.accesscontrol.windows.net}
SendAsTrustedIssuer  : False
Archived             : False
Extensions           : {System.Security.Cryptography.Oid}
FriendlyName         :
HasPrivateKey        : False
PrivateKey           :
IssuerName           : System.Security.Cryptography.X509Certificates.X500DistinguishedName
NotAfter             : 20.12.2025 21:50:17
NotBefore            : 21.12.2020 21:50:17
PublicKey            : System.Security.Cryptography.X509Certificates.PublicKey
RawData              : {48, 130, 3, 5…}
SerialNumber         : 377DD139A209E9B2415830B1B662446E
SignatureAlgorithm   : System.Security.Cryptography.Oid
SubjectName          : System.Security.Cryptography.X509Certificates.X500DistinguishedName
Thumbprint           : 9CEA37643ACE0D710AD63296857B251D1FCA5C48
Version              : 3
Issuer               : CN=accounts.accesscontrol.windows.net
Subject              : CN=accounts.accesscontrol.windows.net

Sie sehen hier auch, dass das Zertifikat eine Gültigkeit von 5 Jahren hat. Alle Dienste, die von diesem Service ausgestellten Tokens verifizieren, müssen rechtzeitig über die Federation Metadata URL den aktuell gültigen Public Key aktualisieren.

Mit dem "Public Key" könnte nun eine Application Firewall die Tokens prüfen und damit auf Anwendungsschicht sicherstellen, dass nur legitime Zugriffe bis zum Exchange Server durchgereicht werden. Also habe ich mich auf die Suche begeben, zu welchen Systemen sich dazu etwas finden lässt:

ich habe entsprechende Filter noch nicht bei Kunden umgesetzt. Bislang war die Beschränkung auf die Source-IP-Range und optional auf URLs als ausreichend sicher angesehen worden.

Es gibt aber schon Hinweise, dass diverse als Reverse Proxy genutzte Produkte die Bearer-Tokens auswerten und Aktionen ausführen können.

Zwischenstand

Eine Beschränkung auf die von Microsoft veröffentlichten IP-Adresse ist eine einfache Lösung den Zugriff auf die lokalen Exchange Server auf Exchange Online zu beschränken. Solange es aber keine Zusicherung von Microsoft gibt, dass diese IP-Range auch nur von Exchange Online genutzt wird, bleibt ein ungutes Gefühl, dass vielleicht doch eine AzureVM eines anderen Tenants mit einer IP-Adresse aus dem Bereich auf ihren lokalen Exchange Server zugreifen könnte.

Der Exchange Online Service weist sich mit seinem OAUTH-Token aus und wenn Sie allein der Verifizierung durch den Code auf dem lokalen Exchange Server nicht trauen, dann könnte eine Prüfung des OAUTH-Tokens einen zusätzlichen Schutz bieten.

Aktuell habe ich noch keine Bestätigung, dass Reverse Proxy Server solche Prüfungen durchführen können und Exchange Online immer ein Bearer-Token mit sendet.

Weitere Links