Qubes OS Pentest Escalação de Privilégio Local Kernel Vulnerável + Backdoor

Cenário Controlado em Rede Privada 10.60.0.0/24

Este laboratório reproduz um cenário real de rede corporativa vulnerável. Toda a operação ocorre em uma rede privada isolada 10.60.0.0/24, sem qualquer exposição à internet, garantindo que os testes sejam éticos e controlados. A topologia é composta por três elementos centrais:

• Roteador/Gateway - 10.60.0.1, ponto de saída e segmentação da rede.
• Máquina atacante - Qubes OS rodando template Parrot OS em 10.60.0.237.
• Máquina alvo (vítima) - Ubuntu 8.04 Hardy com kernel 2.6.24-16-server em 10.60.0.209.

A escolha do Qubes OS como plataforma de ataque não é casual: é o sistema operacional mais robusto para atividades ofensivas, pois isola cada ferramenta e cada alvo em qubes distintos. Se o ataque comprometer a máquina alvo, o Parrot OS permanece confinado em seu domínio, impedindo movimento lateral para o sistema hospedeiro.

Por Que o Alvo é Vulnerável

O Ubuntu 8.04 Hardy com kernel 2.6.24-16-server foi lançado em abril de 2008 e carrega consigo uma série de vulnerabilidades já catalogadas. Esse kernel é contemporâneo a exploits devastadores como CVE-2008-0600 (vmsplice), CVE-2008-0900 (ptrace), CVE-2009-2692 (sock_sendpage) e CVE-2009-3547 (pipe.c 32-bit) - todos exploráveis localmente por qualquer usuário autenticado.

Hydra: A Hidra de Muitas Cabeças do Brute Force

O Hydra (ou THC-Hydra) é um dos mais poderosos e versáteis crackers de login de rede. Ele suporta mais de 50 protocolos, incluindo SSH, Telnet, FTP, HTTP, RDP, SMB e muitos outros. Sua arquitetura multithread permite testar milhares de credenciais por segundo, tornando-o ideal para ataques de dicionário contra serviços expostos.

No nosso laboratório, já conhecemos o nome de usuário (ryu), o que reduz drasticamente o espaço de busca: em vez de testar usuário × senha, testamos apenas senha. Isso é comum em ambientes corporativos onde nomes de usuário seguem um padrão previsível (nome.sobrenome, primeiro nome, etc.).

Ataque contra SSH

SSH (Secure Shell) é o protocolo mais comum para administração remota. Mesmo sendo criptografado, o processo de autenticação pode ser atacado por força bruta se não houver rate limiting ou fail2ban.

Ataque contra Telnet

Telnet é um protocolo legado que transmite credenciais em texto plano. Se estiver habilitado (e muitas vezes está, por esquecimento em sistemas antigos), é ainda mais rápido de quebrar que SSH.

Explicação dos Parâmetros

• -l ryu - usuário único (economiza tempo evitando testar vários usuários).
• -P arquivo - caminho para o dicionário de senhas.
• -t 8 - 8 threads paralelas (aumenta velocidade; valores altos podem causar DoS no serviço).
• -f - finaliza ao encontrar a primeira credencial válida.
• -V - verbose, mostra cada tentativa em tempo real.

Identificando o Alvo Antes de Atacar

Uma vez dentro do sistema, o atacante precisa mapear o terreno. O objetivo é responder três perguntas fundamentais: Qual a versão do kernel?, Qual a distribuição? e Quais serviços e versões estão rodando?

Comandos de Coleta Inicial

Decifrando a Saída do uname -a

• Linux - nome do kernel.
• metasploitable - hostname da máquina (dica óbvia de ambiente propositalmente vulnerável).
• 2.6.24-16-server - versão exata do kernel: este é o dado mais valioso.
• #1 SMP - build número 1, com Symmetric MultiProcessing ativo.
• Thu Apr 10 13:58:00 UTC 2008 - data de compilação (16 anos de atraso de patches).
• i686 - arquitetura 32 bits x86.

Enumeração Avançada via Metasploit

Após estabelecer sessão via auxiliary/scanner/ssh/ssh_login, podemos executar módulos de pós-exploração para automatizar a coleta:

• post/linux/gather/enum_system - informações gerais do sistema.
• post/linux/gather/enum_configs - arquivos de configuração sensíveis.
• post/linux/gather/enum_network - interfaces, rotas e conexões.
• post/linux/gather/enum_protections - verifica ASLR, SELinux, AppArmor.
• post/linux/gather/enum_users_history - histórico de comandos de usuários.
• post/linux/gather/checkvm - detecta se está em VM.
• post/linux/gather/checkcontainer - detecta containers Docker/LXC.
• post/linux/gather/enum_containers - enumera containers em execução.
• post/linux/gather/enum_command - busca binários com SUID/SGID (consulte GTFOBins).

A Anatomia do Bug: NULL Pointer Dereference no Kernel

A CVE-2009-2692 é uma das vulnerabilidades mais elegantes já descobertas em kernels Linux. O problema reside no fato de que os desenvolvedores esqueceram de inicializar o ponteiro de função sendpage na estrutura proto_ops para sockets do tipo PF_PPPOX (e outros tipos exóticos de socket como PF_BLUETOOTH).

Quando um usuário local cria um socket desse tipo e chama a syscall sock_sendpage, o kernel dereferencia um ponteiro NULL. Em arquiteturas x86 32-bit, o espaço de endereço 0 é mapeável pelo usuário (se vm.mmap_min_addr não estiver configurado). Assim, o atacante mapeia código malicioso em 0x00000000, e o kernel - com privilégio de anel 0 - executa o payload.

O resultado é uma escalada de privilégio local trivial: qualquer usuário autenticado vira root em segundos.

Configurando a Sessão no Metasploit

Primeiro, estabelecemos sessão no alvo usando o scanner de SSH. Depois, colocamos em background e usamos o exploit local com essa sessão.

Explorando com sock_sendpage

Versão One-Line do Ataque

Para automação ou repetição rápida, o mesmo ataque pode ser condensado em uma linha:

A Ilusão do Antivírus Tradicional

Antivírus convencionais não protegem contra escalada de privilégio local. Eles monitoram arquivos maliciosos conhecidos, mas não detectam a exploração de vulnerabilidades legítimas do kernel. Uma vez que o atacante tem acesso local (via SSH, Telnet, pendrive ou zero-click), o antivírus é irrelevante.

A defesa real exige monitoramento contínuo de vulnerabilidades, hardening de kernel, IDS/IPS e - acima de tudo - arquitetura de compartimentalização.

1. Kernel Hardening: vm.mmap_min_addr

A defesa mais direta contra CVE-2009-2692 é impedir que o usuário mapeie memória no endereço 0. O parâmetro vm.mmap_min_addr controla o menor endereço de memória que um processo não privilegiado pode mapear.

2. Monitoramento e Aviso de Novos Exploits

Um sistema de defesa eficaz precisa de vigilância contínua sobre:

• Kernel - assinar listas de CVE (NVD, MITRE, distro security trackers).
• Programas instalados - inventariar e cruzar versões com bancos de vulnerabilidades.
• Serviços expostos - parar o serviço se não houver patch disponível.
• Mitigações temporárias - aplicar workarounds até o patch definitivo.

3. IDS e Detecção de Enumeração Local

Um IDS (Intrusion Detection System) bem configurado pode detectar o padrão de enumeração típico de pós-exploração. Processos como uname -a, lsb_release, find / -perm -4000 em sequência rápida são um forte indicativo de ataque local em andamento.

Recomendações:

• Enviar logs para servidor remoto (imutável).
• Alertar via e-mail/Syslog quando arquivos críticos (.bashrc, .bash_profile, /etc/passwd) forem modificados.
• Monitorar criação de processos suspeitos com privilégios elevados.

4. Ferramentas de Enumeração Defensiva

As mesmas ferramentas usadas por atacantes servem para auditoria defensiva. Rodar regularmente e corrigir o que for encontrado:

• LinPEAS - github.com/peass-ng/PEASS-ng
• LinEnum - github.com/rebootuser/LinEnum
• Linux Smart Enumeration - github.com/diego-treitos/linux-smart-enumeration
• unix-privesc-check - github.com/pentestmonkey/unix-privesc-check
• grype - scanner de vulnerabilidades em containers e sistemas de arquivos.

5. Compartimentalização com Qubes OS

A defesa mais poderosa é a arquitetura de compartimentalização. O Qubes OS divide o sistema em múltiplas VMs isoladas (qubes), cada uma com função específica: trabalho, finanças, pessoal, untrusted, disposables.

• Named Disposables - ambientes que se autodestroem ao fechar, revertendo qualquer comprometimento.
• NetVM isolada - todas as conexões de rede passam por uma VM dedicada, dificultando vazamento de IP real.
• Dom0 isolado - o domínio de controle nunca se comunica com a internet.

Se um atacante compromete uma qube, ele fica preso nela. Não consegue escalar para Dom0, não consegue acessar outras qubes, não consegue persistir além do ciclo de vida da VM. Isso é security by isolation levado ao extremo.

6. Defesa em Profundidade: A Estratégia Completa

Nenhuma medida isolada é suficiente. A estratégia robusta combina:

• Política de senhas fortes - elimina o vetor de entrada mais comum.
• Atualização contínua de kernel e pacotes - fecha vulnerabilidades conhecidas.
• Kernel hardening - vm.mmap_min_addr, ASLR, SELinux/AppArmor.
• IDS e monitoramento - detecta ataques em andamento.
• Compartimentalização - Qubes OS, VMs, containers.
• Disposable environments - nada persiste além do necessário.
• Educação do usuário - o fator humano é o elo decisivo.