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
google-osconfig-privesc — Prova de conceito sobre a falha de escalonamento de privilégios identificada no Osconfig do Google | Kitploit
Ferramentas/GitHubGitHub/irsl/google-osconfig-privesc
Escalada de PrivilégiosAnálise de VulnerabilidadesExploraçãoPós-ExploraçãoTestes de PenetraçãoSegurança na NuvemRed Teaming
GitHubirsl/google-osconfig-privesc

google-osconfig-privesc

Prova de conceito sobre a falha de escalonamento de privilégios identificada no Osconfig do Google

Ver Repositório
10há 5 anosAinda não revisado

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

Resumo

O processo google_osconfig_agent é um componente das ferramentas do GoogleCloudPlatform (https://github.com/GoogleCloudPlatform/osconfig) que é executado em cada VM por padrão. O agente roda como root e é responsável por alguns serviços controláveis pelo usuário, incluindo o OS config (https://cloud.google.com/compute/docs/os-config-management), que é uma espécie de implementação do Google de configuração de estado desejado baseada em polling.

Este repositório hospeda uma demonstração sobre uma falha de escalonamento de privilégio que identifiquei na implementação (e que foi corrigida pelo Google desde então).

Problema

As tarefas a serem executadas são chamadas de recipes, e um dos tipos de recipe suportados é executar um script de shell. Ao processar tal recipe, o agente — que roda como root com todas as capacidades — salva arquivos temporariamente no diretório /tmp e depois os executa. O diretório criado pelo agente pode ser sequestrado e, assim, o script a ser executado pode ser substituído, levando efetivamente à elevação local de privilégios.

Passos para reproduzir

  1. Preparando o ambiente:
root@kitploit:~
        gcloud services enable osconfig.googleapis.com 
        gcloud compute project-info add-metadata --metadata=enable-osconfig=TRUE    
  1. Na VM, executando o script de exploração como um usuário de baixo privilégio (nobody):
root@kitploit:~
        # cat /tmp/poc.txt
        cat: /tmp/poc.txt: No such file or directory

        # pip3 install inotify_simple
        # chroot --userspec=nobody:nogroup / /home/radimre83/osconfig-privesc-poc3.py
        Running as 65534
        calling inotify.read()
        ...
  1. Configurando uma política de os-config:
root@kitploit:~
        gcloud beta compute os-config guest-policies create test-policy-poc --file="C:\Projects\gcp-app-engine-experiments\compute-engine\osconfig-policy-poc.yaml"
  1. Saída do script poc quando o runscript é implantado (pode levar de 10 a 15 minutos):
root@kitploit:~
        Event(wd=1, mask=1073742080, cookie=0, name='recipe-runscript')
        New recipe: recipe-runscript2, rename: /tmp/osconfig_software_recipes.mali1596821311/xxx-recipe-name -> /tmp/osconfig_software_recipes.mali1596821311/recipe-runscript
        New rundir recipe-runscript2, rename: /tmp/osconfig_software_recipes.mali1596821311/recipe-runscript/xxx-rundir -> /tmp/osconfig_software_recipes.mali1596821311/recipe-runscript/run_1596821899000709826
  1. Verificar:
root@kitploit:~
        # cat /tmp/poc.txt
        uid=0(root) gid=0(root) groups=0(root),1000(google-sudoers)

SO: instância f1-micro do GCE com a imagem padrão Debian 10.

A correção

O Google passou a usar um diretório temporário aleatório em vez de um previsível.

Remediação

A versão corrigida foi lançada em 2020-09-05. Você precisa atualizar seu pacote do SO.

Cenário de ataque

Esta é uma vulnerabilidade de escalonamento local de privilégios, portanto, pode ser explorada por alguém que já tenha direitos de execução de código nas VMs GCE afetadas:

  • alguém com um shell de baixo privilégio

  • um atacante por meio de um serviço de rede já comprometido

O ponto-chave é assumir o controle do "diretório base" (/tmp/osconfig_software_recipes), o que é possível se nenhuma recipe tiver sido processada na sessão atual, o que significa:

  • nenhuma recipe foi executada até agora (por exemplo, o recurso osconfig não estava em uso, mas será em algum momento posterior)

  • a VM é reiniciada e todas as recipes estão presentes no banco de dados (/var/lib/google/osconfig_recipedb), mas algumas atualizações de política são executadas em algum momento posterior

Embora essa combinação especial de fato diminua a probabilidade de exploração, acho que usar um diretório de trabalho em /tmp não é seguro aqui. (O Google também não achava, e este problema está corrigido desde então.)

Linha do tempo

2020-08-07: Problema descoberto e relatado

2020-08-08: Problema triado pelo Google, prioridade alterada para P1

2020-08-10: Problema confirmado pelo Google ("🎉 Nice catch!"), prioridade alterada para P2, severidade para S2

2020-08-14: Atualização sobre o processo do VRP

2020-09-05: Problema corrigido pelo Google

Créditos

Imre Rad

Links

https://github.com/GoogleCloudPlatform/osconfig

https://issuetracker.google.com/issues/163147689

https://github.com/GoogleCloudPlatform/osconfig/commit/fa7e4ba5ee85be212ffbac66d96862c792bd270c

https://www.linkedin.com/in/imre-rad-2358749b/

Baixar ferramenta