Português - Ht Cloud
HackTricks TrainingTwitterLinkedinSponsor

GCP - Basic Information

Suporte ao HackTricks

Hierarquia de recursos

O Google Cloud usa uma Hierarquia de recursos que é semelhante, conceitualmente, à de um sistema de arquivos tradicional. Isso fornece um fluxo de trabalho lógico de pai/filho com pontos de anexo específicos para políticas e permissões.

Em um nível alto, parece assim:

Organization
--> Folders
--> Projects
--> Resources

Uma máquina virtual (chamada de Compute Instance) é um recurso. Um recurso reside em um projeto, provavelmente ao lado de outras Compute Instances, buckets de armazenamento, etc.

Migração de Projetos

É possível migrar um projeto sem nenhuma organização para uma organização com as permissões roles/resourcemanager.projectCreator e roles/resourcemanager.projectMover. Se o projeto estiver dentro de outra organização, é necessário entrar em contato com o suporte do GCP para movê-lo para fora da organização primeiro. Para mais informações, consulte isso.

Políticas de Organização

Permitem centralizar o controle sobre os recursos em nuvem da sua organização:

  • Centralizar o controle para configurar restrições sobre como os recursos da sua organização podem ser usados.

  • Definir e estabelecer guardrails para suas equipes de desenvolvimento permanecerem dentro dos limites de conformidade.

  • Ajudar os proprietários de projetos e suas equipes a se moverem rapidamente sem se preocupar em quebrar a conformidade.

Essas políticas podem ser criadas para afetar a organização completa, pasta(s) ou projeto(s). Os descendentes do nó da hierarquia de recursos alvo herdam a política da organização.

Para definir uma política de organização, você escolhe uma restrição, que é um tipo particular de restrição contra um serviço do Google Cloud ou um grupo de serviços do Google Cloud. Você configura essa restrição com suas restrições desejadas.

Casos de uso comuns

  • Limitar o compartilhamento de recursos com base no domínio.

  • Limitar o uso de contas de serviço do Identity and Access Management.

  • Restringir a localização física de recursos recém-criados.

  • Desabilitar a criação de contas de serviço.

Existem muitas outras restrições que oferecem controle detalhado sobre os recursos da sua organização. Para mais informações, veja a lista de todas as restrições do Serviço de Política de Organização.

Políticas de Organização Padrão

Estas são as políticas que o Google adicionará por padrão ao configurar sua organização GCP:

Políticas de Gerenciamento de Acesso

  • Contatos restritos por domínio: Impede a adição de usuários a Contatos Essenciais fora dos domínios especificados. Isso limita os Contatos Essenciais a permitir apenas identidades de usuários gerenciados em seus domínios selecionados para receber notificações da plataforma.

  • Compartilhamento restrito por domínio: Impede a adição de usuários a políticas IAM fora dos domínios especificados. Isso limita as políticas IAM a permitir apenas identidades de usuários gerenciados em seus domínios selecionados para acessar recursos dentro desta organização.

  • Prevenção de acesso público: Impede que buckets do Cloud Storage sejam expostos ao público. Isso garante que um desenvolvedor não possa configurar buckets do Cloud Storage para ter acesso à internet não autenticado.

  • Acesso uniforme ao nível do bucket: Impede listas de controle de acesso (ACLs) em nível de objeto em buckets do Cloud Storage. Isso simplifica seu gerenciamento de acesso aplicando políticas IAM de forma consistente em todos os objetos nos buckets do Cloud Storage.

  • Exigir login do SO: VMs criadas em novos projetos terão o Login do SO habilitado. Isso permite que você gerencie o acesso SSH às suas instâncias usando IAM sem precisar criar e gerenciar chaves SSH individuais.

Políticas de segurança adicionais para contas de serviço

  • Desabilitar concessões automáticas de IAM: Impede que as contas de serviço padrão do App Engine e do Compute Engine sejam automaticamente concedidas o papel de Editor IAM em um projeto na criação. Isso garante que as contas de serviço não recebam papéis IAM excessivamente permissivos ao serem criadas.

  • Desabilitar a criação de chaves de conta de serviço: Impede a criação de chaves de conta de serviço públicas. Isso ajuda a reduzir o risco de expor credenciais persistentes.

  • Desabilitar o upload de chaves de conta de serviço: Impede o upload de chaves de conta de serviço públicas. Isso ajuda a reduzir o risco de vazamento ou reutilização de material de chave.

Políticas de configuração de rede VPC seguras

  • Definir IPs externos permitidos para instâncias VM: Impede a criação de instâncias Compute com um IP público, o que pode expô-las ao tráfego da internet.

  • Desabilitar virtualização aninhada de VM: Impede a criação de VMs aninhadas em VMs do Compute Engine. Isso diminui o risco de segurança de ter VMs aninhadas não monitoradas.

  • Desabilitar porta serial de VM: Impede o acesso à porta serial das VMs do Compute Engine. Isso impede a entrada na porta serial de um servidor usando a API do Compute Engine.

  • Restringir redes autorizadas em instâncias do Cloud SQL: Impede que intervalos de rede públicos ou não internos acessem seus bancos de dados do Cloud SQL.

  • Restringir o encaminhamento de protocolo com base no tipo de endereço IP: Impede o encaminhamento de protocolo de VM para endereços IP externos.

  • Restringir acesso IP público em instâncias do Cloud SQL: Impede a criação de instâncias do Cloud SQL com um IP público, o que pode expô-las ao tráfego da internet.

  • Restringir a remoção de ônus de projeto VPC compartilhado: Impede a exclusão acidental de projetos host VPC compartilhados.

  • Define a configuração DNS interna para novos projetos como Apenas DNS Zonal: Impede o uso de uma configuração DNS legada que reduziu a disponibilidade do serviço.

  • Pular a criação de rede padrão: Impede a criação automática da rede VPC padrão e recursos relacionados. Isso evita regras de firewall padrão excessivamente permissivas.

  • Desabilitar uso de IPv6 externo VPC: Impede a criação de sub-redes IPv6 externas, que podem ser expostas a acesso não autorizado à internet.

Papéis IAM

Estes são como políticas IAM no AWS, pois cada papel contém um conjunto de permissões.

No entanto, ao contrário do AWS, não há um repositório centralizado de papéis. Em vez disso, recursos dão X papéis de acesso a Y principais, e a única maneira de descobrir quem tem acesso a um recurso é usar o método get-iam-policy sobre esse recurso. Isso pode ser um problema porque isso significa que a única maneira de descobrir quais permissões um principal tem é perguntar a cada recurso a quem ele está concedendo permissões, e um usuário pode não ter permissões para obter permissões de todos os recursos.

Existem três tipos de papéis no IAM:

  • Papéis Básicos/Primitivos, que incluem os papéis de Proprietário, Editor e Visualizador que existiam antes da introdução do IAM.

  • Papéis Predefinidos, que fornecem acesso granular para um serviço específico e são gerenciados pelo Google Cloud. Existem muitos papéis predefinidos, você pode ver todos eles com os privilégios que possuem aqui.

  • Papéis Personalizados, que fornecem acesso granular de acordo com uma lista de permissões especificada pelo usuário.

Existem milhares de permissões no GCP. Para verificar se um papel tem uma permissão, você pode pesquisar a permissão aqui e ver quais papéis a possuem.

Você também pode pesquisar aqui papéis predefinidos oferecidos por cada produto. Observe que alguns papéis não podem ser anexados a usuários e apenas a SAs devido a algumas permissões que contêm. Além disso, observe que as permissões só terão efeito se estiverem anexadas ao serviço relevante.

Ou verifique se um papel personalizado pode usar uma permissão específica aqui.

Usuários

Na console do GCP não há gerenciamento de Usuários ou Grupos, isso é feito no Google Workspace. Embora você possa sincronizar um provedor de identidade diferente no Google Workspace.

Você pode acessar os usuários e grupos do Workspaces em https://admin.google.com.

MFA pode ser forçada para usuários do Workspaces, no entanto, um atacante pode usar um token para acessar o GCP via cli que não estará protegido por MFA (ele estará protegido por MFA apenas quando o usuário fizer login para gerá-lo: gcloud auth login).

Grupos

Quando uma organização é criada, vários grupos são fortemente sugeridos para serem criados. Se você gerenciar algum deles, pode ter comprometido toda ou uma parte importante da organização:

Política de Senha Padrão

  • Impor senhas fortes

  • Entre 8 e 100 caracteres

  • Sem reutilização

  • Sem expiração

  • Se as pessoas estiverem acessando o Workspace através de um provedor de terceiros, esses requisitos não são aplicados.

Contas de serviço

Estas são os principais que recursos podem ter anexados e acesso para interagir facilmente com o GCP. Por exemplo, é possível acessar o token de autenticação de uma Conta de Serviço anexada a uma VM nos metadados. É possível encontrar alguns conflitos ao usar tanto IAM quanto escopos de acesso. Por exemplo, sua conta de serviço pode ter o papel IAM de compute.instanceAdmin, mas a instância que você invadiu foi limitada com a limitação de escopo de https://www.googleapis.com/auth/compute.readonly. Isso impediria que você fizesse quaisquer alterações usando o token OAuth que é automaticamente atribuído à sua instância.

É semelhante aos papéis IAM do AWS. Mas, ao contrário do AWS, qualquer conta de serviço pode ser anexada a qualquer serviço (não precisa permitir isso por meio de uma política).

Várias das contas de serviço que você encontrará são, na verdade, geradas automaticamente pelo GCP quando você começa a usar um serviço, como:

PROJECT_NUMBER-compute@developer.gserviceaccount.com
PROJECT_ID@appspot.gserviceaccount.com

No entanto, também é possível criar e anexar a recursos contas de serviço personalizadas, que terão a seguinte aparência:

SERVICE_ACCOUNT_NAME@PROJECT_NAME.iam.gserviceaccount.com

Chaves e Tokens

Existem 2 maneiras principais de acessar o GCP como uma conta de serviço:

  • Via tokens OAuth: Esses são tokens que você obterá de lugares como endpoints de metadados ou roubando requisições http e são limitados pelos escopos de acesso.

  • Chaves: Esses são pares de chaves públicas e privadas que permitirão que você assine requisições como a conta de serviço e até mesmo gere tokens OAuth para realizar ações como a conta de serviço. Essas chaves são perigosas porque são mais complicadas de limitar e controlar, por isso o GCP recomenda não gerá-las.

  • Note que toda vez que uma SA é criada, o GCP gera uma chave para a conta de serviço que o usuário não pode acessar (e não será listada na aplicação web). De acordo com este tópico, essa chave é usada internamente pelo GCP para dar acesso aos endpoints de metadados para gerar os tokens OAuth acessíveis.

Escopos de Acesso

Os escopos de acesso são anexados aos tokens OAuth gerados para acessar os endpoints da API do GCP. Eles restrigem as permissões do token OAuth. Isso significa que se um token pertence a um Proprietário de um recurso, mas não tem no escopo do token acesso a esse recurso, o token não pode ser usado para (ab)usar esses privilégios.

O Google na verdade recomenda que os escopos de acesso não sejam usados e que se confie totalmente no IAM. O portal de gerenciamento web realmente impõe isso, mas os escopos de acesso ainda podem ser aplicados a instâncias usando contas de serviço personalizadas programaticamente.

Você pode ver quais escopos estão atribuídos consultando:

curl 'https://www.googleapis.com/oauth2/v1/tokeninfo?access_token=<access_token>'

{
"issued_to": "223044615559.apps.googleusercontent.com",
"audience": "223044615559.apps.googleusercontent.com",
"user_id": "139746512919298469201",
"scope": "openid https://www.googleapis.com/auth/userinfo.email https://www.googleapis.com/auth/cloud-platform https://www.googleapis.com/auth/appengine.admin https://www.googleapis.com/auth/sqlservice.login https://www.googleapis.com/auth/compute https://www.googleapis.com/auth/accounts.reauth",
"expires_in": 2253,
"email": "username@testing.com",
"verified_email": true,
"access_type": "offline"
}

Os escopos anteriores são os gerados por padrão usando gcloud para acessar dados. Isso ocorre porque, ao usar gcloud, você primeiro cria um token OAuth e, em seguida, o utiliza para contatar os endpoints.

O escopo mais importante entre eles potencialmente é cloud-platform, que basicamente significa que é possível acessar qualquer serviço no GCP.

Você pode encontrar uma lista de todos os escopos possíveis aqui.

Se você tiver credenciais de navegador gcloud, é possível obter um token com outros escopos, fazendo algo como:

# Maybe you can get a user token with other scopes changing the scopes array from ~/.config/gcloud/credentials.db

# Set new scopes for SDKs credentials
gcloud auth application-default login --scopes=https://www.googleapis.com/auth/userinfo.email,https://www.googleapis.com/auth/cloud-platform,https://www.googleapis.com/auth/sqlservice.login,https://www.googleapis.com/auth/appengine.admin,https://www.googleapis.com/auth/compute,https://www.googleapis.com/auth/accounts.reauth,https://www.googleapis.com/auth/admin.directory.user,https://www.googleapis.com/auth/admin.directory.group,https://www.googleapis.com/auth/admin.directory.domain,https://www.googleapis.com/auth/admin.directory.user

# Print new token
gcloud auth application-default print-access-token

# To use this token with some API you might need to use curl to indicate the project header with --header "X-Goog-User-Project: <project-name>"

Políticas, Vínculos e Membros IAM do Terraform

Conforme definido pelo terraform em https://registry.terraform.io/providers/hashicorp/google/latest/docs/resources/google_project_iam, usando terraform com GCP, existem diferentes maneiras de conceder a um principal acesso a um recurso:

  • Membros: Você define principais como membros de papéis sem restrições sobre o papel ou os principais. Você pode colocar um usuário como membro de um papel e, em seguida, colocar um grupo como membro do mesmo papel e também definir esses principais (usuário e grupo) como membros de outros papéis.

  • Vínculos: Vários principais podem ser vinculados a um papel. Esses principais ainda podem ser vinculados ou ser membros de outros papéis. No entanto, se um principal que não está vinculado ao papel for definido como membro de um papel vinculado, na próxima vez que o vínculo for aplicado, a associação desaparecerá.

  • Políticas: Uma política é autoritativa, indica papéis e principais e, então, esses principais não podem ter mais papéis e esses papéis não podem ter mais principais a menos que essa política seja modificada (nem mesmo em outras políticas, vínculos ou associações). Portanto, quando um papel ou principal é especificado na política, todos os seus privilégios são limitados por essa política. Obviamente, isso pode ser contornado caso o principal tenha a opção de modificar a política ou permissões de escalonamento de privilégios (como criar um novo principal e vinculá-lo a um novo papel).

Referências

Support HackTricks
PreviousGCP PentestingNextGCP - Federation Abuse

Last updated