Prácticas recomendadas para mitigar los tokens de OAuth vulnerados en Google Cloud CLI

Last reviewed 2024-02-15 UTC

En este documento, se describe cómo mitigar el impacto de un atacante que compromete los tokens de OAuth que usa la CLI de gcloud.

Un atacante puede comprometer estos tokens de OAuth si obtiene acceso a un extremo en el que una cuenta de usuario o una cuenta de servicio legítima ya se autenticó con la CLI de gcloud. Luego, el atacante puede copiar estos tokens en otro extremo que controle para realizar solicitudes que actúen en nombre de la identidad legítima. Incluso después de quitar el acceso del atacante al extremo vulnerado, el atacante puede seguir realizando solicitudes a la API autenticadas mediante los tokens copiados. Para mitigar este riesgo, puedes controlar el acceso a tus sistemas mediante credenciales de corta duración y contextuales.

Este documento está dirigido a los equipos de seguridad o arquitectos de la nube que son responsables de proteger los recursos de la nube del acceso ilegítimo. En este documento, se presentan los controles disponibles que puedes usar para reducir de forma proactiva el impacto de los tokens de OAuth de la CLI de gcloud vulnerados y corregir el entorno después de que se haya vulnerado un extremo.

Descripción general

Para comprender cómo funciona esta amenaza, debes comprender la forma en la que la CLI de gcloud almacena las credenciales de OAuth 2.0 y cómo se pueden abusar de ellas si un atacante las vulnera.

Tipos de credenciales que almacena la CLI de gcloud

La CLI de gcloud usa tokens de acceso de OAuth 2.0 para autenticar solicitudes a las APIs de Google. El flujo de OAuth varía según los tipos de credenciales que se usan, pero, por lo general, se puede acceder de forma local al token de acceso y a otras credenciales. En cada caso, el token de acceso se vence después de 60 minutos, pero otros tipos de credenciales pueden ser persistentes.

Cuando autorizas la CLI de gcloud con una cuenta de usuario, la CLI de gcloud inicia un flujo de consentimiento de OAuth de tres segmentos para acceder a las APIs de Google Cloud en nombre del usuario. Después de que el usuario completa el flujo de consentimiento, la CLI de gcloud recibe un token de acceso y un token de actualización que le permite solicitar nuevos tokens de acceso. En la configuración predeterminada, el token de actualización de larga duración persiste hasta que se cumplan las condiciones de vencimiento.

Cuando autorizas la CLI de gcloud con una cuenta de servicio, la CLI de gcloud inicia un flujo de OAuth de dos segmentos para acceder a las APIs de Google Cloud como la identidad de la cuenta de servicio. Después de activar una cuenta de servicio desde un archivo de claves privadas, esta clave se usa para solicitar de forma periódica un token de acceso. La clave privada de larga duración se almacena en la configuración de la CLI de gcloud y permanece válida hasta que borres la clave de la cuenta de servicio.

Cuando ejecutas la CLI de gcloud dentro de un entorno de Google Cloud, como Compute Engine o Cloud Shell, la aplicación puede encontrar credenciales y autenticarse como una cuenta de servicio de forma automática. Por ejemplo, en Compute Engine, una aplicación como la CLI de gcloud puede consultar el servidor de metadatos para obtener un token de acceso. Google administra y rota la clave de firma privada, que se usa para crear el token de acceso, y las credenciales de larga duración no se exponen a la aplicación.

Cuando realizas la autenticación con la federación de Workload Identity, las aplicaciones se autentican según una credencial de un proveedor de identidad externo y reciben un token de acceso federado de corta duración. Para obtener más información sobre cómo almacenar y administrar las credenciales de larga duración que usa el proveedor de identidad externo, consulta las prácticas recomendadas para usar la federación de Workload Identity.

Cómo un atacante puede usar tokens de OAuth vulnerados

Si un atacante logra comprometer un extremo, las credenciales como los tokens de OAuth son objetivos valiosos, ya que permiten a los atacantes conservar o escalar su acceso.

Es posible que un desarrollador tenga una necesidad legítima de ver sus propias credenciales cuando escribe y depura el código. Por ejemplo, es posible que un desarrollador necesite autenticarse para usar las solicitudes de REST a los servicios de Google Cloud cuando trabaja con una biblioteca cliente no compatible. El desarrollador puede ver las credenciales a través de varios métodos, incluidos los siguientes:

Sin embargo, un atacante podría usar estas mismas técnicas después de que haya comprometido un extremo.

Si un atacante compromete un extremo, como una estación de trabajo para desarrolladores, la amenaza principal es que puede ejecutar comandos de la CLI de gcloud o algún otro código con las credenciales legítimas de la identidad autenticada. Además, el atacante puede copiar los tokens de OAuth en otro extremo que controle para conservar su acceso. Cuando ocurre este robo de credenciales, existe una amenaza secundaria: el atacante aún puede usar los tokens de OAuth de larga duración para tener acceso persistente incluso después de quitar el acceso al extremo vulnerado.

Si el atacante logra comprometer los tokens de OAuth, puede completar las siguientes acciones:

  • Un atacante puede actuar en nombre de un usuario o una cuenta de servicio vulnerados. El tráfico de la API que usa los tokens vulnerados se registra como si proviniera del usuario o cuenta de servicio vulnerados, lo que dificulta distinguir entre la actividad normal y la maliciosa en los registros.
  • Un atacante puede actualizar el token de acceso de forma indefinida mediante un token de actualización persistente asociado con un usuario o una clave privada asociada con una cuenta de servicio.
  • Un atacante puede omitir la autenticación con la contraseña del usuario o la verificación en 2 pasos porque los tokens se otorgan después del flujo de acceso.

Prácticas recomendadas para mitigar riesgos

Implementa los controles que se describen en las siguientes secciones para mitigar el riesgo de tokens de gcloud CLI vulnerados. Si sigues las prácticas recomendadas de seguridad que se describen en el plano de las bases empresarial o en el diseño de la zona de destino en Google Cloud, es posible que ya tengas habilitados estos controles.

Establece la duración de la sesión para los servicios de Google Cloud

Para reducir la cantidad de tiempo que un atacante puede explotar un token vulnerado, establece la duración de la sesión para los servicios de Google Cloud. De forma predeterminada, el token de actualización que el sistema otorga después de la autenticación es una credencial de larga duración y una sesión de la CLI de gcloud nunca requiere que se vuelva a autenticar. Cambia esta configuración para configurar una política de reautenticación con una duración de sesión que esté entre 1 y 24 horas. Después de la duración de la sesión definida, la política de reautenticación invalida el token de actualización y obliga al usuario a volver a autenticar la CLI de gcloud con regularidad mediante su contraseña o clave de seguridad.

La duración de la sesión para los servicios de Google Cloud es una configuración distinta de la duración de la sesión para los servicios de Google, que controla las sesiones web de acceso a todos los servicios de Google Workspace, pero no controla la reautenticación para Google Cloud. Si usas los servicios de Google Workspace, establece la duración de la sesión para ambos.

Configurar los Controles del servicio de VPC

Configura Controles del servicio de VPC en todo tu entorno para garantizar que solo pueda acceder a los recursos admitidos el tráfico de la API de Google Cloud que se origina dentro del perímetro definido. El perímetro de servicio limita la utilidad de las credenciales vulneradas porque el perímetro bloquea las solicitudes a servicios restringidos que se originan en extremos controlados por atacantes que están fuera de tu entorno.

Configura BeyondCorp Enterprise

Configura las políticas de BeyondCorp Enterprise para proteger la consola de Google Cloud y las APIs de Google Cloud. Configura un nivel de acceso y una vinculación de BeyondCorp Enterprise para permitir atributos de forma selectiva que se evalúan en cada solicitud a la API, incluido el acceso basado en IP o el acceso basado en certificados para TLS mutua. Las solicitudes que usan credenciales de autorización vulneradas, pero no cumplen con las condiciones definidas en tu política de BeyondCorp Enterprise se rechazan.

BeyondCorp Enterprise es un control centrado en el usuario que rechaza el tráfico de la API de usuario que no cumple con las condiciones definidas. Los Controles del servicio de VPC son un control centrado en los recursos que define los perímetros dentro de los cuales pueden comunicarse los recursos. Los Controles del servicio de VPC se aplican a todas las identidades de usuarios y las cuentas de servicio, pero BeyondCorp Enterprise solo se aplica a las identidades de usuarios dentro de tu organización. Cuando se usan en conjunto, los Controles del servicio de VPC y BeyondCorp Enterprise reducen la efectividad de las credenciales vulneradas en una máquina controlada por atacantes que está fuera de tu entorno.

Aplica la verificación en 2 pasos para el acceso remoto al servidor

Si permites que los desarrolladores accedan a los recursos de Compute Engine mediante SSH, configura el Acceso al SO con la verificación en 2 pasos. Esto aplica un punto de control adicional en el que un usuario debe volver a autenticarse con su contraseña o clave de seguridad. Un atacante con tokens de OAuth vulnerados, pero sin una contraseña ni una llave de seguridad está bloqueado por esta función.

El acceso de protocolo de escritorio remoto (RDP) a las instancias de Windows en Compute Engine no admite el servicio de Acceso al SO, por lo que la verificación en 2 pasos no se puede aplicar de forma detallada para las sesiones de RDP. Cuando uses los complementos de IAP Desktop o RDP basados en Google Chrome, configura controles generales como la duración de la sesión para los servicios de Google y la verificación en 2 pasos para las sesiones web del usuario. Además, inhabilita el parámetro de configuración Permitir que el usuario confíe en el dispositivo

Restringe el uso de claves de cuentas de servicio

Cuando usas una clave de cuenta de servicio para autenticarte, el valor de la clave se almacena en los archivos de configuración de la CLI de gcloud, por separado del archivo de claves descargado. Un atacante con acceso a tu entorno podría copiar la clave de la configuración de la CLI de gcloud o copiar el archivo de claves del sistema de archivos local o del repositorio de código interno. Por lo tanto, además de tu plan para mitigar los tokens de acceso vulnerados, considera cómo administras los archivos de claves de la cuenta de servicio descargados.

Revisa alternativas más seguras para la autenticación para reducir o eliminar los casos de uso que dependen de una clave de cuenta de servicio y aplicar la restricción de la política de la organización iam.disableServiceAccountKeyCreation para inhabilitar la creación de claves de cuentas de servicio.

Considera el principio de privilegio mínimo

Cuando diseñes políticas de IAM, considera el privilegio mínimo. Otorga a los usuarios los roles que necesitan para realizar una tarea con el permiso más bajo. No les otorgues roles que no necesitan. Revisa y aplica recomendaciones de roles para evitar políticas de IAM con roles excesivos y sin usar en tu entorno.

Protege tus extremos

Considera cómo un atacante puede obtener acceso físico o remoto a tus extremos, como estaciones de trabajo para desarrolladores o instancias de Compute Engine. Si bien un plan para abordar la amenaza de tokens de OAuth vulnerados es importante, también considera cómo responder a la amenaza de cómo un atacante puede comprometer los extremos de confianza. Si un atacante tiene acceso a tus extremos de confianza, puede ejecutar comandos de la CLI de gcloud o algún otro código directamente en el extremo.

Aunque la protección integral de las estaciones de trabajo para desarrolladores está fuera del alcance de este documento, evalúa cómo tus herramientas y operaciones de seguridad pueden ayudar a proteger y supervisar los extremos a fin de lograr riesgos. Ten en cuenta las siguientes preguntas:

  • ¿Cómo está protegida la seguridad física de las estaciones de trabajo para desarrolladores?
  • ¿Cómo identificas y respondes a las vulneraciones de la red?
  • ¿Cómo obtienen los usuarios el acceso remoto a las sesiones de SSH o RDP?
  • ¿Cómo se pueden comprometer otras credenciales persistentes, como las claves SSH o las claves de cuenta de servicio?
  • ¿Hay flujos de trabajo que usen credenciales persistentes que se puedan reemplazar por credenciales de corta duración?
  • ¿Hay dispositivos compartidos en los que alguien pueda leer las credenciales de la CLI de gcloud de otro usuario almacenadas en caché?
  • ¿Puede un usuario autenticarse con la CLI de gcloud desde un dispositivo no confiable?
  • ¿Cómo se conecta el tráfico aprobado a los recursos dentro del perímetro de Control de servicios de VPC?

Asegúrate de que tus operaciones de seguridad aborden cada una de estas preguntas.

Alinea a tus equipos de respuesta

Asegúrate de antemano de que los equipos de seguridad que son responsables de la respuesta ante incidentes tengan el acceso adecuado en la consola de Google Cloud y la Consola del administrador. Si equipos separados administran la consola de Google Cloud y la Consola del administrador, es posible que tengas una respuesta retrasada durante un incidente.

Para quitar el acceso de una cuenta de usuario vulnerada, tu equipo de respuesta ante incidentes necesita un rol de la Consola del administrador, como Administrador de administración de usuarios. Para evaluar si se produjo actividad sospechosa en los recursos de Google Cloud, este equipo también podría necesitar roles de IAM, como revisor de seguridad en todos los proyectos o visor de registros en un centralizado. receptor de registros. Los roles necesarios para el equipo de seguridad variarán según el diseño y el funcionamiento de tu entorno.

Prácticas recomendadas para solucionar problemas después de un incidente de seguridad

Después de que un extremo está comprometido, como parte de tu plan de administración de incidentes, determina cómo responder a la amenaza principal de un extremo vulnerado y cómo mitigar posibles daños continuos de la amenaza secundaria de los tokens vulnerados. Si un atacante tiene acceso persistente a la estación de trabajo para desarrolladores, puede volver a copiar los tokens después de que el usuario legítimo vuelva a autenticarse. Si sospechas que los tokens de la CLI de gcloud pueden estar comprometidos, abre un ticket de Atención al cliente de Cloud y completa las recomendaciones en las siguientes secciones. Estas acciones pueden ayudar a limitar el impacto de un evento como este en la organización de Google Cloud.

Las recomendaciones de esta sección se superponen con la guía general sobre cómo manejar las credenciales vulneradas de Google Cloud, pero se enfocan específicamente en la amenaza de los tokens de la CLI de gcloud que se copian desde un extremo vulnerado.

Haz que venzan los tokens activos en todas las cuentas de usuario con el control de sesión de Google Cloud

Si aún no aplicaste el control de sesiones de Google Cloud, habilítalo de inmediato con una frecuencia de reautenticación breve. Este control ayuda a garantizar que todos los tokens de actualización caduquen al final de la duración que definas, lo que limita la duración que un atacante puede usar los tokens vulnerados.

Invalida manualmente los tokens para las cuentas de usuario vulneradas

Revisa la guía sobre cómo manejar credenciales vulneradas para cualquier identidad de usuario que podría estar comprometida. En particular, la eliminación de las credenciales de la CLI de gcloud es el método más eficaz para que un equipo de seguridad aborde tokens de OAuth vulnerados por identidades de usuario. A fin de invalidar de inmediato los tokens de actualización y los tokens de acceso para la CLI de gcloud y forzar al usuario a volver a autenticarse con su contraseña o llave de seguridad, quita la CLI de gcloud de la lista de aplicaciones conectadas de un usuario.

Un usuario individual también puede quitar las credenciales de la CLI de gcloud para su cuenta individual.

Otros métodos, como la suspensión del usuario, el restablecimiento de la contraseña del usuario o el restablecimiento de las cookies de acceso, no abordan específicamente la amenaza de tokens de OAuth vulnerados. Estos métodos suelen ser útiles para la respuesta ante incidentes, pero no invalidan los tokens de acceso que el atacante ya controla. Por ejemplo, si decides suspender un usuario durante una investigación, pero no revocas los tokens de la CLI de gcloud, es posible que los tokens de acceso aún sean válidos si el usuario suspendido se restablece antes de que venzan los tokens de acceso.

Invalida tokens de manera programática para muchas cuentas de usuario

Si sospechas que se produjo un incumplimiento, pero no puedes identificar a qué usuarios se vieron afectados, considera revocar las sesiones activas de todos los usuarios de tu organización más rápido de lo que permite la política de reautenticación.

Este enfoque puede ser perjudicial para los usuarios legítimos y finalizar los procesos de larga duración que dependen de las credenciales del usuario. Si eliges adoptar este enfoque, prepara una solución con secuencias de comandos para que tu centro de operaciones de seguridad (SOC) se ejecute con anticipación y pruébala con algunos usuarios.

El siguiente código de muestra usa el SDK de Admin de Workspace para identificar todas las identidades de los usuarios en tu cuenta de Google Workspace o Cloud Identity que tienen acceso a la CLI de gcloud. Si un usuario autorizó la CLI de gcloud, la secuencia de comandos revoca el token de actualización y el token de acceso, y los obliga a volver a autenticarse con su contraseña o llave de seguridad. Para obtener instrucciones sobre cómo habilitar la API del SDK de Admin y ejecutar este código, consulta la Guía de inicio rápido de Google Apps Script.

/**
 * Remove access to the Google Cloud CLI for all users in an organization
 * @see https://developers.google.com/admin-sdk/directory/reference/rest/v1/tokens
 * @see https://developers.google.com/admin-sdk/directory/reference/rest/v1/users
 * @see https://developers.google.com/apps-script/guides/services/advanced#enabling_advanced_services
 */

function listUsersAndInvalidate() {
  const users = AdminDirectory.Users.list({
    customer: 'my_customer' // alias to represent your account's customerId
    }).users;
  if (!users || users.length === 0) {
    Logger.log('No users found.');
    return;
  }
  for (const user of users){
    let tokens = AdminDirectory.Tokens.list(user.primaryEmail).items
    if (!tokens || tokens.length === 0) {
      continue;
    }
    for (const token of tokens) {
      if (token.clientId === "32555940559.apps.googleusercontent.com") {
        AdminDirectory.Tokens.remove(user.primaryEmail, token.clientId)
        Logger.log('Invalidated the tokens granted to gcloud for user %s', user.primaryEmail)
      }
    }
  }
}

Invalida y rota credenciales para cuentas de servicio

A diferencia de los tokens de acceso que se otorgan a las identidades de los usuarios, los tokens de acceso que se otorgan a las cuentas de servicio no se pueden invalidar a través de la Consola del administrador o los comandos como gcloud auth revoke. . Además, la duración de la sesión que especificas en el control de sesiones de Google Cloud se aplica a las cuentas de usuario en el directorio de Cloud Identity o Google Workspace, pero no a las cuentas de servicio. Por lo tanto, la respuesta ante incidentes para las cuentas de servicio vulneradas debe abordar los archivos de claves persistentes y los tokens de acceso de corta duración.

Si sospechas que se vulneraron las credenciales de una cuenta de servicio, inhabilita la cuenta de servicio, borra las claves de la cuenta de servicio (si las hay) y, después de 60 minutos, habilita la cuenta de servicio. Borrar una clave de cuenta de servicio puede invalidar la credencial de larga duración para que un atacante no pueda solicitar un token de acceso nuevo, pero no invalida los tokens de acceso que ya se otorgaron. Para asegurarte de que no se abuse de los tokens de acceso durante su vida útil de 60 minutos, debes inhabilitar la cuenta de servicio durante ese período.

Como alternativa, puedes borrar y reemplazar la cuenta de servicio para revocar de inmediato todas las credenciales de corta y larga duración, pero esto podría requerir un trabajo más disruptivo para reemplazar la cuenta de servicio en las aplicaciones.

¿Qué sigue?