Español - Ht Cloud
HackTricks Training Twitter Linkedin Sponsor

AWS - KMS Enum

Apoya a HackTricks

KMS - Key Management Service

AWS Key Management Service (AWS KMS) se presenta como un servicio gestionado, simplificando el proceso para que los usuarios creen y gestionen claves maestras de cliente (CMKs). Estas CMKs son fundamentales en la encriptación de datos de usuario. Una característica notable de AWS KMS es que las CMKs están predominantemente aseguradas por módulos de seguridad de hardware (HSMs), mejorando la protección de las claves de encriptación.

KMS utiliza criptografía simétrica. Esto se usa para encriptar información en reposo (por ejemplo, dentro de un S3). Si necesitas encriptar información en tránsito debes usar algo como TLS.

KMS es un servicio específico de región.

Los administradores de Amazon no tienen acceso a tus claves. No pueden recuperar tus claves y no te ayudan con la encriptación de tus claves. AWS simplemente administra el sistema operativo y la aplicación subyacente, depende de nosotros administrar nuestras claves de encriptación y cómo se usan esas claves.

Customer Master Keys (CMK): Pueden encriptar datos de hasta 4KB de tamaño. Se utilizan típicamente para crear, encriptar y desencriptar las DEKs (Data Encryption Keys). Luego, las DEKs se usan para encriptar los datos.

Una clave maestra de cliente (CMK) es una representación lógica de una clave maestra en AWS KMS. Además de los identificadores de la clave maestra y otros metadatos, incluyendo su fecha de creación, descripción y estado de la clave, una CMK contiene el material de la clave que se usa para encriptar y desencriptar datos. Cuando creas una CMK, por defecto, AWS KMS genera el material de la clave para esa CMK. Sin embargo, puedes optar por crear una CMK sin material de clave y luego importar tu propio material de clave en esa CMK.

Hay 2 tipos de claves maestras:

  • AWS managed CMKs: Usadas por otros servicios para encriptar datos. Es usada por el servicio que la creó en una región. Se crean la primera vez que implementas la encriptación en ese servicio. Se rota cada 3 años y no es posible cambiarlo.

  • Customer manager CMKs: Flexibilidad, rotación, acceso configurable y política de claves. Habilitar y deshabilitar claves.

Envelope Encryption en el contexto de Key Management Service (KMS): Sistema de jerarquía de dos niveles para encriptar datos con una clave de datos y luego encriptar la clave de datos con una clave maestra.

Key Policies

Estas definen quién puede usar y acceder a una clave en KMS.

Por defecto:

  • Da acceso completo a la clave KMS a la cuenta de AWS que posee la clave KMS.

A diferencia de otras políticas de recursos de AWS, una política de clave KMS de AWS no otorga automáticamente permiso a la cuenta ni a ninguno de sus usuarios. Para dar permiso a los administradores de la cuenta, la política de clave debe incluir una declaración explícita que proporcione este permiso, como esta.

  • Sin permitir la cuenta ("AWS": "arn:aws:iam::111122223333:root") los permisos de IAM no funcionarán.

  • Permite que la cuenta use políticas de IAM para permitir el acceso a la clave KMS, además de la política de clave.

Sin este permiso, las políticas de IAM que permiten el acceso a la clave son ineficaces, aunque las políticas de IAM que niegan el acceso a la clave siguen siendo efectivas.

  • Reduce el riesgo de que la clave se vuelva inmanejable al dar permiso de control de acceso a los administradores de la cuenta, incluyendo al usuario root de la cuenta, que no puede ser eliminado.

Ejemplo de política por defecto:

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

Si la cuenta está permitida ("arn:aws:iam::111122223333:root") un principal de la cuenta aún necesitará permisos IAM para usar la clave KMS. Sin embargo, si el ARN de un rol, por ejemplo, está específicamente permitido en la Política de Clave, ese rol no necesita permisos IAM.

Detalles de la Política

Propiedades de una política:

  • Documento basado en JSON

  • Recurso --> Recursos afectados (puede ser "*")

  • Acción --> kms:Encrypt, kms:Decrypt, kms:CreateGrant ... (permisos)

  • Efecto --> Allow/Deny

  • Principal --> arn afectado

  • Condiciones (opcional) --> Condición para otorgar los permisos

Grants:

  • Permiten delegar tus permisos a otro principal de AWS dentro de tu cuenta de AWS. Necesitas crearlos usando las APIs de AWS KMS. Se puede indicar el identificador de CMK, el principal beneficiario y el nivel requerido de operación (Decrypt, Encrypt, GenerateDataKey...)

  • Después de crear el grant, se emiten un GrantToken y un GrantID

Acceso:

  • Vía política de clave -- Si esto existe, toma precedencia sobre la política IAM

  • Vía política IAM

  • Vía grants

Administradores de Claves

Administrador de claves por defecto:

  • Tienen acceso para gestionar KMS pero no para cifrar o descifrar datos

  • Solo usuarios y roles IAM pueden ser añadidos a la lista de Administradores de Claves (no grupos)

  • Si se usa un CMK externo, los Administradores de Claves tienen el permiso para importar material de clave

Rotación de CMKs

  • Cuanto más tiempo se deja la misma clave en su lugar, más datos se cifran con esa clave, y si esa clave se ve comprometida, entonces el área de impacto de los datos en riesgo es mayor. Además, cuanto más tiempo esté activa la clave, aumenta la probabilidad de que se vea comprometida.

  • KMS rota las claves de cliente cada 365 días (o puedes realizar el proceso manualmente cuando quieras) y las claves gestionadas por AWS cada 3 años y este tiempo no se puede cambiar.

  • Las claves antiguas se retienen para descifrar datos que fueron cifrados antes de la rotación

  • En una brecha, rotar la clave no eliminará la amenaza ya que será posible descifrar todos los datos cifrados con la clave comprometida. Sin embargo, los nuevos datos se cifrarán con la nueva clave.

  • Si el CMK está en estado de deshabilitado o pendiente de eliminación, KMS no realizará una rotación de clave hasta que el CMK sea reactivado o se cancele la eliminación.

Rotación manual

  • Se necesita crear un nuevo CMK, luego, se crea un nuevo CMK-ID, por lo que necesitarás actualizar cualquier aplicación para referenciar el nuevo CMK-ID.

  • Para hacer este proceso más fácil, puedes usar alias para referenciar un key-id y luego solo actualizar la clave a la que se refiere el alias.

  • Necesitas mantener las claves antiguas para descifrar los archivos antiguos cifrados con ellas.

Puedes importar claves desde tu infraestructura de claves on-premises.

Otra información relevante de KMS

KMS se cobra por el número de solicitudes de cifrado/descifrado recibidas de todos los servicios por mes.

KMS tiene integración completa de auditoría y cumplimiento con CloudTrail; aquí es donde puedes auditar todos los cambios realizados en KMS.

Con la política de KMS puedes hacer lo siguiente:

  • Limitar quién puede crear claves de datos y qué servicios tienen acceso para usar estas claves

  • Limitar el acceso de los sistemas solo para cifrar, solo para descifrar o ambos

  • Definir para habilitar el acceso de los sistemas a claves a través de regiones (aunque no se recomienda ya que una falla en la región que aloja KMS afectará la disponibilidad de los sistemas en otras regiones).

No puedes sincronizar ni mover/copiar claves entre regiones; solo puedes definir reglas para permitir el acceso entre regiones.

Enumeración

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

AWS - KMS Privesc

Post Exploitation

AWS - KMS Post Exploitation

Persistence

AWS - KMS Persistence

Referencias

Apoya HackTricks
PreviousAWS - IAM, Identity Center & SSO EnumNextAWS - Lambda Enum

Last updated