O Google Cloud abordou uma falha de segurança de gravidade média em sua plataforma que poderia ser explorada por um invasor que já tem acesso a um cluster do Kubernetes para escalar seus privilégios.
"Um invasor que comprometeu o contêiner de registro do Fluent Bit poderia combinar esse acesso com altos privilégios exigidos pelo Anthos Service Mesh (em clusters que o habilitaram) para escalar privilégios no cluster", disse a empresa como parte de um aviso divulgado em 14 de dezembro de 2023.
Palo Alto Networks Unit 42, que descobriu e relatou a deficiência, disse que os adversários poderiam utilizá-la para realizar "roubo de dados, implantar pods maliciosos, e interromper as operações do cluster."
Não há evidências de que o problema tenha sido explorado na prática.
Ele foi abordado nas versões seguintes do Google Kubernetes Engine (GKE) e Anthos Service Mesh (ASM) -
1.25.16-gke.1020000
1.26.10-gke.1235000
1.27.7-gke.1293000
1.28.4-gke.1083000
1.17.8-asm.8
1.18.6-asm.2
1.19.5-asm.4
Um pré-requisito fundamental para explorar com sucesso a vulnerabilidade depende de um invasor já ter comprometido um contêiner FluentBit por meio de alguns outros métodos de acesso inicial, como por meio de uma falha de execução de código remoto.
"O GKE usa o Fluent Bit para processar registros para workloads em execução em clusters", explicou o Google.
"Fluent Bit no GKE também foi configurado para coletar registros para workloads do Cloud Run.
O volume montado configurado para coletar esses registros deu ao Fluent Bit acesso aos tokens de conta de serviço Kubernetes para outros Pods em execução no nó."
Isso significava que um agente de ameaça poderia usar esse acesso para obter acesso privilegiado a um cluster do Kubernetes que tem o ASM habilitado e depois usar o token da conta de serviço do ASM para escalar seus privilégios, criando um novo pod com privilégios de administrador do cluster.
"A conta do serviço clusterrole-aggregation-controller (CRAC) provavelmente é a candidata principal, pois pode adicionar permissões arbitrárias aos papéis de cluster existentes", disse o pesquisador de segurança Shaul Ben Hai.
"O invasor pode atualizar o papel do cluster vinculado ao CRAC para possuir todos os privilégios."
Como correções, o Google removeu o acesso do Fluent Bit aos tokens da conta de serviço e re-arquitetou a funcionalidade do ASM para remover permissões excessivas de controle de acesso baseado em função (RBAC).
"Os fornecedores de nuvem criam automaticamente pods do sistema quando seu cluster é lançado", concluiu Ben Hai.
"Eles são construídos em sua infraestrutura Kubernetes, como os pods adicionais criados quando você habilita um recurso."
"Isso ocorre porque os fornecedores de aplicativos ou nuvem geralmente os criam e gerenciam, e o usuário não tem controle sobre sua configuração ou permissões.
Isso também pode ser extremamente arriscado, pois esses pods são executados com privilégios elevados."
Publicidade
Em 14 de janeiro a Solyd irá revolucionar a forma como pentest e hacking deve ser ensinado. Se inscreva para ser o primeiro a saber das novidades. Saiba mais...