Container Escape to Shadow Admin: vulnerabilidades do ‘autopilot’ do GKE

Em fevereiro de 2021, o Google anunciou o Autopilot , um novo modo de operação no Google Kubernetes Engine (GKE).

Sumário executivo

Com o Autopilot, o Google oferece uma experiência Kubernetes “prática”, gerenciando a infraestrutura de cluster para o cliente. A plataforma provisiona e remove automaticamente os nós com base no consumo de recursos e aplica as melhores práticas seguras do Kubernetes prontas para uso.

Em junho de 2021, os pesquisadores da Unidade 42 divulgaram várias vulnerabilidades e técnicas de ataque no GKE Autopilot para o Google. Os usuários capazes de criar um pod podem ter abusado deles para (1) escapar de seu pod e comprometer o nó subjacente, (2) escalar privilégios e se tornar administradores de cluster completos e (3) persistir secretamente o acesso administrativo por meio de backdoors que são completamente invisíveis ao cluster operadores.

Um invasor que obteve uma posição inicial em um cluster do Autopilot, por exemplo, por meio de uma conta de desenvolvedor comprometida, poderia ter explorado esses problemas para aumentar privilégios e se tornar um “administrador sombra”, com a capacidade de exfiltrar secretamente segredos, implantar malware ou criptomineradores e interromper as cargas de trabalho.

Após nossa divulgação, o Google corrigiu os problemas relatados, implantando patches universalmente no GKE. Todos os clusters do Autopilot agora estão protegidos.

Este blog fornece uma análise técnica dos problemas, bem como mitigações para evitar ataques semelhantes contra ambientes Kubernetes e GKE. 

Produto afetadoPiloto automático do Google Kubernetes Engine (GKE)
Tópicos Relacionados da Unidade 42Fuga de Contêiner , Nuvem

Informações sobre o ‘autopilot’ do GKE

O piloto automático é um novo modo de operação no GKE, oferecendo o que o Google descreve como uma experiência “interna” do Kubernetes. No GKE Standard, os clientes gerenciam a infraestrutura de cluster e pagam por nó. Com o GKE Autopilot, o Google cuida da infraestrutura de cluster e os clientes pagam apenas pelos pods em execução. Isso permite que os clientes se concentrem em suas aplicações, reduzindo os custos operacionais.

Em poucas palavras, a infraestrutura de cluster gerenciada significa que o Google automaticamente:

  1. Provisiona e ajusta o número de nós de acordo com o consumo de recursos de seus pods.
  2. Aplica uma política integrada para garantir que o cluster siga as práticas recomendadas de segurança e possa ser gerenciado com segurança pelo Google.

Abaixo está um diagrama simplificado da arquitetura do Autopilot. Os componentes exclusivos do Autopilot são coloridos em verde e mostrados com um número correspondente à sua função na lista acima. Ao contrário do GKE Standard, em que os nós são visíveis como VMs do Compute Engine, os nós do Autopilot são totalmente gerenciados pelo Google e, portanto, coloridos em verde.

Um diagrama simplificado da arquitetura do Autopilot.  Os componentes exclusivos do Autopilot são coloridos em verde e mostrados com um número correspondente à sua função na lista acima.  Ao contrário do GKE Standard, em que os nós são visíveis como VMs do Compute Engine, os nós do Autopilot são totalmente gerenciados pelo Google e, portanto, coloridos em verde.
Figura 1. Arquitetura do piloto automático do GKE.

Conforme visto na Figura 1, dois componentes reforçam a política do Autopilot. O primeiro é um OPA Gatekeeper validando o webhook de admissão, um projeto de código aberto amplamente usado para aplicação de políticas no Kubernetes. O segundo é um modo de autorização proprietário do Kubernetes chamado GKEAutopilot, que o Google implementou modificando o código-fonte do Kubernetes.

A política integrada tem duas finalidades : (a) impedir que os usuários acessem os componentes do cluster gerenciados pelo Google, como nós; e (b) manter as melhores práticas seguras do Kubernetes. Por exemplo, o Autopilot proíbe a execução de contêineres privilegiados, atendendo a (a) e (b).

A política integrada do GKE Autopilot impede que os usuários acessem os componentes do cluster gerenciados pelo Google e mantém as práticas recomendadas seguras do Kubernetes.
Figura 2. A política integrada do Autopilot impede contêineres privilegiados (Gatekeeper).

A política do Autopilot vai além da prevenção de fugas de contêineres. As Figuras 3, 4 e 5 destacam alguns exemplos interessantes. A documentação do GKE lista todos os limites impostos pela política.

A política do GKE Autopilot vai além da prevenção de fugas de contêineres.  Esta captura de tela mostra como o namespace kube-system é gerenciado.
Figura 3. O namespace kube-system é gerenciado, os clientes estão limitados ao acesso somente leitura.
A política do GKE Autopilot vai além da prevenção de fugas de contêineres.  Esta captura de tela mostra como os usuários não podem listar ou criar webhooks de admissão mutantes.
Figura 4. Os usuários não podem listar ou criar webhooks de admissão mutantes.
A política do GKE Autopilot vai além da prevenção de fugas de contêineres.  Esta captura de tela mostra como os serviços de IP externo são negados para proteção contra CVE-2020-8554.
Figura 5. Os serviços IP externos são negados para proteção contra CVE-2020-8554.

Lendo as mensagens de erro nas Figuras acima, você pode ver que o Gatekeeper impediu as operações nas Figuras 2 e 5, enquanto o modo de autorização GKEAutopilot impediu as operações nas Figuras 3 e 4.

Superfícies de ataque exclusivas do piloto automático do GKE

A política integrada do Autopilot bloqueia vários caminhos de exploração prontos para uso, oferecendo uma melhor postura de segurança em comparação com o Kubernetes padrão ou o GKE Standard. Dito isto, também cria superfícies de ataque exclusivas para o Autopilot:

  1. Os administradores podem confiar na política do Autopilot para evitar configurações arriscadas. Se os invasores puderem contornar essa política de alguma forma, eles poderão escalar privilégios por meio de métodos que os clientes esperam que sejam bloqueados, como implantar um contêiner privilegiado.
  2. Os administradores do Autopilot não são totalmente privilegiados, restringidos pela política interna de acessar nós e certas APIs privilegiadas do Kubernetes. Se os invasores puderem ignorar a política do Autopilot, eles poderão obter privilégios mais altos do que os administradores, abrindo a porta para backdoors invisíveis.

As seções a seguir apresentam vulnerabilidades, técnicas de escalonamento de privilégios e métodos de persistência que identificamos que se enquadram nessas superfícies de ataque. Encadeados, eles permitem que um usuário restrito que pode criar um pod para (1) comprometer nós, (2) escalar privilégios para um administrador de cluster irrestrito e (3) instalar backdoors invisíveis e persistentes no cluster.

Mascarando-se como cargas de trabalho permitidas para comprometer nós

Nossa pesquisa começou no seguinte parágrafo na documentação do Autopilot:

“Nossa intenção é impedir o acesso não intencional à máquina virtual do nó. Aceitamos envios nesse sentido por meio do Programa de recompensa de vulnerabilidade do Google (VRP)…”

Isso parecia um desafio interessante, então criamos um cluster de piloto automático e começamos a procurar. O Autopilot instalou o OPA Gatekeeper no cluster junto com várias políticas (chamadas “restrições” na terminologia do Gatekeeper) encarregadas de evitar configurações arriscadas, como contêineres privilegiados. O cluster também tinha uma Custom Resource Definition (CRD) que parecia interessante, chamada allowlistedworkloads .

Ao pesquisar as vulnerabilidades do GKE Autopilot, observamos que o Autopilot instala um CRD chamado allowlistedworkloads, conforme mostrado aqui.
Figura 6. O Autopilot instala uma definição de recurso personalizado (CRD) chamada allowlistedworkloads

Conforme mostrado anteriormente na Figura 2, o Autopilot proíbe configurações de pod que possam permitir fugas de contêiner. Para dar suporte a complementos que exigem algum nível de acesso ao nó, o Autopilot criou uma noção de cargas de trabalho permitidas na lista. Se um contêiner corresponder a uma carga de trabalho permitida na lista, ele poderá usar os recursos privilegiados especificados na configuração de carga de trabalho permitida . Em junho, as únicas cargas de trabalho permitidas eram os agentes Datadog.

Em junho, as únicas cargas de trabalho permitidas eram os agentes Datadog.
Figure 7. Datadog agent allowlistedworkload

Abaixo está a configuração de carga de trabalho permitida para um dos agentes Datadog que chamou nossa atenção. Se um contêiner especificar o comando e a imagem listados, ele poderá montar os caminhos de host listados em volumes somente leitura.

A captura de tela mostra a configuração de carga de trabalho permitida para um dos agentes do Datadog que chamou nossa atenção ao pesquisar vulnerabilidades do GKE Autopilot.
Figura 8. Um dos exemplos de configuração allowlistworkload para agentes Datadog.

O problema aqui é a verificação insuficiente. Apenas verificar o comando e a imagem não é suficiente para garantir que o contêiner execute o código Datadog. Usando o PodSpec a seguir , um contêiner pode se disfarçar como o agente Datadog enquanto executa o código controlado pelo invasor e abusar dos volumes de host expostos para quebrar.

Usando o PodSpec mostrado aqui, um contêiner pode se disfarçar como o agente Datadog enquanto executa o código controlado pelo invasor e abusar dos volumes de host expostos para romper.
Figure 9. Masquerading as the Datadog agent.

No vídeo abaixo, um usuário mal-intencionado implanta um pod disfarçado de agente Datadog. O pod assume seu nó subjacente por meio das seguintes etapas:

  1. Abuse do soquete containerd montado para criar um container privilegiado que monta o sistema de arquivos do host.
  2. Faça com que esse contêiner privilegiado instale um serviço systemd que gere um shell reverso do nó para uma máquina controlada pelo invasor.

Vídeo 1. Mascarado como uma carga de trabalho permitida para comprometer o nó subjacente.

Impacto do Comprometimento do Nó

Um invasor que pode criar um pod pode explorar esse problema para criar contêineres maliciosos que escapam e assumem seus nós subjacentes. Os usuários do piloto automático esperam que a plataforma evite esse tipo de ataque e serão pegos de surpresa.

O comprometimento do nó abre os seguintes vetores de ataque:

  1. O invasor imediatamente obtém controle sobre os pods vizinhos e seus tokens de conta de serviço, aumentando potencialmente os privilégios e se espalhando para outros namespaces .
  2. O invasor pode consultar o endpoint de metadados da instância do nó para obter um token de acesso. Por padrão, esse token fornece acesso de leitura ao armazenamento em nuvem no projeto do cliente.
  3. Como os administradores do Autopilot não podem acessar os nós, os invasores podem abusar desse problema para instalar malware ou criptomineradores ocultos neles. No entanto, o Autopilot dimensiona automaticamente os nós, portanto, garantir que o malware persista não é simples.
  4. O invasor obtém acesso às credenciais subjacentes do Kubelet, permitindo visibilidade de quase todos os objetos do cluster.

Por fim, como o Autopilot cobra apenas por pods em execução, os usuários habilidosos podem ter abusado desse problema para reduzir alguns custos, executando algumas cargas de trabalho diretamente nos nós. Aconselhamos reduzir as contas de maneiras mais legítimas.

Escalando para administradores irrestritos

Seguindo a trajetória de um intruso motivado, procuramos métodos confiáveis ​​de escalar essa fuga de contêiner para uma tomada completa do cluster. Ao comprometer um nó, os invasores podem roubar os tokens da conta de serviço dos pods vizinhos. Naturalmente, faria sentido segmentar nós que hospedam pods com contas de serviço poderosas. Esses podem ser pods implantados pelo usuário ou, mais interessante, pods do sistema implantados nativamente em todos os clusters do Autopilot.

Depois de examinar a política integrada, descobrimos que o Autopilot isenta completamente as contas de serviço do sistema kube . Isso tornou os pods do sistema kube os alvos mais interessantes, pois os tokens roubados podiam ser usados ​​livremente sem se preocupar com a política.

Depois de examinar a política integrada, descobrimos que o Autopilot isenta completamente as contas de serviço do sistema kube.
Figura 10. A política do Autopilot isenta contas de serviço do sistema kube na linha 3.

Para procurar pods poderosos no Autopilot, criamos o sa-hunter , uma ferramenta Python que mapeia as contas de serviço dos pods para suas permissões do Kubernetes (ou seja, funções e funções de cluster). As ferramentas existentes vinculam contas de serviço a suas permissões, mas não mostram se algum pod realmente usa uma determinada conta de serviço. A Figura 11 mostra um exemplo de saída de sa-hunter :

Um exemplo de saída de sa-under, que procura por pods poderosos no Autopilot.
Figura 11. saída do sa-hunter, vinculando os pods em execução às suas permissões.

O sa-hunter encontrou dois poderosos pods do sistema kube instalados por padrão: stackdriver-metadata-agent-cluster-level e métricas-server . Ambos os pods podem atualizar as implantações existentes, conforme mostrado na Figura 12. Esse privilégio pode parecer inocente à primeira vista, mas é suficiente para escalar para um administrador de cluster completo. Curiosamente, esses pods também são implantados por padrão no GKE Standard, tornando a técnica de escalonamento de privilégios a seguir relevante para todos os clusters do GKE, Standard e Autopilot .

A função privilegiada atribuída ao pod do servidor de métricas pode atualizar as implantações.
Figura 12. A função privilegiada atribuída ao pod do servidor de métricas pode atualizar as implantações.

Depois de assumir um nó que hospeda o pod stackdriver-metadata-agent-cluster-level ou o pod de servidor de métricas , um invasor pode coletar seu token de conta de serviço do sistema de arquivos do nó. Armado com esse token, o invasor pode obter os privilégios de qualquer conta de serviço no cluster com três etapas simples:

  1. Atualize a conta de serviço de uma implantação existente para a conta de serviço de destino. Há várias implantações pré-instaladas, qualquer uma das quais pode ser usada para esta etapa.
  2. Adicione um contêiner malicioso a essa implantação.
  3. Faça com que esse contêiner malicioso recupere o token da conta de serviço de destino montado no contêiner em /run/secrets/kubernetes.io/serviceaccount/token .
Abusando de privilégios de atualização de implantação para obter o token de qualquer conta de serviço.
Figura 13. Abusando dos privilégios de atualização de implantação para obter o token de qualquer conta de serviço.

Para que isso seja uma escalada de privilégios significativa, o invasor precisa ter como alvo uma conta de serviço poderosa. O namespace kube-system oferece várias contas de serviço pré-instaladas e extremamente poderosas para você escolher. A conta de serviço clusterrole-aggregation-controller ( CRAC ) é provavelmente a principal candidata, pois pode adicionar permissões arbitrárias a funções de cluster existentes.

A conta de serviço clusterrole-aggregation-controller pode escalar funções de cluster.
Figura 14. A conta de serviço clusterrole-aggregation-controller pode escalar funções de cluster.

Após usar a técnica ilustrada na Figura 13 para obter o token do CRAC , o invasor pode atualizar a função do cluster vinculada ao CRAC para possuir todos os privilégios. Nesse ponto, o invasor é efetivamente o administrador do cluster e também está isento da política do Autopilot (como visto na Figura 10).

O token do controlador de agregação de clusterrole pode adicionar privilégios de administrador a si mesmo.
Figura 15. O token do clusterrole-aggregation-controller pode adicionar privilégios de administrador a si mesmo.

Rebobinando, se o invasor quiser encadear essa técnica de escalonamento de privilégios com a fuga de contêiner discutida anteriormente, ele precisa agendar de alguma forma seu pod de breakout em um nó que hospeda o pod de stackdriver-metadata-agent-cluster-level ou o pod de servidor de métricas . Embora o Autopilot rejeite pods que tenham nodeSelectors , ele permite a forma mais simples de atribuição de nó — o campo nodeName .

O campo nodeName garante que o pod de breakout chegará ao nó de destino, desde que tenha recursos adequados para outro pod. Mesmo que não haja espaço no nó de destino, o invasor ainda tem algumas opções. Ele pode (1) observar o nó de destino e esperar que um pod seja excluído; ou (2) crie pods para acionar um aumento de nó, enganando o autoescalador do Autopilot para redistribuir cargas de trabalho para que um pod poderoso termine em um nó mais vazio.

Cadeia completa: backdoors invisíveis via webhooks de admissão mutante

O vídeo 2 mostra a cadeia de ataque completa, combinando a fuga do contêiner com a rota de escalonamento de privilégios integrada ao GKE. Após a exploração, o invasor tem privilégios mais altos do que os administradores do Autopilot, pois está isento da política integrada (como visto na Figura 10). Este nível de acesso pode ser abusado para instalar backdoors invisíveis e persistentes na forma de webhooks de admissão mutantes .

Os webhooks de admissão mutantes recebem todos os objetos criados ou atualizados no cluster, incluindo pods e segredos. Se isso não for assustador o suficiente, esses webhooks também podem alterar arbitrariamente qualquer objeto recebido, tornando-os um backdoor ridiculamente poderoso. Conforme mostrado anteriormente na Figura 4, os administradores do Autopilot não podem listar webhooks de admissão em mutação e, portanto, nunca verão esse backdoor.

Antes das correções, um invasor poderia ter explorado as vulnerabilidades do GKE Autopilot para se tornar um administrador de sombra por meio de um webhook de admissão mutante invisível.
Figura 16. Tornando-se um administrador de sombra por meio de um webhook de admissão mutante invisível.

Vídeo 2. Escalando da criação do pod para um administrador irrestrito e um backdoor invisível .

Um webhook de admissão mutante malicioso instalado ao abusar das vulnerabilidades e técnicas de ataque relatadas do GKE.  Observe que ver o backdoor exigia o token de administrador irrestrito adquirido no ataque.
Figura 17. Um webhook de admissão mutante malicioso instalado ao abusar dos problemas relatados. Observe que ver o backdoor exigia o token de administrador irrestrito adquirido no ataque.

Cadeia Completa: Impacto

Antes das correções, os invasores poderiam ter explorado os problemas apresentados para transformar uma violação limitada em um controle completo do cluster em qualquer cluster do Autopilot. Usando webhooks que são invisíveis para os usuários, os invasores podem manter secretamente seu acesso administrativo, tornando-se efetivamente “administradores de sombra”. Nesse ponto, eles podem ter secretamente exfiltrado segredos, implantado malware ou criptomineradores e interrompido cargas de trabalho.

Outros problemas

Durante nossa pesquisa, encontramos dois problemas adicionais que permitem o comprometimento do nó, mas com menor impacto. O primeiro envolve dois nomes de contas de serviço no namespace padrão que foram isentos da política do Autopilot: csi-attacher e otelsvc . Se um invasor obtivesse controle sobre o namespace padrão, seria possível criar essas contas de serviço para ignorar a política interna. O invasor pode então criar pods privilegiados para comprometer os nós e usar a técnica de escalonamento de privilégio discutida para assumir o controle de todo o cluster.

O segundo ataque explorou o CVE-2020-8554 por meio dos serviços do Load Balancer para comprometer os nós, mas exigiu privilégios de administrador para explorar. O cenário de ataque aqui é um invasor que já comprometeu um cluster do Autopilot e está tentando contornar a política interna para estabelecer um backdoor secreto.

Correções e Mitigações

Seguindo nosso conselho e ao longo dos últimos meses, o Google implantou várias correções e mitigações no GKE Autopilot. Eles impedem o ataque relatado e protegem a plataforma contra explorações semelhantes.

  1. Os administradores de cluster agora podem listar, visualizar e até criar webhooks de admissão mutantes, evitando seu abuso como backdoors invisíveis.
  2. O Google reforçou o processo de verificação de cargas de trabalho permitidas na lista .
  3. A aplicação de políticas mudou do OPA Gatekeeper para o controlador de políticas do Google, permitindo que os clientes implantem sua própria instância do Gatekeeper. Os clientes agora podem aplicar sua própria política em cima da política integrada. Como defesa em profundidade e para mitigar possíveis problemas futuros , recomendamos a implantação das mesmas políticas que você implantaria no padrão GKE.
  4. A política interna não é mais visível.
  5. As contas de serviço csi-attacher e otelsvc não estão mais isentas da política do Autopilot.
  6. O Google abriu uma política para o OPA Gatekeeper que restringe os poderosos pods do sistema kube abusados ​​no ataque. A política impede que esses pods atribuam uma nova conta de serviço a um pod existente. Consulte o guia de proteção do GKE para mais informações.

É altamente recomendável ler o comunicado oficial do Google , que descreve os problemas da perspectiva do Google e lista suas mitigações.

Como evitar ataques semelhantes em ambientes Kubernetes

O ataque apresentado pode ser classificado como uma escalação de privilégios do Kubernetes, onde um invasor com acesso limitado obtém permissões mais amplas sobre um cluster. Esse tipo de atividade subsequente do invasor deve começar a partir de uma violação inicial: uma imagem maliciosa na cadeia de suprimentos do cluster, um serviço vulnerável exposto publicamente, credenciais roubadas ou uma ameaça interna. Proteger a cadeia de fornecimento de software, as identidades e o perímetro externo de seu cluster pode reduzir as chances de tais violações ocorrerem em seus clusters.

Atacantes sofisticados ainda podem encontrar maneiras criativas de se infiltrar em clusters. A solução proativa de configurações incorretas comuns, como Kubelets que permitem acesso não autenticado, pode reduzir significativamente a superfície de ataque interna disponível para um invasor. Controles de segurança, como NetworkPolicies e PodSecurityStandards , restringem e desmoralizam ainda mais os agentes mal-intencionados.

Na cadeia de ataque apresentada, o invasor teve que comprometer apenas um nó para assumir o controle de todo o cluster. O problema subjacente não eram as permissões do nó, mas as dos pods poderosos que ele hospedava, que incluíam a capacidade de atualizar implantações. Essa permissão e outras podem parecer restritas à primeira vista, mas são equivalentes ao administrador do cluster.

Pods poderosos ainda são comuns em clusters de produção : instalados nativamente pela plataforma Kubernetes subjacente ou introduzidos por meio de complementos populares de código aberto. Se um nó que hospeda um pod poderoso for comprometido, o invasor poderá coletar facilmente o token de conta de serviço poderoso do pod para espalhar no cluster.

Lidar com pods poderosos é complexo, principalmente porque suas permissões podem ser legitimamente necessárias. A primeira etapa é a detecção — identificando se existem pods poderosos em seu cluster. Esperamos que o sa-hunter possa ajudar com isso e planejamos lançar ferramentas adicionais que se concentrem na detecção automática de pods poderosos.

Se você identificou pods poderosos em seu cluster, recomendamos seguir uma das abordagens abaixo:

  1. Se você gerencia o pod poderoso, considere se é possível remover privilégios desnecessários de sua conta de serviço ou defini-los para namespaces ou nomes de recursos específicos.
  2. Se esses pods fizerem parte de uma solução externa, entre em contato com o provedor ou projeto de nuvem relevante para reduzir os privilégios do pod. Se o pod for implantado por um serviço gerenciado do Kubernetes, talvez seja possível substituí-lo por um controlador de plano de controle.
  3. Algumas permissões do Kubernetes são muito amplas, o que significa que o pod em questão pode não exigir acesso às operações perigosas que suas permissões expõem. Nesse caso, pode ser possível implementar uma política (por exemplo, via OPA Gatekeeper) que impeça o pod de realizar certas operações perigosas ou, melhor ainda, restrinja o pod a um conjunto de operações permitidas e esperadas.
  4. Use as regras Taints , NodeAffinity ou PodAntiAffinity para isolar pods poderosos de pods não confiáveis ​​ou expostos publicamente, garantindo que eles não sejam executados no mesmo nó.

Como exemplo para a terceira abordagem, a política Rego a seguir pode interromper o ataque de escalação de privilégio apresentado. O ataque abusou dos pods do sistema que podem atualizar as implantações para substituir a conta de serviço de uma implantação existente por uma poderosa. A inspeção do código-fonte desses pods poderosos revelou que eles não precisam da capacidade de alterar a conta de serviço das implantações que atualizam. A política abaixo aproveita isso e proíbe que esses pods atualizem inesperadamente as contas de serviço das implantações. Os usuários do Prisma Cloud no GKE são incentivados a importar essa política como uma regra de admissão definida no Alert.

1234567891011121314151617181920212223242526match[{“msg”: msg}] { input.request.object.kind == “Deployment” request_by_powerful_dep_update_sa(input.request.userInfo.username) old_spec := input.request.oldObject.spec.template.spec new_spec := input.request.object.spec.template.spec new_service_account := is_updating_the_service_account(old_spec, new_spec) msg := sprintf(“SA ‘%v’ may be compromised, it unexpectedly tried to replace the serviceaccount of ‘deployment/%v:%v’ to ‘%v'”, [input.request.userInfo.username, input.request.object.metadata.namespace, input.request.object.metadata.name, new_service_account])} request_by_powerful_dep_update_sa(username) { # metrics-server pod on GKE username == “system:serviceaccount:kube-system:metrics-server”} { # stackdriver pod on older GKE clusters username == “system:serviceaccount:kube-system:metadata-agent”} is_updating_the_service_account(oldspec, newspec) = new_service_account { oldspec.serviceAccountName != newspec.serviceAccountName new_service_account := newspec.serviceAccountName} { not has_key(oldspec, “serviceAccountName”) new_service_account := newspec.serviceAccountName} has_key(obj, k) { _ = obj[k]}

Conclusão

À medida que as organizações migram para o Kubernetes, os invasores seguem o exemplo. Amostras recentes de malware, como o Silocap, indicam que os adversários estão evoluindo além de simples técnicas para ataques avançados sob medida do Kubernetes. Contra invasores sofisticados, proteger apenas o perímetro do cluster pode não ser suficiente. Incentivamos os defensores a adotar mecanismos de política e auditoria que possibilitem a detecção e prevenção de atividades subsequentes de invasores de “estágio 2”, e esperamos que esta pesquisa possa destacar como elas podem parecer. Os clientes do Prisma Cloud são incentivados a habilitar nossos recursos de auditoria e controle de admissão do Kubernetes destinados a combater essa ameaça.

Gostaríamos de agradecer ao Google por sua cooperação na resolução desses problemas, a recompensa de recompensas e sua política maravilhosa que duplica as recompensas doadas para instituições de caridade.

A Palo Alto Networks compartilhou essas descobertas, incluindo amostras de arquivos e indicadores de comprometimento, com nossos colegas membros da Cyber ​​Threat Alliance. Os membros do CTA usam essa inteligência para implantar proteções rapidamente para seus clientes e interromper sistematicamente os cibercriminosos mal-intencionados. Saiba mais sobre a Cyber ​​Threat Alliance.

Fonte: https://unit42.paloaltonetworks.com/