0
0
Uma vulnerabilidade recém-descoberta no Google Cloud Build permite que invasores adulterem e injetem malware em imagens armazenadas no Artifact Registry, o repositório do Google para hospedar artefatos de software, como pacotes e imagens de contêineres.
Quaisquer aplicativos que façam uso dessas imagens de contêiner comprometidas correm o risco de infecções por malware, ataques de negação de serviço, roubo de dados e outros impactos negativos.
O Problema Bad.Build
Pesquisadores da Orca Security descobriram recentemente a falha, que eles apelidaram de Bad.Build, ao analisar uma solicitação de chamada de interface de programação de aplicativo (API) associada a um recurso da plataforma de nuvem do Google. Eles relataram o problema ao Google, que investigou o problema e emitiu uma correção para ele em junho.
No entanto, a Orca, em um relatório desta semana , descreveu a correção como insuficiente e abordando apenas parcialmente a vulnerabilidade.
“A falha apresenta um risco significativo na cadeia de suprimentos, pois permite que os invasores adulterem maliciosamente as imagens do aplicativo, que podem infectar usuários e clientes quando instalam o aplicativo”, disse Roi Nisimi, pesquisador de ameaças à nuvem da Orca. “Como vimos com a SolarWinds e os recentes ataques à cadeia de suprimentos 3CX e MOVEit , isso pode ter consequências de longo alcance”.
De acordo com Orca, a falha Bad.Build é realmente um problema de design e tem a ver com as permissões padrão associadas ao serviço Google Cloud Build. As permissões excessivas associadas ao serviço oferecem aos adversários uma maneira relativamente fácil de acessar os registros de auditoria que contêm uma lista completa de permissões associadas a todas as contas do GCP em um “projeto” do Google Cloud Build.
“O que torna essa informação tão lucrativa é que ela facilita muito o movimento lateral e a escalada de privilégios no ambiente”, disse Nisimi. “Saber qual conta do GCP pode executar qual ação é igual a resolver uma grande peça do quebra-cabeça sobre como lançar um ataque.”
Os pesquisadores da Orca descobriram que, ao usar uma conta do GCP com permissão para criar uma nova compilação (cloudbuild.builds.create), eles poderiam representar com relativa facilidade a conta Cloud Build Service e visualizar todas as permissões do projeto. “Um invasor precisaria ter acesso à permissão cloudbuild.builds.create, que pode ser obtida por acesso interno ou por um estranho que obteve acesso não autorizado a um usuário com essa permissão”, disse Nisimi, em comentários ao Dark Reading .
Simples de Explorar
“Eles precisariam executar apenas três linhas de código para criar uma imagem pública do Gcloud nos servidores do Cloud Build e executar os comandos conforme mostrado em nossa prova de conceito para escalar os privilégios do usuário e executar qualquer ação que a conta de serviço do Cloud Build seja permitida. para atuar”, diz.
A correção do Google para Bad.Build remove a permissão de registro da função de serviço padrão do Google Cloud Build, o que significa que determinado serviço não tem mais acesso aos logs de auditoria que listam todas as permissões do projeto sempre que há uma alteração, observa Nisimi.
No entanto, há toda uma lista de outras funções com a permissão cloudbuild.builds.create que podem fazer a mesma coisa. Qualquer usuário com a permissão cloudbuild.builds.create pode escalar privilégios e executar uma ampla gama de ações – incluindo manipular imagens e injetar código malicioso nelas – a menos que as organizações revoguem especificamente as permissões padrão do serviço Google Cloud Build, diz ele.
Uma porta-voz do Google tinha pouco a dizer sobre a falha ou as reivindicações de uma correção parcial. “Agradecemos o trabalho dos pesquisadores e incorporamos uma correção com base em seu relatório, conforme descrito em um boletim de segurança divulgado no início de junho”, disse ela.
Privilégios Limitantes
Quando os usuários ativam a API do Cloud Build em um projeto, o Cloud Build cria automaticamente uma conta de serviço padrão para executar compilações em nome do usuário, de acordo com o comunicado do Google sobre a vulnerabilidade. Essa conta de serviço do Cloud Build anteriormente permitia que o build tivesse acesso a logs privados por padrão, mas, como observou o boletim de segurança de 8 de junho, “esta permissão foi revogada da conta de serviço do Cloud Build para aderir ao princípio de segurança de privilégio mínimo . “
De acordo com Nisimi, a posição do Google parece ser que o problema são as permissões padrão que as organizações optam por habilitar para o Cloud Build. Ele diz: “O Google reconhece que há um risco de ataque à cadeia de suprimentos conforme descrito, mas que gira em torno da escolha de permissões padrão que suportam os fluxos de trabalho de desenvolvimento mais comuns”.
A postura do Google é que os clientes são responsáveis por bloquear ainda mais o acesso para cenários mais avançados. “Portanto, o risco da cadeia de suprimentos é persistente e as organizações devem limitar a permissão cloudbuild.builds.create o máximo possível para reduzir o risco de um ataque à cadeia de suprimentos”, diz Nisimi.
FONTE: DARKREADING