Français - Ht Cloud
HackTricks Training Twitter Linkedin Sponsor

AWS - KMS Enum

Apprenez le piratage AWS de zéro à héros avec htARTE (Expert Red Team AWS de HackTricks)!

Autres façons de soutenir HackTricks :

KMS - Service de gestion des clés

Le service de gestion des clés AWS (AWS KMS) est présenté comme un service géré, simplifiant le processus pour les utilisateurs de créer et gérer des clés maîtresses clients (CMK). Ces CMK sont essentiels dans le chiffrement des données utilisateur. Une caractéristique notable d'AWS KMS est que les CMK sont principalement sécurisées par des modules matériels de sécurité (HSM), renforçant la protection des clés de chiffrement.

KMS utilise la cryptographie symétrique. Cela est utilisé pour chiffrer des informations au repos (par exemple, à l'intérieur d'un S3). Si vous devez chiffrer des informations en transit, vous devez utiliser quelque chose comme TLS.

KMS est un service spécifique à une région.

Les administrateurs d'Amazon n'ont pas accès à vos clés. Ils ne peuvent pas récupérer vos clés et ils ne vous aident pas à chiffrer vos clés. AWS administre simplement le système d'exploitation et l'application sous-jacente, il nous appartient d'administrer nos clés de chiffrement et de gérer comment ces clés sont utilisées.

Clés maîtresses clients (CMK) : Peuvent chiffrer des données jusqu'à 4 Ko. Elles sont généralement utilisées pour créer, chiffrer et déchiffrer les DEK (clés de chiffrement de données). Ensuite, les DEK sont utilisées pour chiffrer les données.

Une clé maîtresse client (CMK) est une représentation logique d'une clé maîtresse dans AWS KMS. En plus des identifiants de la clé maîtresse et d'autres métadonnées, y compris sa date de création, sa description et son état de clé, une CMK contient le matériel de clé utilisé pour chiffrer et déchiffrer des données. Lorsque vous créez une CMK, par défaut, AWS KMS génère le matériel de clé pour cette CMK. Cependant, vous pouvez choisir de créer une CMK sans matériel de clé, puis importer votre propre matériel de clé dans cette CMK.

Il existe 2 types de clés maîtresses :

  • CMK gérées par AWS : Utilisées par d'autres services pour chiffrer des données. Elles sont utilisées par le service qui les a créées dans une région. Elles sont créées la première fois que vous mettez en œuvre le chiffrement dans ce service. Elles sont renouvelées tous les 3 ans et il n'est pas possible de les modifier.

  • CMK gérées par le client : Flexibilité, rotation, accès configurable et politique de clé. Activation et désactivation des clés.

Chiffrement d'enveloppe dans le contexte du Service de gestion des clés (KMS) : Système hiérarchique à deux niveaux pour chiffrer des données avec une clé de données puis chiffrer la clé de données avec une clé maîtresse.

Politiques de clé

Ces politiques définissent qui peut utiliser et accéder à une clé dans KMS.

Par défaut :

  • Il donne à l'AWS account propriétaire de la clé KMS un accès complet à la clé KMS.

Contrairement aux autres politiques de ressources AWS, une politique de clé KMS ne donne pas automatiquement la permission au compte ou à l'un de ses utilisateurs. Pour donner la permission aux administrateurs du compte, la politique de clé doit inclure une déclaration explicite qui fournit cette permission, comme celle-ci.

  • Sans autoriser le compte ("AWS": "arn:aws:iam::111122223333:root"), les autorisations IAM ne fonctionneront pas.

  • Il autorise le compte à utiliser des politiques IAM pour permettre l'accès à la clé KMS, en plus de la politique de clé.

Sans cette permission, les politiques IAM qui autorisent l'accès à la clé sont inefficaces, bien que les politiques IAM qui refusent l'accès à la clé restent efficaces.

  • Il réduit le risque que la clé devienne ingérable en donnant la permission de contrôle d'accès aux administrateurs du compte, y compris l'utilisateur racine du compte, qui ne peut pas être supprimé.

Exemple de politique par défaut :

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

Si le compte est autorisé ("arn:aws:iam::111122223333:root") un principal du compte aura toujours besoin des autorisations IAM pour utiliser la clé KMS. Cependant, si l'ARN d'un rôle par exemple est spécifiquement autorisé dans la Politique de clé, ce rôle n'aura pas besoin des autorisations IAM.

Détails de la politique

Propriétés d'une politique :

  • Document basé sur JSON

  • Ressource --> Ressources affectées (peut être "*")

  • Action --> kms:Encrypt, kms:Decrypt, kms:CreateGrant ... (autorisations)

  • Effet --> Autoriser/Refuser

  • Principal --> arn affecté

  • Conditions (optionnel) --> Condition pour accorder les autorisations

Délégations :

  • Autoriser à déléguer vos autorisations à un autre principal AWS au sein de votre compte AWS. Vous devez les créer en utilisant les APIs AWS KMS. Il est possible d'indiquer l'identifiant CMK, le principal bénéficiaire et le niveau d'opération requis (Decrypt, Encrypt, GenerateDataKey...)

  • Après la création de la délégation, un jeton de délégation et un ID de délégation sont émis

Accès :

  • Via la politique de clé -- Si elle existe, elle a priorité sur la politique IAM

  • Via la politique IAM

  • Via les délégations

Administrateurs de clés

Administrateur de clés par défaut :

  • Ont accès pour gérer KMS mais pas pour chiffrer ou déchiffrer des données

  • Seuls les utilisateurs et rôles IAM peuvent être ajoutés à la liste des administrateurs de clés (pas les groupes)

  • Si une CMK externe est utilisée, les administrateurs de clés ont la permission d'importer du matériel de clé

Rotation des CMKs

  • Plus la même clé reste en place longtemps, plus de données sont chiffrées avec cette clé, et si cette clé est compromise, plus la zone de données à risque est large. En plus de cela, plus la clé est active, plus la probabilité qu'elle soit compromise augmente.

  • KMS fait tourner les clés clients tous les 365 jours (ou vous pouvez effectuer le processus manuellement quand vous le souhaitez) et les clés gérées par AWS tous les 3 ans et ce délai ne peut pas être modifié.

  • Les anciennes clés sont conservées pour déchiffrer les données qui ont été chiffrées avant la rotation

  • En cas de compromission, faire tourner la clé ne supprimera pas la menace car il sera possible de déchiffrer toutes les données chiffrées avec la clé compromise. Cependant, les nouvelles données seront chiffrées avec la nouvelle clé.

  • Si la CMK est dans un état de désactivé ou de suppression en attente, KMS ne fera pas tourner une clé jusqu'à ce que la CMK soit réactivée ou que la suppression soit annulée.

Rotation manuelle

  • Une nouvelle CMK doit être créée, ensuite, un nouvel identifiant de CMK est créé, donc vous devrez mettre à jour toute application pour référencer le nouvel identifiant de CMK.

  • Pour rendre ce processus plus facile, vous pouvez utiliser des alias pour faire référence à un identifiant de clé et ensuite simplement mettre à jour la clé à laquelle l'alias fait référence.

  • Vous devez conserver les anciennes clés pour déchiffrer les anciens fichiers chiffrés avec elles.

Vous pouvez importer des clés depuis votre infrastructure de clés sur site.

Autres informations pertinentes sur KMS

KMS est tarifé par le nombre de demandes de chiffrement/déchiffrement reçues de tous les services par mois.

KMS a une intégration complète d'audit et de conformité avec CloudTrail ; c'est là que vous pouvez auditer toutes les modifications effectuées sur KMS.

Avec la politique KMS, vous pouvez faire ce qui suit :

  • Limiter qui peut créer des clés de données et quels services ont accès pour utiliser ces clés

  • Limiter l'accès des systèmes à chiffrer uniquement, déchiffrer uniquement ou les deux

  • Définir pour permettre aux systèmes d'accéder aux clés à travers les régions (bien que ce ne soit pas recommandé car une défaillance dans la région hébergeant KMS affectera la disponibilité des systèmes dans d'autres régions).

Vous ne pouvez pas synchroniser ou déplacer/copier des clés entre les régions ; vous pouvez seulement définir des règles pour autoriser l'accès entre les régions.

Énumération

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

Élévation de privilèges

pageAWS - KMS Privesc

Post-exploitation

pageAWS - KMS Post Exploitation

Persistance

pageAWS - KMS Persistence

Références

Apprenez le piratage AWS de zéro à héros avec htARTE (Expert en équipe rouge AWS de HackTricks)!

Autres façons de soutenir HackTricks :

PrécédentAWS - IAM, Identity Center & SSO EnumSuivantAWS - Lambda Enum

Dernière mise à jour