AWS - KMS Enum

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

Supporte HackTricks

Confira os planos de assinatura!
Junte-se ao 💬 grupo no Discord ou ao grupo no telegram ou siga-nos no Twitter 🐦 @hacktricks_live.
Compartilhe truques de hacking enviando PRs para o HackTricks e HackTricks Cloud repositórios no github.

KMS - Key Management Service

AWS Key Management Service (AWS KMS) é apresentado como um serviço gerenciado, simplificando o processo para os usuários criarem e gerenciarem chaves mestras de cliente (CMKs). Essas CMKs são essenciais na criptografia de dados do usuário. Uma característica notável do AWS KMS é que as CMKs são predominantemente protegidas por módulos de segurança de hardware (HSMs), aumentando a proteção das chaves de criptografia.

KMS usa criptografia simétrica. Isso é usado para criptografar informações em repouso (por exemplo, dentro de um S3). Se você precisar criptografar informações em trânsito, você precisa usar algo como TLS.

KMS é um serviço específico de região.

Administradores da Amazon não têm acesso às suas chaves. Eles não podem recuperar suas chaves e não ajudam você com a criptografia de suas chaves. A AWS simplesmente administra o sistema operacional e a aplicação subjacente, cabe a nós administrar nossas chaves de criptografia e administrar como essas chaves são usadas.

Customer Master Keys (CMK): Podem criptografar dados de até 4KB de tamanho. Elas são tipicamente usadas para criar, criptografar e descriptografar as DEKs (Data Encryption Keys). Então as DEKs são usadas para criptografar os dados.

Uma chave mestra de cliente (CMK) é uma representação lógica de uma chave mestra no AWS KMS. Além dos identificadores da chave mestra e outros metadados, incluindo sua data de criação, descrição e estado da chave, uma CMK contém o material da chave que é usado para criptografar e descriptografar dados. Quando você cria uma CMK, por padrão, o AWS KMS gera o material da chave para essa CMK. No entanto, você pode optar por criar uma CMK sem material de chave e, em seguida, importar seu próprio material de chave para essa CMK.

Existem 2 tipos de chaves mestras:

AWS managed CMKs: Usadas por outros serviços para criptografar dados. É usada pelo serviço que a criou em uma região. Elas são criadas na primeira vez que você implementa a criptografia nesse serviço. Rotaciona a cada 3 anos e não é possível alterá-la.
Customer manager CMKs: Flexibilidade, rotação, acesso configurável e política de chave. Habilitar e desabilitar chaves.

Envelope Encryption no contexto do Key Management Service (KMS): Sistema de hierarquia de dois níveis para criptografar dados com chave de dados e depois criptografar a chave de dados com chave mestra.

Key Policies

Estas definem quem pode usar e acessar uma chave no KMS.

Por padrão:

Dá à conta AWS que possui a chave KMS acesso total à chave KMS.

Ao contrário de outras políticas de recursos da AWS, uma política de chave KMS da AWS não concede automaticamente permissão à conta ou a qualquer um de seus usuários. Para conceder permissão aos administradores da conta, a política de chave deve incluir uma declaração explícita que forneça essa permissão, como esta.

Sem permitir a conta("AWS": "arn:aws:iam::111122223333:root") permissões IAM não funcionarão.
Permite que a conta use políticas IAM para permitir acesso à chave KMS, além da política de chave.

Sem essa permissão, as políticas IAM que permitem acesso à chave são ineficazes, embora as políticas IAM que negam acesso à chave ainda sejam eficazes.

Reduz o risco de a chave se tornar inadministrável ao conceder permissão de controle de acesso aos administradores da conta, incluindo o usuário root da conta, que não pode ser excluído.

Exemplo de política padrão:

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

Se a conta for permitida ("arn:aws:iam::111122223333:root") um principal da conta ainda precisará de permissões IAM para usar a chave KMS. No entanto, se o ARN de uma função, por exemplo, for especificamente permitido na Política de Chave, essa função não precisa de permissões IAM.

Detalhes da Política

Propriedades de uma política:

Documento baseado em JSON
Recurso --> Recursos afetados (pode ser "*")
Ação --> kms:Encrypt, kms:Decrypt, kms:CreateGrant ... (permissões)
Efeito --> Allow/Deny
Principal --> arn afetado
Condições (opcional) --> Condição para conceder as permissões

Grants:

Permite delegar suas permissões a outro principal AWS dentro da sua conta AWS. Você precisa criá-los usando as APIs AWS KMS. Pode ser indicado o identificador CMK, o principal beneficiário e o nível de operação necessário (Decrypt, Encrypt, GenerateDataKey...)
Após a criação do grant, um GrantToken e um GrantID são emitidos

Acesso:

Via política de chave -- Se isso existir, tem precedência sobre a política IAM
Via política IAM
Via grants

Administradores de Chave

Administrador de chave por padrão:

Tem acesso para gerenciar KMS, mas não para criptografar ou descriptografar dados
Somente usuários e funções IAM podem ser adicionados à lista de Administradores de Chave (não grupos)
Se CMK externo for usado, os Administradores de Chave têm permissão para importar material de chave

Rotação de CMKs

Quanto mais tempo a mesma chave é mantida, mais dados são criptografados com essa chave, e se essa chave for comprometida, maior será a área de impacto dos dados em risco. Além disso, quanto mais tempo a chave estiver ativa, maior será a probabilidade de ser comprometida.
KMS rotaciona chaves de clientes a cada 365 dias (ou você pode realizar o processo manualmente sempre que quiser) e chaves gerenciadas pela AWS a cada 3 anos e esse tempo não pode ser alterado.
Chaves antigas são mantidas para descriptografar dados que foram criptografados antes da rotação
Em caso de violação, rotacionar a chave não removerá a ameaça, pois será possível descriptografar todos os dados criptografados com a chave comprometida. No entanto, os novos dados serão criptografados com a nova chave.
Se o CMK estiver no estado de desativado ou pendente de exclusão, o KMS não realizará uma rotação de chave até que o CMK seja reativado ou a exclusão seja cancelada.

Rotação manual

Um novo CMK precisa ser criado, então, um novo CMK-ID é criado, portanto, você precisará atualizar qualquer aplicação para referenciar o novo CMK-ID.
Para facilitar esse processo, você pode usar aliases para se referir a um key-id e então apenas atualizar a chave à qual o alias se refere.
Você precisa manter as chaves antigas para descriptografar arquivos antigos criptografados com elas.

Você pode importar chaves da sua infraestrutura de chaves on-premises.

Outras informações relevantes do KMS

O KMS é cobrado pelo número de solicitações de criptografia/descriptografia recebidas de todos os serviços por mês.

O KMS tem integração completa de auditoria e conformidade com o CloudTrail; é aqui que você pode auditar todas as mudanças realizadas no KMS.

Com a política do KMS, você pode fazer o seguinte:

Limitar quem pode criar chaves de dados e quais serviços têm acesso para usar essas chaves
Limitar o acesso dos sistemas apenas para criptografar, apenas para descriptografar ou ambos
Definir para permitir que os sistemas acessem chaves entre regiões (embora não seja recomendado, pois uma falha na região que hospeda o KMS afetará a disponibilidade dos sistemas em outras regiões).

Você não pode sincronizar ou mover/copiar chaves entre regiões; você só pode definir regras para permitir o acesso entre regiões.

Enumeração

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