AWS - KMS Enum

Support HackTricks

KMS - Schlüsselmanagementdienst

AWS Schlüsselmanagementdienst (AWS KMS) wird als verwalteter Dienst präsentiert, der den Prozess für Benutzer vereinfacht, Kundenmasterkeys (CMKs) zu erstellen und zu verwalten. Diese CMKs sind integraler Bestandteil der Verschlüsselung von Benutzerdaten. Ein bemerkenswertes Merkmal von AWS KMS ist, dass CMKs überwiegend durch Hardware-Sicherheitsmodule (HSMs) gesichert sind, was den Schutz der Verschlüsselungsschlüssel verbessert.

KMS verwendet symmetrische Kryptographie. Dies wird verwendet, um Informationen im Ruhezustand zu verschlüsseln (zum Beispiel in einem S3). Wenn Sie Informationen während der Übertragung verschlüsseln müssen, müssen Sie etwas wie TLS verwenden.

KMS ist ein regionsspezifischer Dienst.

Administratoren bei Amazon haben keinen Zugriff auf Ihre Schlüssel. Sie können Ihre Schlüssel nicht wiederherstellen und helfen Ihnen nicht bei der Verschlüsselung Ihrer Schlüssel. AWS verwaltet einfach das Betriebssystem und die zugrunde liegende Anwendung; es liegt an uns, unsere Verschlüsselungsschlüssel zu verwalten und zu steuern, wie diese Schlüssel verwendet werden.

Kundenmasterkeys (CMK): Können Daten mit einer Größe von bis zu 4 KB verschlüsseln. Sie werden typischerweise verwendet, um die DEKs (Datenverschlüsselungsschlüssel) zu erstellen, zu verschlüsseln und zu entschlüsseln. Dann werden die DEKs verwendet, um die Daten zu verschlüsseln.

Ein Kundenmasterkey (CMK) ist eine logische Darstellung eines Masterkeys in AWS KMS. Neben den Identifikatoren des Masterkeys und anderen Metadaten, einschließlich seines Erstellungsdatums, seiner Beschreibung und seines Schlüsselsstatus, enthält ein CMK das Schlüsselmateriel, das zur Verschlüsselung und Entschlüsselung von Daten verwendet wird. Wenn Sie ein CMK erstellen, generiert AWS KMS standardmäßig das Schlüsselmateriel für dieses CMK. Sie können jedoch wählen, ein CMK ohne Schlüsselmateriel zu erstellen und dann Ihr eigenes Schlüsselmateriel in dieses CMK zu importieren.

Es gibt 2 Arten von Masterkeys:

  • AWS verwaltete CMKs: Werden von anderen Diensten zur Verschlüsselung von Daten verwendet. Es wird von dem Dienst verwendet, der es in einer Region erstellt hat. Sie werden beim ersten Mal erstellt, wenn Sie die Verschlüsselung in diesem Dienst implementieren. Wechselt alle 3 Jahre und es ist nicht möglich, es zu ändern.

  • Kundenverwaltete CMKs: Flexibilität, Rotation, konfigurierbarer Zugriff und Schlüsselrichtlinie. Aktivieren und Deaktivieren von Schlüsseln.

Umhüllende Verschlüsselung im Kontext des Schlüsselmanagementdienstes (KMS): Zweistufiges Hierarchiesystem zur Verschlüsselung von Daten mit einem Datenschlüssel und dann zur Verschlüsselung des Datenschlüssels mit dem Masterkey.

Schlüsselrichtlinien

Diese definieren wer einen Schlüssel in KMS verwenden und darauf zugreifen kann.

Standardmäßig:

  • Es gewährt dem AWS-Konto, das den KMS-Schlüssel besitzt, vollen Zugriff auf den KMS-Schlüssel.

Im Gegensatz zu anderen AWS-Ressourcenrichtlinien gewährt eine AWS KMS-Schlüsselrichtlinie nicht automatisch Berechtigungen für das Konto oder eines seiner Benutzer. Um den Kontoadministratoren Berechtigungen zu gewähren, muss die Schlüsselrichtlinie eine ausdrückliche Erklärung enthalten, die diese Berechtigung bereitstellt, wie diese hier.

  • Ohne das Erlauben des Kontos ("AWS": "arn:aws:iam::111122223333:root") funktionieren IAM-Berechtigungen nicht.

  • Es erlaubt dem Konto, IAM-Richtlinien zu verwenden, um den Zugriff auf den KMS-Schlüssel zusätzlich zur Schlüsselrichtlinie zu ermöglichen.

Ohne diese Berechtigung sind IAM-Richtlinien, die den Zugriff auf den Schlüssel erlauben, ineffektiv, obwohl IAM-Richtlinien, die den Zugriff auf den Schlüssel verweigern, weiterhin wirksam sind.

  • Es verringert das Risiko, dass der Schlüssel unverwaltbar wird, indem es den Kontoadministratoren, einschließlich des Kontowurzelbenutzers, der nicht gelöscht werden kann, Berechtigungen zur Zugriffskontrolle gewährt.

Beispiel für eine Standardrichtlinie:

{
"Sid": "Enable IAM policies",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:root"
},
"Action": "kms:*",
"Resource": "*"
}

Wenn das Konto erlaubt ist ("arn:aws:iam::111122223333:root"), benötigt ein Principal aus dem Konto trotzdem IAM-Berechtigungen, um den KMS-Schlüssel zu verwenden. Wenn jedoch die ARN einer Rolle beispielsweise im Schlüsselrichtlinie speziell erlaubt ist, benötigt diese Rolle keine IAM-Berechtigungen.

Richtliniendetails

Eigenschaften einer Richtlinie:

  • JSON-basiertes Dokument

  • Ressource --> Betroffene Ressourcen (kann "*")

  • Aktion --> kms:Encrypt, kms:Decrypt, kms:CreateGrant ... (Berechtigungen)

  • Effekt --> Erlauben/Verweigern

  • Principal --> betroffene arn

  • Bedingungen (optional) --> Bedingung zur Erteilung der Berechtigungen

Grants:

  • Erlaubt es, Ihre Berechtigungen an einen anderen AWS-Principal innerhalb Ihres AWS-Kontos zu delegieren. Sie müssen sie mit den AWS KMS-APIs erstellen. Es kann der CMK-Identifikator, der berechtigte Principal und das erforderliche Niveau der Operation (Decrypt, Encrypt, GenerateDataKey...) angegeben werden.

  • Nachdem das Grant erstellt wurde, werden ein GrantToken und eine GrantID ausgegeben.

Zugriff:

  • Über Schlüsselrichtlinie -- Wenn diese existiert, hat sie Vorrang vor der IAM-Richtlinie

  • Über IAM-Richtlinie

  • Über Grants

Schlüsseladministratoren

Schlüsseladministratoren standardmäßig:

  • Haben Zugriff zur Verwaltung von KMS, aber nicht zum Verschlüsseln oder Entschlüsseln von Daten

  • Nur IAM-Benutzer und -Rollen können zur Liste der Schlüsseladministratoren hinzugefügt werden (keine Gruppen)

  • Wenn eine externe CMK verwendet wird, haben Schlüsseladministratoren die Berechtigung, Schlüsselmaterial zu importieren

Rotation von CMKs

  • Je länger derselbe Schlüssel an Ort und Stelle bleibt, desto mehr Daten werden mit diesem Schlüssel verschlüsselt, und wenn dieser Schlüssel kompromittiert wird, desto größer ist der Gefahrenbereich der Daten. Darüber hinaus steigt die Wahrscheinlichkeit, dass der Schlüssel kompromittiert wird, je länger der Schlüssel aktiv ist.

  • KMS rotiert Kundenschlüssel alle 365 Tage (oder Sie können den Prozess manuell durchführen, wann immer Sie möchten) und Schlüssel, die von AWS verwaltet werden, alle 3 Jahre, und diese Zeit kann nicht geändert werden.

  • Ältere Schlüssel werden aufbewahrt, um Daten zu entschlüsseln, die vor der Rotation verschlüsselt wurden.

  • Bei einem Bruch wird die Rotation des Schlüssels die Bedrohung nicht beseitigen, da es möglich sein wird, alle Daten zu entschlüsseln, die mit dem kompromittierten Schlüssel verschlüsselt wurden. Allerdings werden neue Daten mit dem neuen Schlüssel verschlüsselt.

  • Wenn die CMK im Zustand deaktiviert oder in der Löschung ausstehend ist, wird KMS keine Schlüsselrotation durchführen, bis die CMK wieder aktiviert oder die Löschung abgebrochen wird.

Manuelle Rotation

  • Eine neue CMK muss erstellt werden, dann wird eine neue CMK-ID erstellt, sodass Sie alle Anwendungen aktualisieren müssen, um die neue CMK-ID zu referenzieren.

  • Um diesen Prozess zu erleichtern, können Sie Aliase verwenden, um auf eine Schlüssel-ID zu verweisen und dann einfach den Schlüssel aktualisieren, auf den der Alias verweist.

  • Sie müssen alte Schlüssel aufbewahren, um alte Dateien zu entschlüsseln, die damit verschlüsselt wurden.

Sie können Schlüssel aus Ihrer lokalen Schlüssel-Infrastruktur importieren.

Weitere relevante KMS-Informationen

KMS wird pro Anzahl der von allen Diensten pro Monat empfangenen Verschlüsselungs-/Entschlüsselungsanfragen berechnet.

KMS hat eine vollständige Audit- und Compliance-Integration mit CloudTrail; hier können Sie alle Änderungen, die an KMS vorgenommen wurden, überprüfen.

Mit der KMS-Richtlinie können Sie Folgendes tun:

  • Einschränken, wer Datenkeys erstellen kann und welche Dienste Zugriff auf diese Schlüssel haben

  • Den Zugriff von Systemen auf nur Verschlüsselung, nur Entschlüsselung oder beides einschränken

  • Definieren, um Systemen den Zugriff auf Schlüssel über Regionen hinweg zu ermöglichen (obwohl dies nicht empfohlen wird, da ein Ausfall in der Region, die KMS hostet, die Verfügbarkeit von Systemen in anderen Regionen beeinträchtigen wird).

Sie können Schlüssel nicht über Regionen hinweg synchronisieren oder verschieben/kopieren; Sie können nur Regeln definieren, um den Zugriff über Regionen hinweg zu ermöglichen.

Enumeration

aws kms list-keys
aws kms list-key-policies --key-id <id>
aws kms list-grants --key-id <id>
aws kms describe-key --key-id <id>
aws kms get-key-policy --key-id <id> --policy-name <name> # Default policy name is "default"
aws kms describe-custom-key-stores

Privesc

Post Exploitation

Persistence

References

Support HackTricks

Last updated