Suporte Técnico
Documentação
Entrar
Entre em contato conosco
Vá direto para um resumo gerado por IA desta postagem do blog 
No cenário em constante mudança da segurança cibernética, a vigilância é fundamental, especialmente quando se trata de sistemas complexos e amplamente utilizados, como o Kubernetes. Acabaram de ser descobertas três falhas de segurança de alta gravidade acaba de ser descoberto, representando uma ameaça substancial aos ambientes do Kubernetes. Embora essas vulnerabilidades do Kubernetes afetam principalmente os terminais Windows dentro de um cluster do Kubernetes, suas possíveis ramificações vão além dos sistemas Windows, o que ressalta a importância de medidas de segurança robustas e multiplataforma no mundo centrado no Linux.
O trio de CVEs: CVE-2023-3676, CVE-2023-3893 e CVE-2023-3955
A pontuação CVSS para essas três vulnerabilidades, CVE-2023-3676, CVE-2023-3893 e CVE-2023-3955, é 8,8. Elas permitem a execução remota de código com privilégios elevados dentro de um cluster do Kubernetes. É importante ressaltar que essas falhas afetam todos os sistemas do Kubernetes que envolvam nós do Windows.
A Akamai divulgou essas informações de forma responsável riscos de segurança do Kubernetes em 13 de julho de 2023, o que gerou uma resposta rápida da comunidade do Kubernetes. Em 23 de agosto de 2023, foram lançadas correções, ressaltando a importância dos esforços colaborativos no campo do software de código aberto.
Analisando as vulnerabilidades do Kubernetes
As vulnerabilidades estão relacionadas à manipulação de arquivos YAML, uma linguagem de configuração amplamente utilizada no Kubernetes para gerenciar segurança do tempo de execução de contêineres em aplicativos. A possibilidade de explorar essas falhas decorre da conexão direta entre os arquivos YAML e o mecanismo do Kubernetes.
Notavelmente, as vulnerabilidades de análise de YAML já causaram alertas de risco nas atualizações de segurança do Kubernetes. O CVE-2022-1471, por exemplo, revelou uma vulnerabilidade de execução remota de código no analisador SnakeYaml, afetando o cliente Java do Kubernetes. O CVE-2021-25749 também permitia a inclusão de nomes de usuário com erros ortográficos em arquivos YAML, resultando na execução de cargas de trabalho com privilégios de root.
A saga da subpropriedade SubPath
As vulnerabilidades das quais estamos falando hoje têm origem em preocupações anteriores relacionadas à subpropriedade “subPath” em arquivos YAML. Por meio da propriedade “volume”, o Kubernetes permite a montagem de um diretório do sistema host dentro de um contêiner, um recurso comumente utilizado no ecossistema do Kubernetes. Esse recurso possui inúmeras subpropriedades, sendo “subPath” uma delas. Quando “subPath” é especificada em um arquivo YAML, ela é processada pelo kubelet, um serviço essencial do Kubernetes.
Subtilezas do PowerShell
A origem dessas falhas está na forma como o Kubernetes trata a string “subPath”. Durante o processamento, o kubelet determina se trata-se de um link simbólico. Essa proteção, por outro lado, é implementada por meio de um comando do PowerShell invocado pela chamada à função “exec.Command”. Isso abre uma brecha para que invasores insiram código do PowerShell na string “subPath”, que será então executado.
A capacidade do PowerShell de avaliar valores dentro de strings antes de seu uso permite que invasores insiram comandos maliciosos com facilidade. Por exemplo, um invasor pode fornecer um arquivo YAML com um “subPath” contendo “$(Start-Process cmd)”. Durante a validação do caminho, o kubelet enviará esse comando ao PowerShell, onde ele será executado com os privilégios do serviço kubelet, especificamente no nível SYSTEM.
Ampliando o escopo da vulnerabilidade CVE-2023-3676
A vulnerabilidade que está na base desse debate, CVE-2023-3676, foi corrigida no Kubernetes 1.28. A Avaliação de vulnerabilidades do Kubernetes, no entanto, resultou na divulgação de mais duas vulnerabilidades de injeção de comando: CVE-2023-3955 e CVE-2023-3893. Embora essas falhas afetem principalmente o Kubernetes no Windows em sua
configuração padrão, é importante lembrar que os invasores ainda precisam obter privilégios de aplicativo em um nó.
Prevenção de vulnerabilidades no Kubernetes
Para lidar com essas vulnerabilidades, são necessárias medidas proativas. O DevSecOps para Kubernetes optou por corrigir esse tipo de falha substituindo os parâmetros baseados em entradas do usuário por variáveis de ambiente. Essa mudança garante que os parâmetros sejam processados apenas como strings, impedindo que sejam avaliados como expressões do PowerShell.
No contexto de gestão de patches do Kubernetes, os administradores têm opções caso não seja possível realizar atualizações imediatas para a versão corrigida. Eles podem interromper o uso de “Volume.Subpath”, mas isso afetará recursos e funcionalidades utilizados regularmente. Outra opção é utilizar o Open Policy Agent (OPA), um agente de código aberto capaz de executar atividades baseadas em políticas. Os administradores podem escrever regras na linguagem Rego do OPA para impedir que arquivos YAML específicos sejam executados. A verificação de imagens de contêineres também pode ser usada para identificar vulnerabilidades.
Além disso, o controle de acesso baseado em funções (RBAC) deve ser utilizado para limitar o número de usuários autorizados a realizar operações dentro de um cluster do Kubernetes. Essa estratégia abrangente aumenta a segurança e, ao mesmo tempo, reduz possíveis vias de ataque.
Conclusão
Vigilância e medidas de segurança proativas são fundamentais no mundo do Kubernetes. Embora os CVEs no Kubernetes (CVE-2023-3676, CVE-2023-3893 e CVE-2023-3955) afetam principalmente terminais Windows dentro de um cluster do Kubernetes, as repercussões são generalizadas. Como os clusters do Kubernetes estão interconectados, o comprometimento de um único nó, mesmo que esteja rodando o Windows, pode ter repercussões na configuração e na segurança de todo o cluster.
À medida que exploramos o complexo mundo do Kubernetes e suas falhas, fica claro que as práticas recomendadas do Kubernetes são essenciais, independentemente das plataformas envolvidas. Não basta proteger um único nó em um cenário digital em constante mudança; também é necessário preservar a segurança do cluster do Kubernetes.
As fontes utilizadas neste artigo incluem matérias publicadas no The Hacker News e CSO.
