Introdução
A Orca Security identificou recentemente uma falha de design no serviço Google Cloud Build, chamada “Bad.Build”. Esta falha representa um sério risco de segurança, pois permite que os invasores executem o escalonamento de privilégios, garantindo-lhes entrada não autorizada nos repositórios de código do Artifact Registry do Google.
As consequências desta vulnerabilidade estendem-se à cadeia de fornecimento de software, uma vez que os atacantes podem explorá-la para manipular imagens de aplicações com intenções maliciosas. Consequentemente, usuários e clientes desavisados que instalam aplicativos adulterados podem ser vítimas de infecções.
Esta situação lembra-nos o impacto significativo testemunhado em ataques passados à cadeia de abastecimento, como o SolarWinds, 3CX e Mova isso, enfatizando as implicações de longo alcance de tais lapsos de segurança.
Como funciona?
Google Criação de nuvem representa uma integração contínua/entrega contínua (CI/CD) serviço oferecido dentro do ecossistema do Google Cloud. Ele desempenha um papel vital em aplicativos baseados em nuvem ao interagir perfeitamente com outros serviços essenciais, como o Artifact Registry e o App Engine.
A falha em questão resulta de um problema com privilégios excessivos. Especificamente, o “registro.privateLogEntries.list”a ação permite inadvertidamente a listagem de logs de auditoria para uma função não intencional, a saber“funções/cloudbuild.builds.builder. "
Lamentavelmente, esta função padrão é atribuída à conta de serviço de construção em nuvem. Esta situação representa um grave risco, uma vez que os registos de auditoria contêm informações sensíveis, revelando todas as permissões associadas ao projeto. Esse acesso não intencional concede aos invasores a capacidade de se passar pela conta do Cloud Build, adquirindo assim conhecimento sobre quais ações podem ser executadas por diferentes contas do Google. Consequentemente, isto abre a porta ao movimento lateral e à escalada de privilégios, apresentando uma vulnerabilidade de segurança extremamente perigosa.
Representar a conta de serviço de build requer apenas o cloudbuild.builds.create permissão, que muitas funções predefinidas têm e que são concedidas aos desenvolvedores em qualquer situação razoável CI/CD ambiente usando o Cloud Build. Portanto, se você tiver acesso a uma dessas contas de desenvolvedor, criar um arquivo de configuração de build personalizado executará o Comando de leitura de registro do gcloud, que listará as permissões.
Mas o problema não termina aqui: o A conta de serviço do Google Cloud Build é altamente privilegiada, com muitas ações para interagir com o Artifact Registry do Goggle.
Explorando a vulnerabilidade que permite a representação da conta de serviço padrão do Cloud Build, atores mal-intencionados ganham a capacidade de adulterar imagens armazenadas no Artifact Registry do Google, injetando código malicioso. Consequentemente, quaisquer aplicativos criados a partir dessas imagens comprometidas tornam-se suscetíveis a possíveis consequências, incluindo ataques de negação de serviço (DoS), roubo de dados e disseminação de malware.
A gravidade da situação aumenta quando essas aplicações manipuladas se destinam à implantação em ambientes de clientes, quer on-premise ou semi-SaaS. Isso expande o risco além da infraestrutura da organização fornecedora, levando a um ataque à cadeia de suprimentos que se infiltra e compromete os ambientes dos clientes. Esses ataques são semelhantes a incidentes anteriores vistos em violações da cadeia de suprimentos de software, como a violação da SolarWinds. As implicações de tal ataque podem ser graves, causando danos generalizados e afetando várias organizações dentro da cadeia de suprimentos
Houve um PoC de escalonamento de privilégios semelhante por Laboratórios de segurança do rinoceronte, que explorou de forma diferente os privilégios excessivos da conta padrão do Cloud Build.
Por que é perigoso?
A gravidade desta vulnerabilidade reside no potencial para que os invasores explorem o Artifact Registry e introduzam código malicioso nos artefatos. Como resultado, quaisquer aplicativos criados a partir dessas imagens comprometidas tornam-se suscetíveis a vários efeitos adversos.
Esses efeitos incluem a possibilidade de ataques de negação de serviço, roubo de dados e propagação de malware. Além disso, se esses aplicativos comprometidos forem posteriormente implantados on-premise ou em um ambiente semi-SaaS, o risco se estende além da organização vítima para impactar seus clientes também. Este cenário se assemelha ao ataque à cadeia de suprimentos testemunhado no incidente da SolarWinds, destacando as consequências potenciais tanto para a organização quanto para sua base de clientes.
-
Recomendação Xygeni
Aplique o princípio do menor privilégio
- Sensor Xigeni monitora as ações dos usuários nos sistemas onde está implantado e as compartilha com nossa plataforma principal, que identifica comportamentos incomuns ou desvios dos padrões normais, como Conecte-se horários ou locais, grandes transferências de dados ou alterações nos direitos de acesso do usuário que estão fora do comportamento “normal” do usuário modelado.
As políticas e auditoria da Xygeni aplicam as melhores práticas em controles de acesso, requisitos de autenticação multifatorial e aplicativos de permissões baseadas em funções para limitar o acesso do usuário a sistemas e dados críticos.
Essas ferramentas monitoram as ações do usuário, como alterações de código, acesso ao sistema ou transferências de dados, e as comparam com políticas e padrões comportamentais predefinidos. Eles também sinalizam atividades suspeitas, como acesso não autorizado, privilégios excessivos ou padrões incomuns de transferência de dados..
Como a vulnerabilidade foi tratada
Ao notificar a equipe de segurança do Google sobre a vulnerabilidade, eles agiram revogando a permissão logging.privateLogEntries.list da conta de serviço padrão do Cloud Build. Eles reconheceram que, embora os logs de auditoria setIamPolicy sejam relevantes para fins de auditoria, era desnecessário conceder acesso a esses logs da perspectiva da conta de serviço de criação de nuvem.
No entanto, é crucial compreender que esta resposta não abordou diretamente a vulnerabilidade raiz no Artifact Registry. Como resultado, o vetor de escalada de privilégios e o risco potencial de um ataque à cadeia de abastecimento permaneceram inalterados. Essencialmente, a correção do Google limitou o problema, mas não o eliminou totalmente, deixando as organizações ainda expostas a riscos significativos na cadeia de fornecimento de software.
Em resposta à situação, o Google aconselhou seus clientes a modificar as permissões da conta de serviço padrão do Cloud Build, removendo quaisquer credenciais de direito que se desviassem do Princípio do Menor Privilégio (PoLP). Esta medida visa aumentar a segurança, garantindo que as contas tenham apenas os privilégios mínimos necessários para executar as tarefas pretendidas.
Para se defender contra esse ataque de escalonamento de privilégios, é necessário restringir as permissões concedidas à conta de serviço Cloud Build e ter cuidado ao conceder o cloudbuild.builds.create permissão para qualquer usuário em sua organização. Mais importante ainda, você precisa saber que qualquer usuário que receba cloudbuild.builds.create, também recebe indiretamente todas as permissões concedidas à conta de serviço do Cloud Build. Se estiver tudo bem para você, talvez não precise se preocupar com esse vetor de ataque, mas ainda é altamente recomendável modificar as permissões padrão concedidas à conta de serviço do Cloud Build.
Google recomenda isso sucintamente, mas não fornece mais detalhes:
“Se você não planeja realizar uma ação como parte do processo de construção, recomendamos que você revogue a permissão correspondente da conta de serviço Cloud Build para cumprir o princípio de segurança de privilégio mínimo.”
Timeline
No entanto, é essencial observar que a solução do Google não eliminou totalmente o vetor descoberto de escalonamento de privilégios (PE). Em vez disso, restringiu o seu impacto, transformando-o efetivamente numa falha de design que ainda expõe as organizações ao risco mais amplo de um ataque à cadeia de abastecimento. Consequentemente, são necessárias medidas adicionais para que as equipas de segurança se protejam contra este risco persistente.
Conclusão
Privilégios excessivos concedidos à conta padrão do Google Cloud Build podem ser aproveitados por adversários para montar um ataque usando uma conta de desenvolvedor que permite criar uma construção em nuvem. Os invasores podem exfiltrar uma imagem de contêiner, adulterá-la com comportamento malicioso e, em seguida, enviá-la para o Artifact Registry, em um ataque à cadeia de fornecimento de software que pode ter consequências devastadoras.
A resposta do Google deixa o trabalho de mitigação para as organizações que usam o serviço Cloud Build, que precisam revogar os privilégios para controlar o risco. Pode-se pedir ao Google para fornecer ajuda adicional no futuro para lidar com problemas de segurança com seus CI/CD sistema.
Referências
- Funcionando conforme pretendido: escalonamento de privilégios de RCE para IAM no GCP Cloud Build. Laboratórios de segurança Rhino.
- Bad.Build: Vulnerabilidades PE e RCE no Google Cloud Build. Orca Segurança.
- Boletim de Segurança. Google Nuvem.
Saiba mais sobre a Plataforma Xygeni, baixe o datasheet da plataforma Xygeni
