GCP - KMS Enum

Tip

Aprenda e pratique AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Aprenda e pratique GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Aprenda e pratique Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Apoie o HackTricks

KMS

The Cloud Key Management Service serve como um armazenamento seguro para chaves criptográficas, que são essenciais para operações como encriptar e descriptografar dados sensíveis. Essas chaves são organizadas dentro de key rings, permitindo um gerenciamento estruturado. Além disso, o controle de acesso pode ser configurado minuciosamente, seja no nível da chave individual ou de todo o key ring, garantindo que as permissões estejam precisamente alinhadas com os requisitos de segurança.

KMS key rings são, por padrão, criados como global, o que significa que as chaves dentro desse key ring são acessíveis de qualquer região. No entanto, é possível criar key rings em regiões específicas.

Key Protection Level

  • Software keys: Software keys são criadas e gerenciadas pelo KMS inteiramente em software. Essas chaves não são protegidas por nenhum módulo de segurança de hardware (HSM) e podem ser usadas para testes e desenvolvimento. Software keys não são recomendadas para produção porque oferecem baixa segurança e são suscetíveis a ataques.
  • Cloud-hosted keys: Cloud-hosted keys são criadas e gerenciadas pelo KMS na nuvem usando uma infraestrutura altamente disponível e confiável. Essas chaves são protegidas por HSMs, mas os HSMs não são dedicados a um cliente específico. Cloud-hosted keys são adequadas para a maioria dos casos de uso em produção.
  • External keys: External keys são criadas e gerenciadas fora do KMS, e são importadas para o KMS para uso em operações criptográficas. External keys podem ser armazenadas em um módulo de segurança de hardware (HSM) ou em uma biblioteca de software, dependendo da preferência do cliente.

Key Purposes

  • Symmetric encryption/decryption: Usado para encriptar e descriptografar dados usando uma única chave para ambas as operações. Chaves simétricas são rápidas e eficientes para encriptar e descriptografar grandes volumes de dados.
  • Supported: cryptoKeys.encrypt, cryptoKeys.decrypt
  • Asymmetric Signing: Usado para comunicação segura entre duas partes sem compartilhar a chave. Chaves assimétricas vêm em par, consistindo de uma chave pública e uma chave privada. A chave pública é compartilhada com outros, enquanto a chave privada é mantida em segredo.
  • Supported: cryptoKeyVersions.asymmetricSign, cryptoKeyVersions.getPublicKey
  • Asymmetric Decryption: Usado para verificar a autenticidade de uma mensagem ou dado. Uma assinatura digital é criada usando uma chave privada e pode ser verificada usando a chave pública correspondente.
  • Supported: cryptoKeyVersions.asymmetricDecrypt, cryptoKeyVersions.getPublicKey
  • MAC Signing: Usado para garantir integridade e autenticidade dos dados criando um message authentication code (MAC) usando uma chave secreta. HMAC é comumente usado para autenticação de mensagens em protocolos de rede e aplicações de software.
  • Supported: cryptoKeyVersions.macSign, cryptoKeyVersions.macVerify

Rotation Period & Programmed for destruction period

Por padrão, cada 90 dias, mas pode ser facilmente e completamente personalizado.

O período “Programmed for destruction” é o tempo desde que o usuário solicita a exclusão da chave até que a chave seja excluída. Não pode ser alterado após a criação da chave (padrão 1 dia).

Primary Version

Cada chave KMS pode ter várias versões; uma delas deve ser a padrão, que será a utilizada quando uma versão não for especificada ao interagir com a chave KMS.

CMEK permission model

When objects in Cloud Storage are encrypted with CMEK, the decrypt/encrypt calls to KMS are done by the project’s Cloud Storage service agent whose email is service-${BUCKET_PROJECT_NUMBER}@gs-project-accounts.iam.gserviceaccount.com), not directly by the end user reading the object.

Isso significa que, para ler algo criptografado por um CMEK:

  • O agente de serviço do Cloud Storage do projeto deve ter permissões KMS sobre a chave KMS usada (tipicamente roles/cloudkms.cryptoKeyEncrypterDecrypter).
  • O usuário precisa apenas de permissões de leitura do objeto (por exemplo storage.objects.get). Ele não precisa de permissões sobre a chave KMS.

Isso significa que, para controlar o acesso aos dados criptografados com a chave KMS, é necessário adicionar/remover permissões KMS ao agente de serviço do Cloud Storage do projeto.

Observe que uma vinculação em nível de projeto como roles/cloudkms.cryptoKeyEncrypterDecrypter para o agente do serviço do Cloud Storage ainda permitirá descriptografar com as chaves no mesmo projeto.

Enumeration

Tendo permissões para listar as chaves, é assim que você pode acessá-las:

# List the global keyrings available
gcloud kms keyrings list --location global
gcloud kms keyrings get-iam-policy <KEYRING>

# List the keys inside a keyring
gcloud kms keys list --keyring <KEYRING> --location <global/other_locations>
gcloud kms keys get-iam-policy <KEY>

# Encrypt a file using one of your keys
gcloud kms encrypt --ciphertext-file=[INFILE] \
--plaintext-file=[OUTFILE] \
--key [KEY] \
--keyring [KEYRING] \
--location global

# Decrypt a file using one of your keys
gcloud kms decrypt --ciphertext-file=[INFILE] \
--plaintext-file=[OUTFILE] \
--key [KEY] \
--keyring [KEYRING] \
--location global

Escalada de Privilégios

GCP - KMS Privesc

Pós-Exploração

GCP - KMS Post Exploitation

Referências

Tip

Aprenda e pratique AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Aprenda e pratique GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Aprenda e pratique Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Apoie o HackTricks