Skip to content
KitploitKITPLOIT
FerramentasBlog
Enviar
FerramentasBlog
Enviar

Ferramentas de Hacking, PenTest e Cibersegurança para o seu Arsenal de Segurança!

Kitploit é um diretório de ferramentas de hacking, cibersegurança e pentesting. Descubra as últimas atualizações de projetos para encontrar vulnerabilidades, analisar sistemas, automatizar testes e fortalecer sua segurança.

··Feeds·Contato·Privacidade·© 2026 Kitploit

Diretório de Ferramentas

Categorias

Ver todas as categorias
Loading categories
Ferramentas/GitHubGitHub/bgeesaman/subpath-exploit
Análise de VulnerabilidadesExploraçãoSegurança na NuvemAprendizado e EducaçãoEscape de ContêinerLabs e Prática
GitHubbgeesaman/subpath-exploit

subpath-exploit

Análise do CVE-2017-1002101 com exemplo de "exploit"/escape

Ver Repositório
3423há 8 anosRevisado pelo Kitploit
Site

Mais Populares

Ver todos →

Descubra as ferramentas mais usadas pela nossa comunidade.

Explore todas as ferramentas

Navegue pela nossa coleção de ferramentas

Ver todas as ferramentas →
Compartilhar

Exemplo de Escape do Kubernetes via CVE-2017-1002101

Descrição

Após ouvir sobre o problema e seguir este guia, quis explorar as coisas um pouco mais. Este repositório contém algumas implantações de pods e scripts shell auxiliares que demonstram o mecanismo de ataque da forma mais simples possível, para que administradores e operadores do Kubernetes possam compreender totalmente a gravidade e os riscos potenciais. Você precisa ser um usuário autenticado ou ser capaz de controlar a especificação/modelo de um pod no momento da criação, então este escape provavelmente não será anônimo a menos que combinado com outros ataques como este.

Explicação Rápida

Quando o Kubelet monta um volume/secret/configmap, etc., ele segue incorretamente links simbólicos dentro do volume para locais fora do escopo onde deveria. Como o Kubelet está sendo executado como root, isso significa que ele pode ser enganado para montar partes privilegiadas do sistema de arquivos do host dentro do contêiner de um pod não privilegiado. Minha abordagem foi usar um único pod com dois contêineres "normais". Um contêiner cria o link simbólico para / ou e o outro crashloop até que isso seja bem-sucedido (forçando o volume a ser remontado e seguindo esse caminho de link simbólico), permitindo que o usuário execute comandos no segundo contêiner e acesse o ponto de montagem.

/home/ubuntu

Execução Rápida

Nota: Estes exemplos funcionam sem modificação em um host Ubuntu 16.04, mas podem ser facilmente ajustados para outras configurações.

  1. Examine os arquivos no repositório antes de executar qualquer coisa.
  2. Execute ./run-as-root.sh se seu cluster for razoavelmente "padrão".
  3. Execute ./run-as-root-no-chroot.sh ou ./run-as-user-1000.sh para outras variações.

asciicast

Estratégia de Mitigação

É realmente uma situação de "correção obrigatória". Infelizmente, as soluções alternativas listadas aqui não são muito práticas para a maioria das pessoas. Quase todas as versões anteriores são vulneráveis.

Referências

  • https://github.com/kubernetes/kubernetes/issues/60813
  • https://nvd.nist.gov/vuln/detail/CVE-2017-1002101
  • https://www.twistlock.com/2018/03/21/deep-dive-severe-kubernetes-vulnerability-date-cve-2017-1002101/
Baixar ferramenta