Inhaltsverzeichnis
Der Standard und das Problem
Exchange Server sind in vielen Active Directory Umgebungen ein bekannter Begleiter. Aus der Perspektive der IT-Sicherheit stellen sie aber ein gewisses Risiko dar. Mit einem Exchange Split Permission Modell kann man das Risiko deutlich reduzieren.
Doch wo kommt dieses Risiko her? Es beginnt bei der Installation des ersten Exchange Servers in einem Active Directory. Da wird die dafür erforderliche Option „Apply Active Directory split permission…“ nicht standardmäßig aktiviert:
Wurde der erste Exchange Server auf diese Weise installiert, dann wird im Active Directory die Sicherheitsbeschreibung erweitert. So kann ein Exchange seine Arbeit aufnehmen. Doch diese Rechteerweiterung hat es in sich. Hier seht ihr ein schönes Beispiel:
Die Gruppe „Exchange Windows Permissions“ hat auf der Domain die Berechtigung zum Ändern und Zurücksetzen von Kennworten erhalten. Diese wird auf „speziell“ angewendet. Das hat die GUI etwas unglücklich gelöst. Schaut man sich aber eine beliebige OU oder einen Container unter der Domain an, dann wird die Berechtigung korrekt dargestellt. Hier mal das Beispiel des Containers „Users“:
Mit meiner PowerShell-Funktion kann ich diese Berechtigung für alle OUs im AD erkennen:
Die Gruppenmitglieder können also Benutzerpassworte in der Domain zurücksetzen. Und wer sind die Mitglieder? Richtig: Die Computerkonten der Exchange Server:
OK, das alleine ist noch nicht problematisch. Gravierend wird es erst, wenn man folgende Fakten dazu zählt:
- Zu den Usern zählen auch alle Adminkonten. Wer den Exchange Server kontrolliert, kann die Passworte von Admins ändern und deren Identität annehmen.
- Zu den Usern gehört auch das Konto KRBTGT. Wer dessen Passwort kennt, kann sich Golden Tickets ausstellen! In einem solchen Fall wird ein Active Directory sehr oft als verloren angesehen. Wie ein Golden Ticket funktioniert, zeige ich hier: https://www.ws-its.de/hacking-kerberos-goldenticket/ die Grundlagen findet ihr hier: https://www.ws-its.de/kerberos-ein-ueberblick/
- Exchange Server sind für meist alle Benutzer intern erreichbar. Zudem sind auch oft aus dem Internet erreichbar (HTTPS für Outlook, OWA und Active Sync, SMTP für Mails).
Ein Angreifer braucht also nur einen Zugriff auf einen Exchange (aus dem Internet oder durch einen internen, kompromittierten Benutzer) und einen Exploit für eine ausnutzbare Schwachstelle. Dann kann er den Exchange Server kontrollieren und damit auch direkt das Active Directory übernehmen
Na zum Glück gibt es kaum Schwachstellen für Exchange Server…
Quelle: CVE – Search Results (mitre.org)
Das sollte als Grund für eine Veränderung eigentlich genügen! Wer es immer noch nicht glauben kann, in diesem Beitrag zeige ich einen einfachen Hack: https://www.ws-its.de/ad-hacking-ueber-exchange-server/
Exchange Rechtemodelle im Überblick
Microsoft bietet uns insgesamt 3 Rechtemodelle an.
Das ist der Standard, den ich in der Einleitung eben beschrieben habe. Dieses Modell bietet sich nach Microsoft an, wenn die gleichen Admins für Exchange und Active Directory zuständig sind. Ich würde da gerne widersprechen. Diese Empfehlung kommt aus einer Zeit, in der kein Tier-Berechtigungsmodell genutzt wurde. In dieser Zeit meldete man sich auch auf Clients als Domain Admin an, um eine Software zu installieren. Das ist nicht mehr zeitgemäß!
Link zu Microsoft: Split permissions in Exchange Server | Microsoft Learn
RBAC split permissions
Mit diesem Modell werden die Rechte an den Exchange Objekten durch eine Role Based Access Control (RBAC) Delegation aufgeteilt. Man erstellt neue Gruppen im AD und weist diesen im Exchange die Rechte an den AD-Objekten zu. Microsoft empfiehlt dieses Modell, da es mit nur wenigen Einschränkungen daher kommt.
Link zu Microsoft: Split permissions in Exchange Server | Microsoft Learn
Active Directory split permissions
Dieses Modell schneidet tief in die Berechtigung ein. Ein Exchange Admin kann nun keine AD-Objekte, wie z.B. Benutzer oder Verteilergruppen mehr anlegen. Das muss ein Active Directory Admin für ihn erledigen.
Link zu Microsoft: Split permissions in Exchange Server | Microsoft Learn
Einschränkungen im Vergleich
Die Rechtetrennung betrifft einzelne Befehle in der PowerShell und natürlich auch deren Pendant in der EAC-Seite:
| cmdlet | shared permissions | RBAC split permissions | AD split permissions |
|---|---|---|---|
| New-Mailbox | Exchange Admins | nur RoleMembers | keine Berechtigung |
| New-MailContact | Exchange Admins | nur RoleMembers | keine Berechtigung |
| New-MailUser | Exchange Admins | nur RoleMembers | keine Berechtigung |
| New-RemoteMailbox | Exchange Admins | nur RoleMembers | keine Berechtigung |
| Remove-Mailbox | Exchange Admins | nur RoleMembers | keine Berechtigung |
| Remove-MailContact | Exchange Admins | nur RoleMembers | keine Berechtigung |
| Remove-MailUser | Exchange Admins | nur RoleMembers | keine Berechtigung |
| Remove-RemoteMailbox | Exchange Admins | nur RoleMembers | keine Berechtigung |
| Add-DistributionGroupMember | Exchange Admins | Exchange Admins | keine Berechtigung |
| New-DistributionGroup | Exchange Admins | Exchange Admins | keine Berechtigung |
| Remove-DistributionGroup | Exchange Admins | Exchange Admins | keine Berechtigung |
| Remove-DistributionGroupMember | Exchange Admins | Exchange Admins | keine Berechtigung |
| Update-DistributionGroupMember | Exchange Admins | Exchange Admins | keine Berechtigung |
Umstellung des Rechtemodells
Vorbereitung
Ich benötige ein aktuelles Exchange Server ISO, da die Umstellung des Rechtemodells mit der setup.exe vorgenommen wird. Weiter benötige ich eine Kennung mit den Rechten im Exchange Server und im Active Directory. Dafür privilegiere ich meine T3-Kennung temporär zum Superadmin:
Aktivierung von RBAC split permissions
Microsoft hat die Arbeitsschritte hier beschrieben: Configure Exchange Server for split permissions | Microsoft Learn.
Als T3-Admin starte ich den setup.exe-Befehl auf einem Domain Controller, nachdem ich dort das Exchange Server ISO eingebunden habe:
Die Aktion dauert wenige Minuten. Was hat sich im Active Directory verändert? Ich prüfe die ACL auf der Domain Partition. Doch hier hat sich im Vergleich zum Modell „shared permissions“ nichts verändert!
Und was hat sich im Exchange verändert? In der EAC-Seite gibt es die Option zur Anlage eines neuen Benutzers mit Mailbox noch:
Und ebenso funktioniert die Anlage über die PowerShell weiterhin:
Das bedeutet, es gibt wirklich nur eine Trennung mit den Berechtigungsgruppen und ein Exchange Organisationsadmin hat immer noch die vollen Rechte im Active Directory. Von den Exchange Computerkonten mal ganz abgesehen. Das ist nicht das, was ich mir hier vorstelle. Daher überspringe ich die weiteren Schritte in der Microsoft-Anleitung!
Aktivierung von Active Directory split permissions
Auch für diese Umstellung ist ein Aufruf der setup.exe erforderlich. Diese starte ich als T3-Admin (mit SuperAdmin-Rechten) auf meinem Domain Controller. Auch hier dauert der gesamte Vorgang nur wenige Minuten:
Ich prüfe wieder, welche Berechtigungen im AD greifen. Es sind einige Einträge in der ACL verschwunden. Vor allem fehlt nun der Passwort-Reset-Eintrag 🙂
Doch das möchte ich nun genau wissen. Ich versuche wieder, einen User mit Mailbox anzulegen. Die EAC scheitert:
Und ebenso geht es in der PowerShell nicht weiter, da die erforderlichen Parameter fehlen:
So habe ich mir das vorgestellt! 🙂 Zusätzlich scanne ich noch alle ACL meiner Domain Partition auf Berechtigungen vom Exchange. Das Ergebnis ist optimal:
Der Weg zurück zum Modell „shared permissions“ wird wieder über die setup.exe durchgeführt. Dem geübten Auge wird auffallen, dass der Befehl der gleiche ist, mit dem man zum Modell „RBAC split permissions“ wechselt:
Das ist auch nicht weiter verwunderlich, da der Unterschied zwischen diesen beiden Modellen alleine in den Rollen im Exchange liegt.
Mitgliedschaft in der Gruppe Administratoren
Ich präferiere das Modell „Active Directory Split Permissions“, da hier das Risiko eines Übergriffs zum AD nicht mehr möglich ist. Aber: Es gibt bei mir im AD noch einen Rest, der weiter die hohen Rechte an die Exchange Server delegiert:
Ich weiß noch, dass diese Gruppenmitgliedschaft bei einem CU-Setup oder dem Aufbau eines neuen Exchange Servers benötigt wird. Da das aber recht seltene Ereignisse sind, habe ich die Gruppenmitgliedschaft entfernt. Das Ergebnis aus der Perspektive des Hackers könnt ihr euch in meinem Artikel https://www.ws-its.de/ad-hacking-ueber-exchange-server/ ansehen.
Fazit
Der Eingriff zum richtigen Aufsplitten ist recht schnell erledigt und die Verbesserung der IT-Sicherheit ist enorm. Aber natürlich müssen vorher einige Prozesse angepasst werden: Bisher konnte der Exchange Admin neue Verteilergruppen oder Mailboxen mit den AD-Objekten direkt selber anlegen. Jetzt muss ein AD-Admin diese Objekte im AD anlegen und dann muss der Exchange Admin diese im Exchange enablen. Und bei der Entfernung gilt natürlich das Gleiche. Aber das sollte sich doch lösen lassen, oder?
Stay tuned!