Problema de sincronização do git: explorando as falhas de injeção de comando no Kubernetes
Resumo executivo
O pesquisador da Akamai Tomer Peled encontrou uma falha no git-sync no projeto auxiliar do Kubernetes que possibilita uma potencial injeção de comando. Ele apresentará essas descobertas no DEF CON 2024.
Essa falha no projeto pode causar a exfiltração de dados de qualquer arquivo no pod (incluindo tokens de conta de serviço) ou execução de comando com os privilégios de usuário git_sync.
Para explorar a falha, tudo o que um invasor precisa fazer é aplicar um arquivo YAML no cluster, que é uma operação de baixo privilégio.
Essa vulnerabilidade pode ser explorada em instalações padrão do Kubernetes em todas as plataformas (incluindo Amazon Elastic Kubernetes Service (EKS), Azure Kubernetes Service (AKS) e Google Kubernetes Engine (GKE) e Linode).
Nesta publicação do blog, fornecemos um arquivo YAML de prova de conceito (POC), bem como demonstrações do impacto potencial.
Como um CVE não foi atribuído a essa falha no projeto, não há nenhum patch para ele, portanto, ele permanece explorável.
A equipe do Kubernetes nos incentivou a compartilhar essa pesquisa para aumentar a conscientização sobre esses vetores de ataque.
Introdução
Não é a primeira vez que o Kubernetes apresenta vulnerabilidades de injeção de comandos. Apenas em 2023, sete dessas vulnerabilidades foram encontradas, incluindo várias que nós mesmosidentificamos. As preocupações com a limpeza das entradas nos levaram a olhar mais a fundo os vetores de ataque auxiliares: esse vetor de ataque é exclusivo do projeto principal do Kubernetes ou é mais abrangente? Há vários projetos auxiliares associados ao Kubernetes nos quais as vulnerabilidades podem estar ocultas, inclusive ogit-sync.
O projeto git-sync destina-se a conectar um pod e um repositório git para sincronizar as alterações entre seu site/servidor automaticamente em vez de fazer alterações manualmente por meio de uma solução CI/CD. Por exemplo, os usuários podem usar esse recurso para vincular seu pod nginx a um repositório contendo os arquivos que querem expor por meio de um pod nginx.
Nesta publicação do blog, veremos os detalhes da falha no projeto, os problemas no código-fonte do Kubernetes que permitem isso e algumas mitigações. Também discutiremos a resposta do Kubernetes às nossas descobertas.
Detalhes do vetor de ataque
Ao examinar a página de uso do git-sync, podemos ver que ele aceita muitos parâmetros de configuração possíveis para que um usuário possa personalizar o git-sync de acordo com suas necessidades. Gera uma superfície de ataque potencialmente grande que um invasor pode explorar (Figura 1).
Fig. 1: Alguns dos parâmetros do git-sync
Como a estrutura Kubernetes usa arquivos YAML para basicamente tudo, desde a configuração da interface de rede do contêiner até o gerenciamento de pods e até mesmo a manipulação de segredos, uma vulnerabilidade no YAML pode ter consequências desastrosas. Nesse caso, um pod pode ser criado para usar o git-sync para se conectar a um repositório remoto (ou um invasor).
A Figura 2 é um exemplo de um arquivo YAML de configuração que implanta um pod com git-sync.
Fig. 2: Arquivo YAML de configuração que implanta um pod com git-sync
Os dois parâmetros que mais se destacaram como possíveis vetores de ataque foram foram GITSYNC_GIT GITSYNC_GIT eGITSYNC_PASSWORD.
De acordo com os documentos oficiais dodocumento, GITSYNC_PASSWORD_FILE é “O arquivo a partir do qual a senha ou o token de acesso pessoal (consulte documentos do github) a ser usado para autenticação de git (consulte --username) será lido.“Isso sugere a possibilidade de exfiltração de dados do “accesstoken” ou de outros arquivos no pod.
GITSYNC_GIT é (novamente, segundo os documentos oficiais)“O comando git a ser executado (sujeito a pesquisa de CAMINHO, principalmente para testes). O padrão é "git," que significa que podemos escolher um binário que será executado no lugar do git e usá-lo para execução de código nocluster.
Cadeia de ataque proposta
Considerando as informações acima, nós nos propusemos a provar nossas teorias. Acreditamos que existem alguns vetores de ataque que os invasores podem explorar.
Execução furtiva de código
Um invasor com privilégios baixos (Criar privilégios) no cluster ou namespace pode aplicar um arquivo YAML mal-intencionado contendo um caminho para seu binário, fazendo com que seja executado sob o nome git-sync.
O arquivo binário precisa estar dentro do pod, o que pode ser feito de algumas formas diferentes, como por meio de testes doKubernetes, volumes do Kubernetesou LOLBins que acompanham o pod git-sync (Figura 3).
Fig. 3: Exemplo de YAML usando LOLBins
Depois de aplicar o arquivo YAML, aos olhos da equipe azul, o git-sync é aquele que se comunica com um servidor remoto e, portanto, é razoável supor que seria confiável se comunicar com ele externamente. Isso permite que os invasores rompam as medidas de segurança como um bônus à execução do comando.
A Figura 4 é uma POC de um ataque em potencial que inicia um criptominerador XMrig sob o usuário git-sync.
Fig. 4: POC de potencial criptominerador XMRig
Agora, quando um administrador de rede faz a auditoria dos pods existentes e de suas comunicações fora da rede da empresa, provavelmente ele verá o usuário git-sync se comunicando com um servidor externo.
Exfiltração de dados
Um invasor com privilégios de edição pode editar uma implementação git-sync para alterar ou adicionar o parâmetro GITSYNC_PASSWORD_FILE e apontar para ele em qualquer arquivo nocluster. Isso fará com que o git-sync envie o arquivo como um meio de autenticação em sua próxima conexão com o repositório git.
Se o invasor também modificar o local do repositório git e configurar um servidor de repositório falso, a próxima implantação do processo git-sync dentro do pod enviará o arquivo no parâmetro GITSYNC_PASSWORD_FILE do pod para a máquina. Não há restrições nos caminhos de arquivo ou permissões necessárias para ocluster.
Uma exfiltração de alto risco não é difícil de imaginar. Considereo seguinte: os invasores podem usar essa técnica para recuperar o token de acesso do pod, o que os permitiria interagir com o cluster sob a forma do pod git-sync (Figura 5).
Fig. 5: POC de possível ataque ao GITSYNC_PASSWORD_FILE
Divulgação e resposta do Kubernetes
Originalmente, divulgamos nossas descobertas para a equipe do Kubernetes em dezembro de 2023. Depois de algumas discussões com a equipe do Kubernetes, foi decidido que a edição de YAMLs é considerada uma operação de alto privilégio. Por isso, os nossos resultados não atravessam um limite de segurança. Da nossa perspectiva, porém, embora as operações de edição em um pod sejam consideradas um privilégio, o movimento lateral ainda é possível com essa técnica. Também nos preocupamos com a perda de integridade: o invasor pode roubar informações como se fosse um usuário git-sync legítimo.
Sobre a questão do GITSYNC_GIT,a equipe do Kubernetes reconheceu que os privilégios necessários para esse tipo de ação são baixos, mas não achou que as operações de baixo privilégio levariam a qualquer comportamento prejudicial. No entanto, acreditamos que a falha no projeto que descrevemos permitiria que os invasores executassem comandos enquanto falsificam sua identidade, e a única proteção contra o comportamento prejudicial são os baixos privilégios no cluster. Esse fluxo de ataque é especialmente perigoso em organizações que têm comunicação git-sync pré-autorizada em seucluster.
Em ambos os casos, o Kubernetes nos incentivou a compartilhar essa pesquisa valiosa online, pois “ajuda os administradores a pensar cuidadosamente sobre a área da superfície que eles expõem aos usuários”.
Mitigações
Como as técnicas de ataque descritas nesta publicação do blog não são consideradas vulnerabilidades pela equipe do Kubernetes, não haverá a aplicação de patch para elas. Portanto, para reduzir a superfície de ataque que esses “recursos” permitem, recomendamos algumas possíveis mitigações.
Primeiro, aumente o monitoramento da comunicação que sai da organização, especificamente dos pods do Kubernetes. Se for possível, tome cuidado especial com os pods git-sync.
Em segundo lugar, recomendamos a auditoria de pods git-sync para descobrir qual comando eles estão executando. Isso pode ser feito com o seguinte comando:
kubectl describe pod <git-sync-pod>
Por exemplo, ao executar esse comando no criptominerador mostrado na Figura 4, podemos ver o argumento –git que teria gerado um sinal vermelho na detecção, especialmente quando o valor do argumento não é “git” (Figura 6).
Fig. 6: Executar este comando de auditoria no criptominerador na Figura 4
Essa auditoria é uma prática recomendada de segurança geral, portanto, recomendamos executar esse comando em todos os pods, não apenas nos pods git-sync.
Também escrevemos uma regra OPA que pode detectar um de nossos vetores de ataque propostos, em que os ataques substituem o binário git por uma carga mal-intencionada:
package kubernetes.admission
deny[msg] {
input.request.kind.kind == "<Deployment/Pod>"
path := input.request.object.spec.env.name
contains(path, "GITSYNC_GIT")
msg := sprintf("Gitsync binary parameter detected, possible payload alteration, verify new binary ", [path])
}
Conclusão
Nesta publicação do blog, mostramos dois vetores de ataque no projeto auxiliar do Kubernetes git-sync. Ambos os vetores se devem à falta de limpeza das entradas, o que destaca a necessidade de uma defesa robusta em relação à limpeza das entradas do usuário. Esses problemas de limpeza do Kubernetes não são exclusivos do git-sync, como discutimos anteriormente.
Os membros da equipe azul devem estar atentos ao comportamento incomum proveniente do usuário gitsync em suas organizações. Acreditamos que esses vetores de ataque podem ter um grande impacto sobre as empresas; portanto, é importante conscientizarmos e ajudarmos os administradores de segurança a saber sobre o perigo potencial.
O Akamai Security Intelligence Group continuará a pesquisar e reportar ameaças como essas aos nossos clientes e à comunidade de segurança em geral. Para receber atualizações em tempo real sobre o que estamos trabalhando, siga-nos no X (antigo Twitter).
Apesar de nossa discordância no resultado, queremos agradecer à equipe do Kubernetes por sua resposta e comunicação.
