AWS - KMS Enum

Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks

Check the subscription plans!
Join the 💬 Discord group or the telegram group or follow us on Twitter 🐦 @hacktricks_live.
Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.

KMS - Serviço de Gerenciamento de Chaves

O Serviço de Gerenciamento de Chaves da AWS (AWS KMS) é apresentado como um serviço gerenciado, simplificando o processo para os usuários criarem e gerenciarem chaves mestras do cliente (CMKs). Essas CMKs são integrais na criptografia dos dados do usuário. Um recurso 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.

O 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, precisará usar algo como TLS.

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

Os 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 o aplicativo subjacente; cabe a nós administrar nossas chaves de criptografia e administrar como essas chaves são usadas.

Chaves Mestras do Cliente (CMK): Podem criptografar dados de até 4KB de tamanho. Elas são tipicamente usadas para criar, criptografar e descriptografar as DEKs (Chaves de Criptografia de Dados). Então, as DEKs são usadas para criptografar os dados.

Uma chave mestra do 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 da chave e, em seguida, importar seu próprio material da chave para essa CMK.

Existem 2 tipos de chaves mestras:

CMKs gerenciadas pela AWS: Usadas por outros serviços para criptografar dados. Elas são usadas pelo serviço que as 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.
CMKs gerenciadas pelo cliente: Flexibilidade, rotação, acesso configurável e política de chave. Habilitar e desabilitar chaves.

Criptografia Envelope no contexto do Serviço de Gerenciamento de Chaves (KMS): Sistema de hierarquia de dois níveis para criptografar dados com a chave de dados e, em seguida, criptografar a chave de dados com a chave mestra.

Políticas de Chave

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

Por padrão:

Ele dá ao 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 dá automaticamente permissão à conta ou a qualquer um de seus usuários. Para dar 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") as permissões IAM não funcionarão.
Ele 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.

Ele reduz o risco de a chave se tornar inadministrável ao dar 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 um papel, por exemplo, for especificamente permitido na Política da Chave, esse papel 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 --> Permitir/Negar
Principal --> arn afetado
Condições (opcional) --> Condição para conceder as permissões

Concessões:

Permite delegar suas permissões a outro principal AWS dentro de sua conta AWS. Você precisa criá-las usando as APIs do 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 concessão ser criada, um GrantToken e um GrantID são emitidos

Acesso:

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

Administradores de Chave

Administrador de chave por padrão:

Tem acesso para gerenciar KMS, mas não para criptografar ou descriptografar dados
Apenas usuários e papéis IAM podem ser adicionados à lista de Administradores de Chave (não grupos)
Se uma CMK externa for usada, os Administradores de Chave têm a permissão para importar material de chave

Rotação de CMKs

Quanto mais tempo a mesma chave permanecer no lugar, mais dados serão criptografados com essa chave, e se essa chave for comprometida, então a área de impacto dos dados estará em risco. Além disso, quanto mais tempo a chave estiver ativa, maior 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 mais antigas são retidas para descriptografar dados que foram criptografados antes da rotação
Em uma 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 a CMK estiver em estado de desativada ou pendente de exclusão, o KMS não realizará uma rotação de chave até que a CMK seja reativada ou a exclusão seja cancelada.

Rotação manual

Uma nova CMK precisa ser criada, então, um novo CMK-ID é criado, portanto, você precisará atualizar qualquer aplicativo 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 está se referindo.
Você precisa manter chaves antigas para descriptografar arquivos antigos criptografados com elas.

Você pode importar chaves de sua infraestrutura de chaves local.

Outras informações relevantes do KMS

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

O KMS tem plena auditoria e conformidade integração com o CloudTrail; é aqui que você pode auditar todas as alterações realizadas no KMS.

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

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

Você não pode sincronizar ou mover/copiar chaves entre regiões; você só pode definir regras para permitir 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