Vulnerabilidade crítica de execução arbitrária de código encontrada no Kubernetes

Em 3 de dezembro de 2018, uma vulnerabilidade grave foi divulgada à comunidade do Kubernetes. Foi o primeiro CVE crítico identificado no projeto Kubernetes (com base na pontuação CVSS v3).

Versões corrigidas foram lançadas e disponibilizadas para usuários finais e provedores de nuvem. Atualize para uma versão corrigida, caso ainda não tenha feito isso. Recomendamos as seguintes versões: v1.10.11, v1.11.5, v1.12.3 e v1.13.0-rc.1. Se não for possível atualizar, outras soluções alternativas e opções de mitigação foram sugeridas na issue do GitHub mencionada acima por Jordan Liggitt, do projeto Kubernetes.

A vulnerabilidade crítica, identificada como CVE-2018-1002105, foi descoberta por Darren Shepherd, da Rancher. Ela permite que um invasor obtenha acesso remoto a serviços de back-end no cluster do Kubernetes e execute comandos arbitrários neles, o que pode resultar em escalonamento de privilégios.

O ataque é possível devido a uma vulnerabilidade no serviço de API do kubelet, um dos vários componentes que compõem o projeto Kubernetes.

O serviço de API do kubelet é um gateway intermediário fornecido pelo Kubernetes que permite que serviços de back-end, também chamados de servidores de API agregados, se registrem no gateway. Assim, todas as solicitações a esses servidores, como chamadas de API para /apis/<apiGroup>/<apiVersion>, passam pelo serviço de API do kubelet e seguem para o destino da API agregada dentro do cluster do Kubernetes.

Um exemplo de uso de um servidor de API agregado é um serviço de verificação de integridade para balanceadores de carga, que consultam servidores de back-end internos para verificar seu estado. Outro exemplo é o serviço de métricas integrado ao Kubernetes.

A vulnerabilidade

Para explorar a vulnerabilidade, um usuário precisa ter acesso ao serviço de API do kubelet, identificado como kube-apiserver. Isso abre caminho para o escalonamento de privilégios e para obter ainda mais acesso.

A vulnerabilidade decorre da forma como o kube-apiserver encaminha solicitações aos servidores de back-end internos do cluster. Isso cria um túnel direto entre os servidores de back-end e o usuário. Mais especificamente, isso acontece durante o tratamento de solicitações de atualização de conexão, necessárias para a comunicação por WebSockets. A conexão TCP aberta entre o cliente e o servidor de back-end pode então ser usada para enviar solicitações arbitrárias diretamente a esse servidor.

Normalmente, esse serviço de API do kubelet é bloqueado para qualquer pessoa de fora do cluster. No entanto, por padrão, o acesso a essa API é permitido a usuários anônimos para possibilitar a descoberta de serviços e as verificações de integridade.

Há também outro vetor de ataque: um serviço acessível a usuários pode interagir com o serviço de API do kubelet de uma forma que permite a um invasor remoto assumir o controle dessa interação, abrindo caminho para manipular a conexão com o kubelet e explorá-la de maneira semelhante.

Curiosamente, este não é o primeiro incidente relacionado ao kube-apiserver. Uma análise publicada em março revelou como um kube-apiserver exposto publicamente levou à instalação de um malware de mineração de criptomoedas em um cluster do Kubernetes. A infraestrutura de nuvem da própria Tesla também foi vítima de um ataque semelhante, devido a um console de administração do Kubernetes inseguro. Ainda assim, esta vulnerabilidade recente é a mais grave já divulgada à equipe de Segurança de Produtos do Kubernetes.

Na Snyk, nossa equipe de segurança adicionou a vulnerabilidade ao nosso banco de dados em 5 de dezembro de 2018.

Principais aprendizados:

• Configurações padrão inseguras — usuários autenticados e não autenticados podem consultar a API do Kubernetes

• Registro insuficiente — atividades maliciosas ou suspeitas foram realizadas por meio de uma conexão de API já existente. Por isso, o Kubernetes não registrou as atividades em si, apenas a chamada inicial à API.

Como se proteger

Em junho, anunciamos nossa solução de análise de imagens Docker, fácil de usar por desenvolvedores, que permite detectar se alguma das suas imagens contém as vulnerabilidades mencionadas neste artigo, além de muitas outras. A Snyk também fornece recomendações de correção, indicando imagens-base para as quais você pode atualizar e que contêm menos vulnerabilidades, além de ajudar a mitigar esta vulnerabilidade específica.

Se você ainda não experimentou, convidamos você a testar seus projetos que contêm Dockerfiles. Vamos começar a analisá-los e monitorá-los para identificar pacotes vulneráveis instalados na imagem-base do sistema operacional.