GCP - IAM Privesc
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Encontre mais informações sobre IAM em:
GCP - IAM, Principals & Org Policies Enumiam.roles.update
(iam.roles.get
)Um atacante com as permissões mencionadas poderá atualizar um papel atribuído a você e lhe conceder permissões extras para outros recursos como:
Você pode encontrar um script para automatizar a criação, exploração e limpeza de um ambiente vulnerável aqui e um script em python para abusar desse privilégio aqui. Para mais informações, consulte a pesquisa original.
iam.serviceAccounts.getAccessToken
(iam.serviceAccounts.get
)Um atacante com as permissões mencionadas será capaz de solicitar um token de acesso que pertence a uma Conta de Serviço, então é possível solicitar um token de acesso de uma Conta de Serviço com mais privilégios do que os nossos.
Você pode encontrar um script para automatizar a criação, exploração e limpeza de um ambiente vulnerável aqui e um script em python para abusar desse privilégio aqui. Para mais informações, consulte a pesquisa original.
iam.serviceAccountKeys.create
Um atacante com as permissões mencionadas poderá criar uma chave gerenciada pelo usuário para uma Conta de Serviço, o que nos permitirá acessar o GCP como essa Conta de Serviço.
Você pode encontrar um script para automatizar a criação, exploração e limpeza de um ambiente vulnerável aqui e um script em python para abusar desse privilégio aqui. Para mais informações, consulte a pesquisa original.
Observe que iam.serviceAccountKeys.update
não funcionará para modificar a chave de uma SA porque, para fazer isso, as permissões iam.serviceAccountKeys.create
também são necessárias.
iam.serviceAccounts.implicitDelegation
Se você tiver a iam.serviceAccounts.implicitDelegation
permissão em uma Conta de Serviço que tem a permissão iam.serviceAccounts.getAccessToken
em uma terceira Conta de Serviço, então você pode usar implicitDelegation para criar um token para essa terceira Conta de Serviço. Aqui está um diagrama para ajudar a explicar.
Observe que, de acordo com a documentação, a delegação do gcloud
só funciona para gerar um token usando o método generateAccessToken(). Então aqui está como obter um token usando a API diretamente:
Você pode encontrar um script para automatizar a criação, exploração e limpeza de um ambiente vulnerável aqui e um script em python para abusar desse privilégio aqui. Para mais informações, consulte a pesquisa original.
iam.serviceAccounts.signBlob
Um atacante com as permissões mencionadas será capaz de assinar cargas úteis arbitrárias no GCP. Assim, será possível criar um JWT não assinado da SA e, em seguida, enviá-lo como um blob para obter o JWT assinado pela SA que estamos visando. Para mais informações, leia isso.
Você pode encontrar um script para automatizar a criação, exploração e limpeza de um ambiente vulnerável aqui e um script em python para abusar desse privilégio aqui e aqui. Para mais informações, consulte a pesquisa original.
iam.serviceAccounts.signJwt
Um atacante com as permissões mencionadas será capaz de assinar tokens web JSON (JWTs) bem formados. A diferença em relação ao método anterior é que em vez de fazer o google assinar um blob contendo um JWT, usamos o método signJWT que já espera um JWT. Isso facilita o uso, mas você só pode assinar JWT em vez de qualquer byte.
Você pode encontrar um script para automatizar a criação, exploração e limpeza de um ambiente vulnerável aqui e um script em python para abusar desse privilégio aqui. Para mais informações, consulte a pesquisa original.
iam.serviceAccounts.setIamPolicy
Um atacante com as permissões mencionadas será capaz de adicionar políticas IAM a contas de serviço. Você pode abusar disso para conceder a si mesmo as permissões necessárias para se passar pela conta de serviço. No exemplo a seguir, estamos nos concedendo o papel roles/iam.serviceAccountTokenCreator
sobre a SA interessante:
Você pode encontrar um script para automatizar a criação, exploração e limpeza de um ambiente vulnerável aqui.
iam.serviceAccounts.actAs
A permissão iam.serviceAccounts.actAs é como a permissão iam:PassRole da AWS. É essencial para executar tarefas, como iniciar uma instância do Compute Engine, pois concede a capacidade de "agir como" uma Conta de Serviço, garantindo uma gestão de permissões segura. Sem isso, os usuários podem obter acesso indevido. Além disso, explorar a iam.serviceAccounts.actAs envolve vários métodos, cada um exigindo um conjunto de permissões, ao contrário de outros métodos que precisam apenas de uma.
Impersonar uma conta de serviço pode ser muito útil para obter novas e melhores permissões. Existem três maneiras de impersonar outra conta de serviço:
Autenticação usando chaves privadas RSA (coberto acima)
Autorização usando políticas do Cloud IAM (coberto aqui)
Implantando trabalhos em serviços do GCP (mais aplicável à compromissão de uma conta de usuário)
iam.serviceAccounts.getOpenIdToken
Um atacante com as permissões mencionadas será capaz de gerar um OpenID JWT. Estes são usados para afirmar identidade e não necessariamente carregam qualquer autorização implícita contra um recurso.
De acordo com este post interessante, é necessário indicar o público (serviço onde você deseja usar o token para autenticar) e você receberá um JWT assinado pelo google indicando a conta de serviço e o público do JWT.
Você pode gerar um OpenIDToken (se tiver acesso) com:
Então você pode usá-lo para acessar o serviço com:
Alguns serviços que suportam autenticação via esse tipo de tokens são:
Google Cloud Endpoints (se usando Google OIDC)
Você pode encontrar um exemplo de como criar um token OpenID em nome de uma conta de serviço aqui.
Aprenda e pratique Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Aprenda e pratique Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)