Was Hänschen nicht lernt,…

Aus sicherheitstechnischer Perspektive lohnt es sich, speziell bei Hybrid-Szenarien, das On-Prem Active Directory vor einer Verbindung mit einem Cloud-Directory etwas genauer zu analysieren.

Start…

…Express Setup, next, next, configure…fertig. So oder ähnlich schnell lässt sich z.B. Microsofts Active Directory On-Prem mit dem hauseigenen Cloud Pendant Azure Active Directory via Azure AD-Connect verbinden. Kaum sind die Active Directory-Benutzer und -Gruppen mit dem Azure Active Directory synchronisiert, schon lassen sie sich beispielsweise zur Berechtigungsvergabe für Cloud-Dienste und -Applikationen nutzen.
Zum Schutz von Cloud-Accounts stehen viele intelligente, effektive und relativ leicht zu implementierende Sicherheitsmechanismen zur Verfügung. Ein ähnlich hohes Sicherheitsniveau für On-Prem Active Directory-Accounts zu erreichen, kann leicht das IT-Budget überstrapazieren oder lässt sich aufgrund des jeweiligen Designs gar nicht implementieren.
Aus sicherheitstechnischer Perspektive lohnt es sich, für solche Hybrid-Szenarien – oft in Verbindung mit Federation-Services – das On-Prem Active Directory bereits vor der Installation genauer zu analysieren.

Zuerst Design-Fragen klären…

Bevor es mit den On-Prem-Benutzer und -Gruppen in die Cloud geht, können grundsätzliche Design- und Sicherheitsfragen und deren Klärung hilfreich sein. Beispielsweise:

  • Sind die Security Best Practices von Microsoft für das Active Directory, wie z.B. Tiering-Modelle, Rollen-Trennung und -Konzepte, Privileged Access Workstations, effektives Monitoring, Just in Time Administration, Zonenkonzepte oder gar ein Privileged Access Forest implementiert?
  • Welche Privilegien sind den Active Directory-Administratoren für alltägliche Aufgaben zugewiesen? Wird das Least Privilege-Konzept angewendet oder arbeiten die Administratoren unnötigerweise hoch-privilegiert oder sind sogar permanent Mitglied der Domain oder Enterprise Admin-Gruppe?
  • Entspricht die Konfiguration der Federation-Services den allgemein gültigen Sicherheitsrichtlinien?

Diese Aufzählung lässt sich beliebig erweitern und soll auf die enorme Komplexität der Thematik hinweisen.

Die Umsetzung der Security Best Practices im Kontext von Active Directory erweisen sich je nach Umgebung als enorm komplex und aufwändig, weshalb eine eingehende Risikoanalyse sinnvoll ist.

…oder lieber gleich los?

Um die Wichtigkeit der eben gestellten Fragen hervorzuheben, soll die Installation von Azure AD-Connect auf einem Standard Domainmember-Server ohne speziellen Sicherheitsrichtlinien als Beispiel dienen.

Der Installations-Assistent von Azure AD-Connect fordert unter anderem zur Eingabe von Enterprise Admin- und Global Admin-Credentials auf, wobei es sich um die beiden höchst-privilegierten Account-Typen im Active Directory respektive Azure Active Directory handelt. Wird nicht explizit die Option für ein Custom-Setup gewählt und dabei ein vordefinierter, entsprechend minimal privilegierter AD DS Connector-Account genutzt, erstellt die Setup-Routine automatisch einen MSOL-Account im Active Directory. Diesem automatisch erstellten Account wird ein erweitertes Recht auf Ebene der Active Directory Domain zugeteilt: «Replicate Directory Changes All». Dieses Recht wird eigentlich nur für die Funktion «Password Hash Sync» benötigt, welche natürlich nicht in jedem Fall genutzt wird. Die technische Dokumentation von Microsoft lässt erahnen, um was für ein erweitertes Recht es sich dabei handelt: «Control access right that allows the replication of secret domain data». Microsoft versucht diesem Umstand seit der Version 1.1.654.0 von Azure AD-Connect gerecht zu werden und reduziert die Angriffsfläche ein wenig.
Wer sich jedoch mit Mimikatz und ähnlichen Pentest-Werkzeugen auskennt, weiss genau, was sich mit diesem erweiterten Recht im Active Directory bewerkstelligen lässt. Ein Angreifer oder auch ein etwas fehlgeleiteter Administrator kann damit innert kürzester Zeit das On-Prem Active Directory unter seine Kontrolle bringen und gegebenenfalls enormen Schaden anrichten.

Und was hat das mit der Cloud zu tun?

Können hoch-privilegierte Accounts im Azure Active Directory nicht in vielfacher Art und Weise geschützt werden? Ja, können sie. Jedoch besteht eine Verbindung zum On-Prem Active Directory und Accounts werden von dort importiert oder auch synchronisiert. Wer nun das On-Prem Active Directory kontrolliert, wird einen Weg finden, auch das Azure Active Directory zu kontrollieren oder zumindest stark zu beeinflussen. Dies trifft insbesondere für Installationen mit Federation-Services zu.

Was passieren kann…

Im Video https://tube.switch.ch/videos/5026ac26 wird der Sachverhalt genauer erläutert. Dabei greift ein Angreifer (Support Administrator) einzig mit lokalen Administratoren-Privilegien zuerst auf den geschützten Speicherbereich des Azure AD-Connect Servers zu, um via MSOL-Account spezifische Active Directory Secrets (Passwort-Hash des krbtgt-Accounts) auszulesen. Damit erstellt er ein sogenanntes Kerberos Golden-Ticket, womit praktisch jeder Zugriff im Active Directory möglich wird. Mit dem Passwort-Reset eines synchronisierten Active Directory- / Azure Active Directory-Accounts (Global Administrator), kann der Angreifer dann sämtliche Azure-Ressourcen kontrollieren.

Microsoft ist sich der Risiken im Zusammenhang mit Active Directory bewusst und bietet neben zahlreichen technischen Dokumenten auch ein vor Ort oder Online Risk Assessment Programm zu diesem Thema an (RaaS for Active Directory).

Zurück auf Feld eins…

Nochmals zu den Design-Fragen… Es kann sich durchaus lohnen, vor der Installation von Azure AD-Connect das On-Prem Active Directory sicherheitstechnisch auf den aktuellen Stand zu bringen oder aber allfällige Risiken bewusst zu akzeptieren. Andernfalls besteht die Wahrscheinlichkeit, dass sich das Cloud-Directory via On-Prem-Angriff übernehmen lässt und die Sicherheitsmassnahmen für hochprivilegierte Cloud-Accounts vergeblich implementiert wurden.

Quellen und weiterführende Links (online, 12.12.2018):

Active Directory Tiering / Privileged Access Management:
https://docs.microsoft.com/en-us/windows-server/identity/securing-privileged-access/securing-privileged-access-reference-material
https://cloudblogs.microsoft.com/microsoftsecure/2018/11/29/secure-your-privileged-administrative-accounts-with-a-phased-roadmap/

DS-Replication extended right:
https://docs.microsoft.com/en-us/windows/desktop/ADSchema/r-ds-replication-get-changes-all

Securing Azure AD-Connect:
https://docs.microsoft.com/en-gb/security-updates/securityadvisories/2017/4056318

Pentest-Tool:
https://github.com/gentilkiwi/mimikatz

Kerberos Golden Ticket Attack & Mitigation:
https://mva.microsoft.com/en-us/training-courses/how-to-avoid-golden-ticket-attacks-12134?l=4NoyuNYUB_604300474

Golden SAML Attack
https://www.cyberark.com/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-cloud-apps/

Securing privileged access for hybrid and cloud deployments in Azure AD:
https://docs.microsoft.com/en-us/azure/active-directory/users-groups-roles/directory-admin-roles-secure

Beitrag teilen

deisenlo

Daniel Eisenlohr ist Security-Engineer bei HSLU IT-Services und bloggt aus dem Unterricht des CAS Cloud and Platform Manager

Alle Beiträge ansehen von deisenlo →