Exchange Rechte

Die Sicherheitslücken Anfang 2019 (Siehe auch Exchange Fail Jan 2019 - CVE-2018-8581) haben das Augenmerk auch auf die Berechtigungen der Exchange Server gelenkt. Exchange 2007 und höher haben ja ein von anderen Produkten abweichendes Berechtigungsmodell (Siehe Exchange Permission Model) und die Rechte, die der Exchange Administrator nicht mehr hat, hat nun das "Exchange Trusted Subsystem", mit dem auch mit Exchange Server arbeiten.

Was macht PrepareDomain?

Sowohl beim "Shared" als auch beim "Split Permission Modell" hat die Gruppe "Exchange Trusted Subsystem" einige Berechtigungen auf alle Domänen in ihrem Forests. Für die Einrichtung dieser Rechte ist der Administrator während der Installation zuständig. Er führt nämlich in allen Domänen mit Exchange Objekten die Aktion "/PrepareDomain" aus.

Exchange Server is a directory services-enabled application. Therefore, it must be able to modify attributes that are related to Exchange Server-enabled objects. This includes the ability to modify Discretionary Access Control Lists (DACLs) in some instances. Because these objects can exist anywhere in the domain hierarchy, Exchange Server grants rights to servers that are running Exchange Server at the root of the domain. This is done to make sure that the rights are passed on to all applicable objects.
Quelle: https://support.microsoft.com/en-us/help/4490059/using-shared-permissions-model-to-run-exchange-server

Für Exchange 2013 hat Microsoft noch sehr umfangreich die Berechtigungen einzeln dokumentiert.

Eine vergleichbare Liste habe ich für Exchange 2016/2019 noch nicht gefunden. Allerdings protokolliert das Exchange Setup ja jeden Schritt im der Logdatei C:\ExchangeSetupLogs\ExchangeSetup.log. Suchen Sie einfach nach folgendem String

Beginning processing initialize-DomainPermissions

Damit sollten Sie direkt an die Stelle komme, an der das Setup die Berechtigungen liest und schreibt. Hier finden Sie auch viele "Lesezugriffe" und auch Fehlermeldungen, dass er vielleicht Berechtigungen nicht entfernen kann, wenn Sie eh nicht vorhanden sind. Interessant sind also eher die Rechte die er tatsächlich addiert. Wenn eine bestehende Installation aktualisiert wird, dann meldet er auch vorhandene Rechte aber ohne Details

[09.27.2019 14:56:37.0424] [2] Adding the access control entry on the object CN=DnsAdmins,CN=Users,DC=UCLABOR,DC=DE: S-1-5-21-4124281298-819535733-1525930181-1868; Deny; WriteProperty; ContainerInheritAll; bf9679c0-0de6-11d0-a285-00aa003049e2.
[09.27.2019 14:56:37.0424] [2] Adding the access control entry on the object CN=DnsAdmins,CN=Users,DC=UCLABOR,DC=DE: S-1-5-21-4124281298-819535733-1525930181-1868; Deny; WriteProperty; ContainerInheritAll; 0296c120-40da-11d1-a9c0-0000f80367c1.
[09.27.2019 14:56:37.0424] [2] Used domain controller DC01.UCLABOR.DE to write object CN=DnsAdmins,CN=Users,DC=UCLABOR,DC=DE.
[09.27.2019 14:56:37.0549] [2] Can't remove the access control entry on the object "DC=UCLABOR,DC=DE" for attribute "ExtendedRight (ObjectType: ab721a53-1e2f-11d0-9819-00aa0040529b)" because the ACE isn't present.
[09.27.2019 14:56:37.0549] [2] Removing the access control entry from the object DC=UCLABOR,DC=DE: S-1-5-21-4124281298-819535733-1525930181-1866; Allow; WriteDacl; ContainerInheritDescendents; bf967a9c-0de6-11d0-a285-00aa003049e2.
[09.27.2019 14:56:37.0580] [2] Removing the access control entry from the object DC=UCLABOR,DC=DE: S-1-5-21-4124281298-819535733-1525930181-1868; Allow; WriteDacl; ContainerInheritAll; bf967aba-0de6-11d0-a285-00aa003049e2.
[09.27.2019 14:56:37.0580] [2] Removing the access control entry from the object DC=UCLABOR,DC=DE: S-1-5-21-4124281298-819535733-1525930181-1868; Allow; WriteDacl; ContainerInheritAll; 4828cc14-1437-45bc-9b07-ad6f015e5f28.
[09.27.2019 14:56:37.0596] [2] Adding the access control entry on the object DC=UCLABOR,DC=DE: S-1-5-21-4124281298-819535733-1525930181-1866; Deny; WriteProperty; ContainerInheritAll; f3a64788-5306-11d1-a9c5-0000f80367c1.
[09.27.2019 14:56:37.0596] [2] The appropriate access control entry is already present on the object "DC=UCLABOR,DC=DE" for account "UCLABOR\Exchange Servers".
[09.27.2019 14:56:37.0596] [2] The appropriate access control entry is already present on the object "DC=UCLABOR,DC=DE" for account "UCLABOR\Exchange Servers".
[09.27.2019 14:56:37.0596] [2] The appropriate access control entry is already present on the object "DC=UCLABOR,DC=DE" for account "NT AUTHORITY\Authenticated Users".
[09.27.2019 14:56:37.0596] [2] The appropriate access control entry is already present on the object "DC=UCLABOR,DC=DE" for account "UCLABOR\Exchange Servers".
......
[09.27.2019 14:56:37.0612] [2] The appropriate access control entry is already present on the object "DC=UCLABOR,DC=DE" for account "UCLABOR\Exchange Servers".
[09.27.2019 14:56:37.0612] [2] The appropriate access control entry is already present on the object "DC=UCLABOR,DC=DE" for account "UCLABOR\Organization Management".
[09.27.2019 14:56:37.0612] [2] The appropriate access control entry is already present on the object "DC=UCLABOR,DC=DE" for account "UCLABOR\Exchange Trusted Subsystem".
.....
[09.27.2019 14:56:37.0627] [2] The appropriate access control entry is already present on the object "DC=UCLABOR,DC=DE" for account "UCLABOR\Exchange Servers".
[09.27.2019 14:56:37.0643] [2] The appropriate access control entry is already present on the object "DC=UCLABOR,DC=DE" for account "NT AUTHORITY\NETWORK SERVICE".
.....[
09.27.2019 14:56:37.0674] [2] The appropriate access control entry is already present on the object "DC=UCLABOR,DC=DE" for account "UCLABOR\Exchange Windows Permissions".
[09.27.2019 14:56:37.0674] [2] The appropriate access control entry is already present on the object "DC=UCLABOR,DC=DE" for account "UCLABOR\Exchange Windows Permissions".
[09.27.2019 14:56:37.0674] [2] Adding the access control entry on the object DC=UCLABOR,DC=DE: S-1-5-21-4124281298-819535733-1525930181-1868; Allow; WriteDacl; ContainerInheritDescendents; bf967aba-0de6-11d0-a285-00aa003049e2.
[09.27.2019 14:56:37.0674] [2] Adding the access control entry on the object DC=UCLABOR,DC=DE: S-1-5-21-4124281298-819535733-1525930181-1868; Allow; WriteDacl; ContainerInheritDescendents; 4828cc14-1437-45bc-9b07-ad6f015e5f28.
.......
[09.27.2019 14:56:37.0705] [2] Removing the access control entry from the object CN=AdminSDHolder,CN=System,DC=UCLABOR,DC=DE: S-1-5-21-4124281298-819535733-1525930181-1866; Allow; WriteDacl; ContainerInheritDescendents; bf967a9c-0de6-11d0-a285-00aa003049e2.
......
[09.27.2019 14:56:37.0752] [2] Adding the access control entry on the object CN=AdminSDHolder,CN=System,DC=UCLABOR,DC=DE: S-1-5-21-4124281298-819535733-1525930181-1866; Deny; WriteProperty; ContainerInheritAll; f3a64788-5306-11d1-a9c5-0000f80367c1.
......
[09.27.2019 14:56:37.0987] [2] The SeSecurityPrivilege privilege is already assigned to account S-1-5-21-4124281298-819535733-1525930181-1865.
[09.27.2019 14:56:37.0987] [2] Adding access control entries to the security descriptor for the object CN=Deleted Objects,DC=UCLABOR,DC=DE.
......
[09.27.2019 14:56:53.0050] [2] Added group CN=Exchange Install Domain Servers,CN=Microsoft Exchange System Objects,DC=UCLABOR,DC=DE to CN=Exchange Servers,OU=Microsoft Exchange Security Groups,DC=UCLABOR,DC=DE on DC01.UCLABOR.DE, link resolution server is DC01.UCLABOR.DE
[09.27.2019 14:56:53.0050] [2] Added group CN=Exchange Servers,OU=Microsoft Exchange Security Groups,DC=UCLABOR,DC=DE to CN=Windows Authorization Access Group,CN=Builtin,DC=UCLABOR,DC=DE on DC01.UCLABOR.DE, link resolution server is DC01.UCLABOR.DE

[09.27.2019 14:56:53.0065] [2] Used domain controller DC01.UCLABOR.DE to write object CN=Microsoft Exchange System Objects,DC=UCLABOR,DC=DE.
[09.27.2019 14:56:53.0065] [2] Ending processing initialize-DomainPermissions

Soweit ist dies noch verständlich, denn Exchange benötigt ja entsprechende Berechtigungen, um im Auftrag des Administrators die Aktionen durchzuführen.

Risiko Exchange Rechte

Bei allen Betriebsmodellen muss natürlich sichergestellt werden, dass dieser Code keinen Mist macht, d.h. dass unter den Rechten von "Computername$" und damit als Mitglied von "Exchange Trusted Subsystem" nur die gewünschten Aktionen ablaufen. Nun wissen wir aber auch, dass jede Software "Fehler" hat und Programmierer nicht immer sich auf die minimalen Berechtigungen beschränken. So passierte es auch Microsoft, dass Exchange mehr Berechtigungen hatte, als die für die eigentliche Funktion erforderlich ist. Hier gibt es aber verschiedene Risiken

  • "Mad Admin"
    Natürlich kann ein Exchange Admin mit seinen Berechtigungen auch Unfug machen. Das liegt in der Natur der Sache und auch wenn er Dank RBAC - Role Based Access Control vielleicht nur ausgewählte Schritte ausführen darf, könnte ja dennoch z.B. die Gruppe "Domänen Administratoren" zu einem Mailverteiler machen und dann auch mit Exchange Bordmitteln die Mitglieder pflegen. Er könnte sich vielleicht auch zusätzliche Benutzer anlegen und diese in bestehende Verteiler addieren. Das wäre zwar alles strafbar aber sie müssten es erst einmal bemerken.
    Arbeiten mit "reduzierten Rechten" ist hier eine Lösung, z.B.: in dem Administratoren eben nicht "Exchange Organization Admin" sind sondern vielleicht nur "User Admin" mit einem Scope auf die OU der normalen Anwender. Gerade über den "Scope" kann ein Admin sehr gut schon eingeschränkt werden.
    Das ist auch wichtig, damit keine Malware z.B. "als Admin" solche Anpassungen vornimmt.
  • Exchange Minimum Permission
    Natürlich sollten auch die Entwickler von Exchange darauf achten, dass die Exchange Berechtigungsgruppen auch nur die erforderlichen Berechtigungen während der Installation bekommen. Leider hat hier Microsoft in der Vergangenheit auch etwas geschludert und zu viele Berechtigungen vergeben. Updates haben das gefixt aber müssen natürlich auch richtig eingespielt werden. Aber auch die minimal erforderlichen Rechte sind für viele Firmen zu viel. Dann könnte ein Deployment als "Resource Forest" eine Lösung sein, so dass Exchange nur in seinem eigenen Forest etwas tun darf aber die Anmeldeforests nicht angefasst werden.
  • Exchange Programmfehler
    Wenn die Exchange Dienst zu viele Rechte haben, dann sollte der Code "sicher" sein. Aber Fehler passieren und daher gibt es immer wieder Updates, die solche Fehler bereinigen. Auf der einen Seite bemüht Microsoft sich natürlich erkannte "Lücken" umgehend zu patchen aber es könnte immer Lücken geben, die nicht "bekannt" aber ausgenutzt werden. Dennoch sind aktuelle Versionen für Exchange die wichtigste Voraussetzung für einen sicheren Betrieb.

Die Rechte sind einfach sehr umfangreich und natürlich gibt es weitere Fragen, die offenen Stellen weiter zu reduzieren.

Split Permission

Microsoft bietet bei der Installation und bei Updates an ein etwas eingeschränktes Berechtigungsmodell anzuwenden. Bei einer Standardinstallation bekommt Exchange auch das Recht, Postfächer und Verteiler neu anzulegen und zu löschen. Der Exchange Admin muss nicht darauf warten, dass ein Account Admin erst die passenden AD-Objekte anlegt. Allerdings hat das Active Directory auch die Besonderheit, dass jedes Objekt einen "Besitzer" haben muss, der auch wieder Berechtigungen ändern kann. Es macht für den Anwender und das Postfach oder die Verteilergruppe keinen Unterschied, wer das Konto letztlich anlegt, Aber für die Sicherheit ist es sehr wohl ein Unterschied, wer der "Besitzer" ist. Wenn Sie daher ihr Berechtigungsmodell auf "Split" umstellen, dann verliert das Administrator den Zugriff auf folgende Commandlets:

New-Mailbox
New-MailContact
New-MailUser
New-RemoteMailbox
Remove-Mailbox
Remove-MailContact
Remove-MailUser
Remove-RemoteMailbox
Add-DistributionGroupMember
New-DistributionGroup
Remove-DistributionGroup
Remove-DistributionGroupMember
Update-DistributionGroupMember

Und auch die reduzierten Berechtigungen beim "Split Permission Model" sind beschrieben

In Hinblick auf die Security Lücke in EWS (Siehe Exchange Fail Jan 2019 - CVE-2018-8581) kann man natürlich sagen, dass all die Firmen mit dem "Split Permission Model" hier nicht verwundbar waren. Beim Split Permission Modell muss er ja direkt per LDAP die Objekte anlegen und ändern können weil Exchange es nicht mehr kann.

Damit die Änderungen aber aktiv werden, müssen Sie nach Installation des Updates auf jeden Fall ein "/PrepareDomain" ausführen, damit die Anpassungen erfolgen.

REM Exchange CU Installationsquellen
setup.exe /preparedomain /IAcceptExchangeServerLicenseTerms

Ich habe bei mir mal die Änderungen mit GET-ADChanges verfolgt und folgende Änderungen gesehen:

Genauer sehen Sie es natürlich im ExchangeServerSetup.Log

12/18/2019 15:43:41,Modify,DC=msxfaq,DC=de,ntsecuritydescriptor,System.Byte[]
12/18/2019 15:43:41,Modify,CN=Deleted Objects,DC=msxfaq,DC=de,ntsecuritydescriptor,System.Byte[]
12/18/2019 15:43:41,Modify,CN=AdminSDHolder,CN=System,DC=msxfaq,DC=de,ntsecuritydescriptor,System.Byte[]

Ex2016CU12/Ex2019CU1:
The AdminSDHolder object on the domain is updated to remove the "Allow" ACE that grants the "Exchange Trusted Subsystem" group the "Write DACL" right on the "Group" inherited object types.
Ex2013CU22
The "Allow" Access Control Entry (ACE) that grants the "Exchange Windows Permissions" group the "Write DACL" right to the "User" and "INetOrgPerson" inherited object types is updated to include the "Inherit Only" flag on the domain root object.
Ex2010:
manuelle Anpassung erforderlich
Quelle: https://support.microsoft.com/en-us/help/4490059/using-shared-permissions-model-to-run-exchange-server

Die aktuell auf AdminSDHolder zugewiesenen Berechtigungen können Sie natürlich auch per PowerShell auslesen

(get-acl -Path "AD:\CN=AdminSDHolder,CN=System,DC=msxfaq,DC=de").access `
| where-object {$_.I dentityReference.tostring().endswith("Exchange Trusted Subsystem")}

Security Bugfixes

Die erweiterten Berechtigungen von Exchange sind natürlich auch für Hacker interessant. Wenn es ihnen gelingt die Sicherheitsprüfungen zu umgehen, könnten Sie auf interessante Postfach-Inhalte zugreifen. Die meisten Exchange Server sind auf die ein oder andere Weise auch aus dem Internet erreichbar, z.B.: per OWA, ActiveSync, EWS oder MAPI/HTTP. Auch Mails per SMTP müssen von Exchange "verarbeitet" werden. Natürlich sollte Exchange hier "Daten" und Programme klar voneinander trennen. Aber Mails müssen schon interpretiert werden, z.B. BASE64-Codierung, Spam/Antivirus-Filter, Transportregeln und der Code muss hier mit jeder "Falschformatierung" umgehen können.

Die Erfahrung zeigt, dass dies nicht immer gelingt und da ist Microsoft in guter Gesellschaft. Daher ist es wichtig, dass ihre Produkte zeitnah Updates erhalten und Sie diese auch installieren:

Auch ein Jahr später gab es wieder eine Meldung, dass eine gezielt formulierte Mal Exchange dem tritt bringen könnten und damit erhöhte Zugriffe möglich seien.

CVE-2020-0688 – Microsoft Exchange Memory Corruption Vulnerability
This code execution bug in Exchange is only listed as Important, but you should treat it as a Critical-rated vulnerability. An attacker could gain code execution on affected Exchange servers by sending a specially crafted e-mail. No other user interaction is required. The code execution occurs at System-level permissions, so the attacker could completely take control of an Exchange server through a single e-mail. This bug was reported through our program, and we’ll publish details about it in the near future.
Quelle: https://www.zerodayinitiative.com/blog/2020/2/11/the-february-2020-security-update-review

Aber auch früher gab es schon die ein oder andere "Lücken". die immer schnell gefixt wurden.

Exchange härten?

Ein Betriebssystem oder Software robuster gegen Angriffe zu konfigurieren wird auch als "härten" bezeichnet. Entsprechend finden sich auch Quellen im Internet, die mehr oder weniger übereinstimmen. So können bestimmte standardmäßig installierte Dienste und Einstellungen entfernt werden. Wer z.B. nie POP3 oder IMAP4 verwendet, muss den Dienst nicht auf "automatisch" stellen. Allerdings werden die Dienste sowieso schon länger nicht mehr automatisch gestartet. Viele Schritte gehören aber eh schon zum guten Ton einer Serverinstallation. Sie schützen aber nicht gegen einen Fehler im Exchange Code oder einer für Exchange erforderlichen Komponente, die von einem Angreifer ausgenutzt werden kann.

Sie verbessern natürlich schon die Gesamtsicherheit und schützen damit auch besser gegen Angriffe von innen, z.B. SMB1 abschalten, Spooler deaktivieren, Admin-Konten umbenennen, etc. Ich habe dennoch einige Links hier versammelt

Infos zu Lücken und deren Nutzung

Natürlich beruhen die Security Updates auf Entdeckungen anderer Personen, die über verschiedene Wege es dann geschafft haben, als "Exchange Server" und als "Exchange Trusted Subsystem" zu arbeiten. Ich möchte und kann die individuellen Szenarien nicht bewerten. Zum Teil werden eigentlich NTLM-Schwächen genutzt, um als "Man in the Middle"-Attack sich die NTLM-Hashed zu erhalten und dann quasi als Server zu agieren. Solche Angriffe lassen sich recht zuverlässig verhindern, wenn der Zugang zum Netzwerk abgesichert ist (802.1x, IPSec) oder NTLM-Signing erzwungen wird. Leider gibt es aber auch heute noch Administratoren, die über eine SMB1 Abschaltung nicht mal nachgedacht, geschweige denn umgesetzt haben.

Trotzdem würde ich dem interessierten Administrator immer dazu raten, auch solche Informationen zu lesen und in das eigene Handeln einzubeziehen.

Weitere Links