¿Qué pasaría si los usuarios de IAM pudieran generar claves de API de AWS libremente y sin restricciones? ¿Y si los administradores de seguridad no tuvieran visibilidad de la creación de claves de API y no pudieran auditar quién las utiliza?
Aunque este escenario no se aplica a AWS, es una cruda realidad para las claves HMAC de Google Cloud . En este blog se describen tres vulnerabilidades surgidas a partir de la forma en que Google Cloud gestiona las claves HMAC asociadas a usuarios.
1. Vulnerabilidad nº 1 - Registro insuficiente
2. Vulnerabilidad nº 2 - Credenciales inmanejables a largo plazo
3. Vulnerabilidad nº 3 - Credenciales no auditables a largo plazo
TLDR;
- Las claves HMAC tienen una finalidad práctica. Se pueden utilizar para crear cabeceras firmadas Sigv4 utilizadas para autenticar contra la API XML deCloud Storage. durante un máximo de 7 días después de la creación inicial.
- Los registros de auditoría de Google Cloud no registran los eventos de creación o eliminación de claves HMAC cuando están asociados a cuentas de usuario.
- La API de Google Cloud no está disponible para los administradores, lo que les impide auditar la existencia de claves HMAC asociadas a cuentas de usuario.
- No existen permisos de Cloud IAM para restringir la creación, eliminación o uso de claves HMAC.
- Este problema ha sido reportado a través del Programa de Recompensa de Vulnerabilidades de Google y han cerrado el problema sin proporcionar una solución citando que el comportamiento reportado está funcionando según lo previsto.
Uso de claves HMAC
Las API de creación y eliminación de claves HMAC asociadas a cuentas de usuario no son accesibles externamente. Estas acciones sólo pueden realizarse a través del servicio de API privada de la consola en cloud (cloudconsole-pa), al que se accede a través de la pestaña de interoperabilidad de la consola de almacenamiento. Las URL identificadas a continuación representan los puntos finales dentro de la consola de cloud utilizados para crear y eliminar claves HMAC asociadas a usuarios cuando van acompañadas de una cookie de inicio de sesión válida.
- Una petición POST a `/v3/entityServices/StorageEntityService/entities/STORAGE_USER_HMAC/CREATE` crea una clave HMAC utilizada en el proceso de firma Sigv4.
- Una petición POST a `/v3/entityServices/StorageEntityService/entities/STORAGE_USER_HMAC/DELETE` borra un HMAC asociado a un usuario.
Los usuarios de Google Cloud pueden crear una cantidad aparentemente infinita del tipo de recurso: "type.googleapis.com/google.internal.cloud.console.clientapi.storage.UserHmac"
En las pruebas no se identificó ningún límite superior de claves HMAC y no se encontró ninguna limitación de clasificación.
Vulnerabilidad nº 1 - Registro insuficiente
Los Registros de Auditoría de Cloud no capturan acciones mediadas a través del servicio API privado de la consola de cloud (cloudconsole-pa). En consecuencia, no hay registro de la creación o eliminación de claves HMAC vinculadas a cuentas de usuario. Esta ausencia de registros dificulta la capacidad de los defensores para alertar o supervisar la creación de claves HMAC para cuentas de usuario, lo que supone un riesgo de persistencia, o su eliminación, lo que representa un riesgo de denegación de servicio.
Vulnerabilidad nº 2: credenciales inmanejables a largo plazo
Los usuarios con acceso a Google Cloud pueden crear claves HMAC, requiriendo al menos el permiso resource manager.projects.get. Sin embargo, no existen permisos de Cloud IAM para gestionar claves HMAC para uno mismo o para otros usuarios, lo que impide a los administradores controlar su creación. Como resultado, este aviso no proporciona recomendaciones para mitigar el riesgo de exposición de claves HMAC mediante la limitación de la asignación de permisos.
Vulnerabilidad nº 3 - Credenciales no auditables a largo plazo
Los administradores de Cloud se enfrentan a retos a la hora de gestionar las claves HMAC dentro de sus organizaciones, al carecer de visibilidad sobre qué cuentas de usuario han generado estas claves y si se están utilizando activamente para acceder a objetos de almacenamiento. Además, carecen de funciones para revocar claves asociadas a otros usuarios, lo que limita su capacidad para aplicar políticas de seguridad de forma eficaz.
Los equipos de respuesta a incidentes confían en Cloud Logging para supervisar el acceso a objetos de Cloud Storage, pero carecen de indicadores específicos para determinar si se están utilizando claves HMAC en estos intentos de acceso. Aunque varias acciones de contención, como suspender o eliminar las cuentas de usuario comprometidas, pueden parecer eficaces inicialmente al rechazar las cabeceras firmadas Sigv4 creadas previamente, reactivar o volver a crear el mismo usuario permite reutilizar las credenciales a menos que hayan caducado.
Además, la eliminación de los roles de Cloud IAM puede revocar el acceso a los recursos de almacenamiento afectados. Sin embargo, es importante tener en cuenta que la reasignación de roles no invalida las cabeceras firmadas Sigv4 creadas previamente, lo que permite que sigan funcionando incluso después del cambio de rol.
Caso de abuso de la clave HMAC
Un atacante en posesión de una cuenta de usuario de Google con acceso a un proyecto de Google Cloud y mínimamente el permiso `resource manager.projects.get` es capaz de generar claves HMAC en la pestaña de interoperabilidad de la consola de almacenamiento.
Una ruta de ataque aprovechando claves HMAC puede desarrollarse de la siguiente manera:
1. Un atacante compromete una cuenta de usuario de Google
2. Genera una clave HMAC para el usuario
3. Utiliza la clave HMAC para generar una serie de cabeceras firmadas Sigv4 con una caducidad de 7 días.
4. Exfiltra datos de Google Cloud Storage hasta que expira la firma del encabezado.
5. La identificación del acceso al almacenamiento malicioso y/o la respuesta se ve obstaculizada debido a las vulnerabilidades #1, #2 y #3 descritas anteriormente.
6. Los intentos de contención pueden ser ineficaces, como cambiar la contraseña de los usuarios comprometidos, o temporales, si se suspende a un usuario afectado pero se reactiva más tarde.
Prueba de concepto
El SDK de Google Cloud no dispone de funciones para convertir una clave HMAC asociada a un usuario en credenciales utilizables a través del proceso de firma Sigv4. Por ello, hemos proporcionado un sencillo script de ayuda en python para hacerlo. Toma un identificador de clave de acceso, un secreto, un objeto y un nombre de bucket y devuelve una solicitud curl con una cabecera de autorización firmada que se utilizará para recuperar el objeto GCS objetivo a través de la API XML.
La prueba de concepto está fuertemente influenciada por un artículo de Rosy Parmar sobre el uso de HMAC para autenticarse en Google Cloud.
Recomendaciones
A la luz de los numerosos abusos asociados a las claves HMAC específicas de usuario, aquí se presentan una serie de recomendaciones que mejoran la gestión, el registro y el ciclo de vida de las claves HMAC de GCP.
1. Permisos y API
- Introducir API y permisos asociados que faculten a los administradores, dándoles la autoridad para crear y eliminar claves HMAC específicas de usuario según sea necesario.
- Crea API y permisos asociados que permitan a los administradores de Google Workspace auditar las claves HMAC de todos los usuarios de su Organización, su uso y la capacidad de eliminar claves para otros.
2. Política de organización
- Cree una restricción de política orgánica que permita a los administradores de políticas impedir la creación de claves HMAC asociadas a usuarios.
3. Registro
- Write to Admin Activity admin registra la creación y eliminación de todas las claves HMAC, incluidas las asociadas a usuarios.
- Indicar en Cloud Logs cuando se accede a la API XML de Cloud Storage utilizando una credencial de encabezado Sigv4.
4. Gestión de credenciales
- Limita el número de claves HMAC que cualquier usuario puede crear a un máximo de dos.
- Introducir un dato de caducidad configurado por el usuario para las claves HMAC.
- Sólo mostrar las claves HMAC a los usuarios una vez, cuando se crean, y no secretos a la interfaz de usuario en las solicitudes posteriores.
Calendario de divulgación
2/07/24 [Kat Traxler]: Reportado al Programa de Recompensa de Vulnerabilidades de Google bajo el titular "Las claves HMAC generadas para los usuarios plantean riesgos de seguridad, especialmente debido a la ausencia de eventos de registro en su creación o eliminación."
2/07/24 [Google]: Confirma la recepción del informe
2/08/24 [Google]: Indicaron que estaban cerrando el tema debido a la falta de detalles. Se solicitó un escenario de ataque y una prueba de concepto.
02/09/24 [Kat Traxler]: Respondido con un recorrido más detallado de las acciones del atacante dadas las características de las claves HMAC y una promesa de escribir un PoC.
2/12/24 [Google]: Estado cambiado a "Asignado, Reabierto, Triaged".
16/2/24 [Google]: El equipo de Google Bug Hunter recapituló los detalles de la vulnerabilidad reportada, solicitó un ejemplo de una cabecera firmada Sigv4 y preguntó si las credenciales se pueden utilizar para acceder a algo más que la API XML de Google Cloud Storage.
18/2/24 [Kat Traxler]: Respondió a la serie de preguntas y confirmó que las credenciales generadas a partir de claves HMAC sólo pueden utilizarse para acceder a la API XML de Google Cloud Storage.
19/2/24 [Kat Traxler]: Proporcionamos al equipo de Google Bug Hunter un enlace al PoC alojado en Github que les permite generar sus propias cabeceras firmadas con claves HMAC.
28/2/24 [Google]: El problema fue "identificado como un Riesgo de Abuso y triado a nuestro equipo de Confianza y Seguridad".
28/2/24 [Google]: Respondió con un agradecimiento por el informe e indicó que el equipo estaba analizando el envío.
04/01/24 [Kat Traxler]: "Siguiendo con este informe. Han pasado unas 4 semanas desde la última vez que hablamos. Como recordatorio, tengo previsto dar a conocer este problema en torno a la primera semana de junio. Me gustaría aprovechar el tiempo que tenemos para coordinar con el equipo de servicio la implementación de los registros y controles IAM que faltan. Sin nuevos eventos registrados y nuevos controles de IAM, la divulgación sólo contendrá detalles del mecanismo de persistencia sin ninguna orientación para los clientes sobre cómo prevenirlo o detectarlo. A nadie le gusta ese tipo de blog de divulgación. *Por favor, hágame saber cómo puedo ayudar a elevar este tema o coordinar con las partes responsables".
4/02/24 [Google]: "🎉 ¡Buena captura! He presentado un error al equipo de producto responsable basándome en tu informe. Trabajaremos con el equipo de producto para asegurarnos de que se soluciona este problema. Te avisaremos cuando se haya solucionado el problema".
4/11/24 [Google]: "El panel del Programa de Recompensa de Vulnerabilidades de Google ha decidido que el impacto de seguridad de este problema no cumple los requisitos para una recompensa económica."
24/06 [Google]: "Nuestros sistemas muestran que el error que creamos basándonos en su informe se ha cerrado sin proporcionar una solución. Esto puede haber sucedido por varias razones: el impacto del riesgo puede ser demasiado pequeño para justificar una solución, puede haber otros factores atenuantes, o simplemente el producto ya no se mantiene. El estado exacto es INTENDED_BEHAVIOR. Esta decisión ha sido tomada por los equipos de producto correspondientes y no afecta al importe de tu recompensa VRP ni a tu posición en la clasificación. No podemos proporcionar más detalles en esta notificación automática, pero estaremos encantados de responder a tus preguntas sobre esta decisión."