Zephyrnet Logo

Patch agora: falha RCE do Kubernetes permite o controle total dos nós do Windows

Data:

Um bug de segurança no sistema de gerenciamento de contêineres Kubernetes amplamente utilizado permite que invasores executem código remotamente com privilégios de sistema em endpoints do Windows, levando potencialmente ao controle total de todos os nós do Windows em um Cluster Kubernetes.

O pesquisador de segurança da Akamai, Tomer Peled, descobriu a falha, que é rastreada como CVE-2023-5528 e tem uma pontuação CVSS de 7.2. A exploração consiste na manipulação de volumes Kubernetes, um recurso que visa apoiar o compartilhamento de dados entre pods em um cluster, ou armazená-los de forma persistente fora do ciclo de vida de um pod, explicou ele. em um post de blog publicado em 13 de março.

Como vetor de ataque, os invasores precisariam para criar pods e volumes persistentes em nós do Windows, o que lhes permitiria escalar para privilégios de administrador nesses nós, de acordo com uma lista do GitHub para a falha.

“É muito fácil explorar esta vulnerabilidade porque um invasor só precisaria modificar um parâmetro e aplicar 3 arquivos YAML para obter RCE nos endpoints do Windows”, disse Peled ao Dark Reading. A estrutura Kubernetes “usa arquivos YAML para basicamente tudo”, escreveu ele no post.

Clusters Kubernetes são afetados apenas se estiverem usando um plug-in de armazenamento em árvore para Windows; no entanto, “existem muitos tipos de volume diferentes que os desenvolvedores podem usar”, criando diferentes cenários de ataque, observou Peled na postagem.

As instalações padrão do Kubernetes anteriores à versão 1.28.4 que executam implantações locais e o Serviço Azure Kubernetes são vulneráveis. A equipe do Kubernetes foi alertada sobre a falha e há um patch disponível para correção, que é altamente recomendado.

“Como o problema está no código-fonte, essa ameaça permanecerá ativa e sua exploração provavelmente aumentará – é por isso que recomendamos fortemente corrigir seu cluster, mesmo que ele não tenha nenhum nó Windows”, escreveu Peled.

Seguindo as falhas

Peled descobriu a falha após uma investigação de outra vulnerabilidade que compartilhava a mesma causa raiz: chamada de função insegura e falta de limpeza de entrada do usuário no Kubernetes. Essa falha foi CVE-2023-3676, uma vulnerabilidade de injeção de comando que pode ser explorada aplicando um arquivo YAML malicioso no cluster. A descoberta desta vulnerabilidade levou à descoberta de outras duas que também são causadas pela falta de sanitização do parâmetro subPath em arquivos YAML, que cria pods com volumes e abre oportunidade para injeção de código malicioso.

“No final dessa pesquisa, notamos um local potencial no código que parecia poder levar a outra vulnerabilidade de injeção de comando”, que acabou se tornando CVE-2023-5528, explicou Peled.

“Depois de várias tentativas, conseguimos um resultado semelhante: executar comandos como o serviço kubelet (privilégios SYSTEM)”, escreveu ele.

Exploração e Patching

A prova de conceito executada pelos pesquisadores focou em volumes locais, um dos tipos de volume do Kubernetes. Ao criar um pod que inclui um volume local, o serviço kubelet eventualmente alcançará uma função com uma chamada de linha cmd para “exec.command”, criando um link simbólico entre a localização do volume no nó e a localização dentro do pod.

Como muitos terminais, o Prompt de Comando do Windows (cmd) permite a execução de dois ou mais comandos um após o outro, bem como vários comandos na mesma linha de comando. “O fato de podermos controlar um dos parâmetros na execução do cmd significa que podemos usar injeção de comando”, explicou Peled.

Existem pré-requisitos para conseguir isso em volumes locais, incluindo a necessidade de especificar ou criar um persistenteVolume, entre outros. No entanto, uma vez criado esse volume, “um usuário pode solicitar espaço de armazenamento usando um persistenteVolumeClaim”, escreveu ele. “É aqui que a injeção pode ser aplicada.”

O patch criado para a falha elimina a oportunidade de injeção, excluindo a chamada cmd e substituindo-a por uma função GO nativa que realizará a mesma operação para criar o link simbólico. “Agora, a biblioteca GO 'os' realizará apenas uma operação de link simbólico, como foi planejado inicialmente”, explicou.

Seu sistema é vulnerável?

Kubernetes emergiu como um dos sistemas de código aberto mais utilizados para contêineres; no entanto, também se tornou um alvo principal para os atores de ameaças devido à sua vasto potencial para exploração e acesso a dados organizacionais. Além disso, muitas vezes a própria configuração do Kubernetes cria uma instalação vulnerável, fornecendo uma ampla superfície de ataque para os agentes de ameaças.

“O Kubernetes é uma ferramenta muito complexa e robusta”, diz Peled. “Por um lado, sua robustez permite que os usuários adaptem sua experiência às necessidades de sua organização, mas, por outro lado, torna muito difícil proteger todos os seus aspectos, tanto do ponto de vista do desenvolvedor quanto do usuário.”

Na verdade, a descoberta do CVE-2023-5528 e suas falhas relacionadas destaca para as empresas que implantam o Kubernetes “quão crucial é verificar os YAMLs de configuração do Kubernetes, uma vez que falta higienização de entrada em várias áreas de código no próprio Kubernetes e em seus projetos secundários”, escreveu Peled .

Seguir as melhores práticas, como controle de acesso baseado em função (RBAC) e garantir que os clusters estejam atualizados, também “deve mitigar uma grande parte das ameaças conhecidas”, disse ele à Dark Reading.

Um ambiente corporativo executando o Kubernetes é vulnerável à exploração da falha somente se uma versão do sistema for anterior à 1.28.4 e o sistema estiver executando nós do Windows. Se for esse o caso, a Akamai forneceu um comando para os administradores executarem para determinar se o sistema deve ser corrigido. Nesse caso, o patch deve ser priorizado.  

“Se o seu cluster Kubernetes não tiver nenhum nó Windows, você não precisa se apressar para corrigir essa vulnerabilidade específica”, observou Peled. “Mas é importante corrigi-lo de qualquer maneira, quando você tiver tempo.”

Se a correção imediata não for uma opção, a Akamai também está fornecendo uma regra Open Policy Agent (OPA) para ajudar a detectar e bloquear esse tipo de comportamento. OPA é um agente de código aberto que permite aos usuários receber dados sobre o tráfego que entra e sai dos nós e realizar ações baseadas em políticas sobre os dados recebidos.

local_img

Inteligência mais recente

local_img