Español - Ht Cloud
HackTricks TrainingTwitterLinkedinSponsor

GCP - IAM Privesc

Support HackTricks

IAM

Encuentra más información sobre IAM en:

iam.roles.update (iam.roles.get)

Un atacante con los permisos mencionados podrá actualizar un rol asignado a ti y darte permisos adicionales a otros recursos como:

gcloud iam roles update <rol name> --project <project> --add-permissions <permission>

Puedes encontrar un script para automatizar la creación, explotación y limpieza de un entorno vulnerable aquí y un script de python para abusar de este privilegio aquí. Para más información, consulta la investigación original.

iam.serviceAccounts.getAccessToken (iam.serviceAccounts.get)

Un atacante con los permisos mencionados podrá solicitar un token de acceso que pertenece a una Cuenta de Servicio, por lo que es posible solicitar un token de acceso de una Cuenta de Servicio con más privilegios que los nuestros.

gcloud --impersonate-service-account="${victim}@${PROJECT_ID}.iam.gserviceaccount.com" \
auth print-access-token

Puedes encontrar un script para automatizar la creación, explotación y limpieza de un entorno vulnerable aquí y un script de python para abusar de este privilegio aquí. Para más información, consulta la investigación original.

iam.serviceAccountKeys.create

Un atacante con los permisos mencionados podrá crear una clave gestionada por el usuario para una Cuenta de Servicio, lo que nos permitirá acceder a GCP como esa Cuenta de Servicio.

gcloud iam service-accounts keys create --iam-account <name> /tmp/key.json

gcloud auth activate-service-account --key-file=sa_cred.json

Puedes encontrar un script para automatizar la creación, explotación y limpieza de un entorno vulnerable aquí y un script de python para abusar de este privilegio aquí. Para más información, consulta la investigación original.

Ten en cuenta que iam.serviceAccountKeys.update no funcionará para modificar la clave de un SA porque para hacer eso también se necesita el permiso iam.serviceAccountKeys.create.

iam.serviceAccounts.implicitDelegation

Si tienes el iam.serviceAccounts.implicitDelegation permiso en una Cuenta de Servicio que tiene el iam.serviceAccounts.getAccessToken permiso en una tercera Cuenta de Servicio, entonces puedes usar implicitDelegation para crear un token para esa tercera Cuenta de Servicio. Aquí hay un diagrama para ayudar a explicar.

Ten en cuenta que según la documentación, la delegación de gcloud solo funciona para generar un token utilizando el generateAccessToken() método. Así que aquí tienes cómo obtener un token utilizando la API directamente:

curl -X POST \
'https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/'"${TARGET_SERVICE_ACCOUNT}"':generateAccessToken' \
-H 'Content-Type: application/json' \
-H 'Authorization: Bearer '"$(gcloud auth print-access-token)" \
-d '{
"delegates": ["projects/-/serviceAccounts/'"${DELEGATED_SERVICE_ACCOUNT}"'"],
"scope": ["https://www.googleapis.com/auth/cloud-platform"]
}'

You can find a script to automate the creación, explotación y limpieza de un entorno vulnerable aquí and a python script to abuse this privilege aquí. For more information check the investigación original.

iam.serviceAccounts.signBlob

An attacker with the mentioned permissions will be able to firmar cargas útiles arbitrarias en GCP. So it'll be possible to crear un JWT no firmado del SA y luego enviarlo como un blob para obtener el JWT firmado por el SA que estamos atacando. For more information lee esto.

You can find a script to automate the creación, explotación y limpieza de un entorno vulnerable aquí and a python script to abuse this privilege aquí and aquí. For more information check the investigación original.

iam.serviceAccounts.signJwt

An attacker with the mentioned permissions will be able to firmar tokens web JSON (JWTs) bien formados. The difference with the previous method is that en lugar de hacer que Google firme un blob que contiene un JWT, usamos el método signJWT que ya espera un JWT. This makes it easier to use but you can only sign JWT instead of any bytes.

You can find a script to automate the creación, explotación y limpieza de un entorno vulnerable aquí and a python script to abuse this privilege aquí. For more information check the investigación original.

iam.serviceAccounts.setIamPolicy

An attacker with the mentioned permissions will be able to agregar políticas IAM a cuentas de servicio. You can abuse it to otorgarte the permissions you need to impersonate the service account. In the following example we are granting ourselves the roles/iam.serviceAccountTokenCreator role over the interesting SA:

gcloud iam service-accounts add-iam-policy-binding "${VICTIM_SA}@${PROJECT_ID}.iam.gserviceaccount.com" \
--member="user:username@domain.com" \
--role="roles/iam.serviceAccountTokenCreator"

# If you still have prblem grant yourself also this permission
gcloud iam service-accounts add-iam-policy-binding "${VICTIM_SA}@${PROJECT_ID}.iam.gserviceaccount.com" \ \
--member="user:username@domain.com" \
--role="roles/iam.serviceAccountUser"

Puedes encontrar un script para automatizar la creación, explotación y limpieza de un entorno vulnerable aquí.

iam.serviceAccounts.actAs

El permiso iam.serviceAccounts.actAs es como el permiso iam:PassRole de AWS. Es esencial para ejecutar tareas, como iniciar una instancia de Compute Engine, ya que otorga la capacidad de "actuar como" una Cuenta de Servicio, asegurando una gestión segura de permisos. Sin esto, los usuarios podrían obtener acceso indebido. Además, explotar el iam.serviceAccounts.actAs implica varios métodos, cada uno requiriendo un conjunto de permisos, a diferencia de otros métodos que solo necesitan uno.

Suplantación de cuenta de servicio

Suplantar una cuenta de servicio puede ser muy útil para obtener nuevos y mejores privilegios. Hay tres formas en las que puedes suplantar otra cuenta de servicio:

  • Autenticación usando claves privadas RSA (cubierto arriba)

  • Autorización usando políticas de Cloud IAM (cubierto aquí)

  • Desplegando trabajos en servicios de GCP (más aplicable a la compromisión de una cuenta de usuario)

iam.serviceAccounts.getOpenIdToken

Un atacante con los permisos mencionados podrá generar un OpenID JWT. Estos se utilizan para afirmar la identidad y no necesariamente llevan ninguna autorización implícita contra un recurso.

Según este interesante post, es necesario indicar la audiencia (servicio donde deseas usar el token para autenticarte) y recibirás un JWT firmado por google indicando la cuenta de servicio y la audiencia del JWT.

Puedes generar un OpenIDToken (si tienes acceso) con:

# First activate the SA with iam.serviceAccounts.getOpenIdToken over the other SA
gcloud auth activate-service-account --key-file=/path/to/svc_account.json
# Then, generate token
gcloud auth print-identity-token "${ATTACK_SA}@${PROJECT_ID}.iam.gserviceaccount.com" --audiences=https://example.com

Entonces puedes usarlo para acceder al servicio con:

curl -v -H "Authorization: Bearer id_token" https://some-cloud-run-uc.a.run.app

Algunos servicios que admiten autenticación a través de este tipo de tokens son:

Puedes encontrar un ejemplo de cómo crear un token OpenID en nombre de una cuenta de servicio aquí.

Referencias

Apoya a HackTricks
PreviousGCP - Deploymentmaneger PrivescNextGCP - KMS Privesc

Last updated