Tim Beasley Senior Incident Response

In dieser Artikelserie haben wir untersucht, wie Berechtigungen in Gruppen wie „Backup Operators“ und „Account Operators“ ausgenutzt werden können. In diesem Beitrag werden wir uns damit befassen, welche Rolle Vertrauensbeziehungen bei den Risiken von Active-Directory-Gruppen spielen.

Kryptografische Operatoren gehören zu jenen Gruppen, die die meisten Verteidiger entweder völlig ignorieren oder gedanklich unter „wahrscheinlich nicht wichtig“ einordnen. Das ist ein großer Fehler.

Auf den ersten Blick wirkt „Cryptographic Operators“ nicht besonders einschüchternd. Microsoft beschreibt es ganz einfach: Mitglieder sind berechtigt, kryptografische Operationen durchzuführen.

  • Es handelt sich um eine integrierte lokale Gruppe im „Builtin “-Container.
  • Es enthält keine Standardmitglieder.
  • Es sind standardmäßig keine Benutzerrechte zugewiesen.

Genau diese unscheinbare Beschreibung ist der Grund, warum es übersehen wird.

Das Problem besteht nicht darin, dass „Cryptographic Operators“ wie „Domain Admins“ aussieht. Das tut es nicht. Das Problem ist vielmehr, dass es gefährlich nahe an den Systemen angesiedelt ist, die das Vertrauensmodell definieren.

Und unter Windows ist Vertrauen das A und O.


Was ist die Gruppe „Kryptografische Operatoren“?

Microsoft hat die integrierte Gruppe „Cryptographic Operators“ eingeführt, um die Rolle des Kryptobeauftragten abzubilden und bestimmte kryptografische Konfigurationsaufgaben in Windows-Umgebungen mithilfe der Cryptography API: Next Generation (CNG) zu steuern. In Szenarien im Zusammenhang mit Common Criteria oder FIPS können Mitglieder der Gruppe „Cryptographic Operators“ kryptografische Einstellungen konfigurieren, die normalen Benutzern nicht zur Verfügung stehen, darunter bestimmte IPsec-Kryptografieparameter.

Dies ist von Bedeutung, da das der Windows-Kryptografie zugrunde liegende Provider-Modell nicht nur eine rein theoretische Angelegenheit ist. Die kryptografischen Provider von Microsoft implementieren Algorithmen, generieren Schlüssel, stellen Speicherkapazitäten für Schlüssel bereit und authentifizieren Benutzer; sowohl die Active Directory-Zertifikatsdienste (AD CS) als auch die Zertifikatsausstellung stützen sich auf CryptoAPI und CNG.

Mit anderen Worten: Dies ist nicht „nur eine weitere seltsame vordefinierte Gruppe“.

Es befindet sich neben den Systemen, die mitbestimmen, wie Schlüssel erstellt werden, wo diese gespeichert werden und wie die Arbeitsabläufe bei der Authentifizierung, Signierung und Verschlüsselung funktionieren.

Und wenn diese Schwachstelle ausgenutzt wird, könnte das für Sie das Aus bedeuten .


Warum diese AD-Gruppe schneller gefährlich wird, als man denkt

Viele Menschen hören den Begriff „kryptografische Operationen“ und gehen davon aus, dass es sich dabei um eine eng gefasste, harmlose Aufgabe im Hintergrund handelt.

Das ist das falsche Denkmodell.

Wenn in Ihrer Umgebung AD CS, Smartcards, IPsec, Hardware-Sicherheitsmodule oder Software- und Hardware-Schlüsselspeicheranbieter zum Einsatz kommen, arbeiten Sie bereits in einem Umfeld, in dem die kryptografische Konfiguration direkt mit Entscheidungen hinsichtlich Identität, Authentifizierung und Vertrauenswürdigkeit verknüpft ist.

Semperis stuft „Cryptographic Operators“ in zahlreichen realen Kundenumgebungen bereits als bekannte Tier-0-Gruppe ein und nicht als unbedeutende Kuriosität aus der Vergangenheit.

Das sollte Verteidigern eine wichtige Erkenntnis vermitteln: Auch wenn die Standardbeschreibung harmlos erscheint, ist der Explosionsradius es nicht.


Realistische Bedenken der Verteidiger nach dem Kompromiss

Die Gefahr bei kryptografischen Operatoren hängt stärker vom jeweiligen Kontext ab als beispielsweise bei Backup-Operatoren.

„Backup-Operatoren“ schreien es geradezu heraus. „
“ – kryptografische Operatoren – flüstern es .

Das ist noch schlimmer.


1. Manipulation der Krypto- policy en in den Umgebungen, in denen diese tatsächlich zum Einsatz kommen

Die Microsoft-eigene Dokumentation und frühere Anleitungen bringen diese Gruppe mit der CNG-Konfiguration und den IPsec-Verschlüsselungseinstellungen im Common-Criteria-Modus in Verbindung, einschließlich der Möglichkeit, bestimmte Verschlüsselungsparameter im Hauptmodus festzulegen oder zu ändern, die von Standardbenutzern nicht geändert werden können.

Sollte ein Angreifer in einer abgesicherten Umgebung Zugriff auf eine Identität erlangen, die diese Art von Verantwortung trägt, sollten Sie davon ausgehen, dass er nun auf der Ebene des Vertrauenspolicy s (auch bekannt als Tier 0) agiert und nicht nur auf einem Endgerät.

Genau hier werden subtile Veränderungen zu strategischen Veränderungen.


2. Anbindung an PKI- und Schlüsselverwaltungs-Workflows

Schlüsselspeicheranbieter (KSPs) sind für die Speicherung und den Abruf kryptografischer Schlüssel zuständig. Bei der Installation von AD CS wählen Administratoren ausdrücklich einen Anbieter für die Verwaltung des privaten Schlüssels der Zertifizierungsstelle aus. (…oder sie klicken sich während der Installation einfach mit „Weiter“ zum Ziel…)

Gleichzeitig bildet das Krypto-Anbieter-Modell von Microsoft die Grundlage für die Zertifikatsregistrierung und den AD CS-Betrieb im weiteren Sinne.

Auch wenn die Mitgliedschaft in der Gruppe „Cryptographic Operators“ nicht automatisch den sofortigen Zugriff auf jeden privaten Schlüssel bedeutet, sollten Sie dennoch unbedingt jede Umgebung genau unter die Lupe nehmen, in der diese Gruppe vertreten ist, da diese Rolle in unmittelbarer Nähe zu den Systemen angesiedelt ist, die Vertrauensanker und Signaturschlüssel verwalten.

Das ist kein Bereich, in dem „wahrscheinlich in Ordnung“ eine akzeptable Sicherheitsentscheidung darstellt.


3. Verborgene Persistenz und geringe Sichtbarkeit

Microsoft dokumentiert, dass die Gruppe „Cryptographic Operators“ keine Standardmitglieder hat und nicht durch „AdminSDHolder“ geschützt ist – und weist gleichzeitig darauf hin, dass die Verwaltung dieser Gruppe nicht an Administratoren delegiert werden sollte, die keine Dienstadministratoren sind.

Diese Kombination dürfte Ihnen Unbehagen bereiten.

Das bedeutet, dass es sich hierbei nicht um eine der offensichtlichen geschützten Gruppen handelt, auf die sich Befürworter besonders konzentrieren, dennoch wird sie als so sensibel angesehen, dass Microsoft ausdrücklich darauf hinweist: „Übertragen Sie deren Verwaltung nicht an Administratoren mit geringerem Vertrauensniveau.“

Das macht es zu einem perfekten toten Winkel.


4. Die Einsatzflächen für private Schlüssel werden von den Verantwortlichen selten gründlich überprüft

Bei softwaregestützten Anbietern speichert Windows private Schlüssel auf Systemebene üblicherweise unter Pfaden wie beispielsweise C:\ProgramData\Microsoft\Crypto\Keys für CNG-KSPs und C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys für CryptoAPI-CSPs.

Ich behaupte nicht , dass die Mitgliedschaft bei „Cryptographic Operators“ allein einen uneingeschränkten Zugriff auf diese Dateien gewährt.

Ich möchte damit sagen : Wenn Sie es mit Konten zu tun haben, denen der Betrieb im Zusammenhang mit Krypto-Konfigurationen, Anbietern, Zertifikatsdiensten und Schlüssel-Workflows anvertraut ist, dann sind genau diese Bereiche diejenigen, die Sicherheitsverantwortliche auf Fehler in den Zugriffskontrolllisten (ACL), den Missbrauch von Anbietern und betriebliche Missbräuche überprüfen sollten.


Was Verteidiger im Auge behalten sollten

Beginnen Sie mit einer einfachen Frage: Warum ist überhaupt jemand in dieser Gruppe?

Microsoft gibt an, dass die Klasse „Cryptographic Operators“ keine Standardelemente enthält. Sollte sie also mit Elementen gefüllt sein, sollte dies eine sofortige Überprüfung auslösen.

Achten Sie von dort aus auf Folgendes:

  • Hinzufügungen und Löschungen von Mitgliedern. Die Gruppe „Kryptografische Operatoren“ sollte in der Regel leer bleiben, und jede Änderung ist aus betrieblicher Sicht von Bedeutung.
  • Änderungen an IPsec oder kryptografischen policy en in Umgebungen, in denen Common-Criteria- oder FIPS-bezogene Kontrollmaßnahmen zum Einsatz kommen, insbesondere wenn diese Änderungen von Personen vorgenommen werden, die nicht Teil eines streng kontrollierten Krypto-Admin-Workflows sind.
  • Aktivitäten auf CA-Servern, Registrierungsservern, in der Smartcard-Infrastruktur sowie in Systemen, die HSM oder Software-KSP/CSP-Integrationen nutzen; diese Arbeitsabläufe stützen sich auf denselben Anbieterstack, zu dessen Steuerung diese Gruppe eingerichtet wurde.
  • Überprüfung der ACLs und Zugriffsrechte an softwaregestützten Schlüsselstandorten wie MachineKeys und Crypto\Keys, da Sicherheitsverantwortliche häufig die Ausstellung von Zertifikaten überwachen, dabei jedoch die zugrunde liegende Schlüsselspeicherebene vernachlässigen.

Wie geht man mit Risiken bei kryptografischen Operatoren um?

Die bevorzugten Empfehlungen entsprechen denen, die ich bereits für andere AD-Gruppen ausgesprochen habe:

Lassen Sie die Gruppe leer. Und überwachen Sie alle Änderungen an der Gruppenzugehörigkeit.

Wenn Microsoft angibt, dass die Gruppe keine Standardmitglieder hat, und Ihre eigene Tier-0-Logik sie bereits als vertraulich einstuft, sollten die Anforderungen sehr hoch sein, bevor jemand dieser Gruppe zugeordnet wird.

Wenn Sie der Meinung sind, dass Sie dies benötigen, belegen Sie dies bitte.
Konkret:

  • Dokumentieren Sie den genauen Arbeitsablauf, für den eine Mitgliedschaft erforderlich ist.
  • Ermitteln Sie die genauen Server, Anbieter, HSM-Integrationen, Smartcard-Dienste oder IPsec-Richtlinien, die davon betroffen sind.
  • Behandeln Sie das Konto als Tier 0 oder als an Tier 0 angrenzend.
  • Schränken Sie ein, wo sich das System anmelden darf.
  • Überprüfen Sie die CA und die damit verbundene Anbieter-Konfiguration.
  • Überwachen Sie die Gruppe so, wie Sie es bei jeder anderen vertrauensbildenden Verwaltungsebene tun würden.

Wenn dem Konto die Verantwortung für den Betrieb der Systeme übertragen wird, die das kryptografische Vertrauen definieren, dann ist es per Definition in einem Bereich der Umgebung tätig, in dem ein einziger Fehler zum Problem für alle werden kann.


Rücken Sie Ihre Identitäten auf der Vertrauens-Ebene ins Rampenlicht

„Kryptografische Operatoren“ sind gerade deshalb gefährlich, weil sie nicht gefährlich aussehen .

  • Die Standardbeschreibung ist kurz.
  • Das Feld „Mitglieder“ ist häufig leer.
  • Sein Name löst nicht dieselben Bedenken aus wie die Gruppen „Admins“ oder „Operators“, die über weitreichendere Berechtigungen verfügen.

Microsoft verknüpft dies jedoch mit der kryptografischen Konfigurationsinstanz, dem Windows-Anbieter-Modell, das hinter Schlüsseln und Zertifikaten steht, sowie mit bestimmten IPsec- und CNG-Szenarien, die ein hohes Maß an Vertrauen erfordern.

Und die Auswertungsergebnisse von Semperis behandeln diese Gruppe in realen Umgebungen bereits als bekannte Tier-0-Gruppe.

Das bedeutet, dass erfahrene Sicherheitsbeauftragte aufhören sollten, kryptografische Operatoren als harmloses Hintergrundrauschen zu betrachten.

Wenn eine Identität die kryptografische Vertrauensebene beeinflussen kann, handelt es sich nicht um eine Identität mit geringen Berechtigungen. Es handelt sich um eine Identität der Vertrauensebene.

Und Identitäten auf der Vertrauens-Ebene verdienen eine Betrachtung auf Tier-0-Ebene.

Bis zum nächsten Mal …verfolgen Sie die Diskussion über kryptografische Operatoren auf LinkedIn.

Und wenn Sie fachkundige Unterstützung benötigen, um Schwachstellen in Ihren AD-Sicherheitsgruppen zu identifizieren und zu beheben, wenden Sie sich an einen Active Directory-Sicherheitsbewertung. Wir sind für Sie da.


Verwandte Ressourcen