__
/ \--..____
\ \ \-----,,,..
\ \ \ \--,,..
\ \ \ \ ,'
\ \ \ \ ``..
\ \ \ \-''
\ \ \__,,--'''
\ \ \.
\ \ ,/
\ \__..-
\ \ TryHackMe Writeup
\ \
\ \
\ \
\ \
\ \
\ \
[0x1] Enumeração 
[0x3] Acesso via SSH 
[0x4] SUID, O que é? 
[0x5] Bypass AppArmor E Conseguir Acesso a Root
Olá, pessoal! Hoje estarei fazendo o write-up da máquina Publisher para dar início à nossa série de posts de CTF.
Essa máquina é classificada como Easy. Nela, vamos explorar uma aplicação web vulnerável a RCE (Remote Code Execution) e faremos a escalação de privilégios.
Em algumas prints, o IP da máquina vai Mudar (a máquina desligou no meio do tempo XD).
Para começar, vamos iniciar com a enumeração padrão do alvo. Estarei usando a ferramenta RustScan uma ótima opção para enumeração rápida, ideal para CTFs.
───────────────── Enumeração
──── rustscan.png ──────────────────────────────────
────────────────────────────────────────
Aqui verificamos que temos apenas duas portas abertas:
22 - SSH
80 - Http 
Bom, quando acessamos o site, a página está estática, sem interações.
Acho que já podemos pular para a descoberta de diretórios, e para isso estarei utilizando a ferramenta GoBuster - perfeita para fuzzing e outros tipos de bruteforce para descobrir diretórios e outras coisas.
──── gobuster.png ──────────────────────────────────
────────────────────────────────────────
Bom, descobrimos alguns diretórios, sendo a maioria padrão. Porém, dentre eles há um chamado:
/spip
Nesse diretório, encontramos uma página que parece ser um blog. Utilizando o Wappalyzer
descobri que o servidor está rodando SPIP, um CMS pouco comum.
──── wappalyzer.png ──────────────────────────────────
────────────────────────────────────────
Pelo Wappalyzer podemos perceber que ele está rodando na versão 4.2.0. Vamos verificar se existem
exploits publicados para essa versão. Existem vários métodos de pesquisa tanto manuais quanto
utilizando programas, Hoje irei utilizar o Metasploit, um framework com funcionalidades para
reconhecimento, exploração e pós-exploração.
───────────────── Exploração Utilizando O Metasploit [ 0x2 ]
No Metasploit, vamos utilizar o comando search para localizar um exploit adequado.
──── search-exploit.png ──────────────────────────────────
────────────────────────────────────────
Vamos verificar se o exploit spip_rce_form é compatível com nossa versão do SPIP. Para isso
utilizamos os seguintes comandos no Metasploit:
use exploit/multi/http/spip_rce_form
info
Assim, visualizaremos todas as informações referentes ao exploit, incluindo versões compatíveis.
──── show-info.png ──────────────────────────────────
────────────────────────────────────────
Pela descrição, o exploit é compatível com nossa versão. Vamos à exploração!
Para configurar o exploit corretamente, utilizamos o comando: show options
──── show-options.png ──────────────────────────────────
────────────────────────────────────────
Isso nos mostrará todos os parâmetros necessários para executar o exploit, incluindo:
LHOST = Nosso IP que vai receber a conexão: Coloquei a placa da VPN
RHOST = A Url para explorar o alvo
Mudando esses 2 já podemos rodar o exploit usando o comando: run
──── exploit.png ──────────────────────────────────
────────────────────────────────────────
E Vualá! 
Temos Shell na máquina, porem é de um www-data, vamos escalar os nossos privilégios.
Para isso, verifiquei se temos permissão de leitura em /home e ela nos retornou que podemos.
Olhar a pasta do usuário think.
Logo, pensei em procurar o id_rsa para verificar se podemos ler e acessar o ssh dele.
───────────────── Acesso via SSH [ 0x3 ]
──── id-rsa.png ──────────────────────────────────
────────────────────────────────────────
Agora vamos acessar o ssh dele utilizando a id_rsa
Para quem não conhece, a id_rsa serve como um método de verificação que, em alguns casos,
Só utilizando a id_rsa você não precisa fornecer a senha do usuário.
Para utilizar a Chave SSH é preciso dar chmod 600 id_rsa para que ela esteja nas permissões corretas.
──── user-pwn.png ──────────────────────────────────
────────────────────────────────────────
Ótimo, escalamos para mais um usuário e conseguimos nossa 1 Flag (user.txt) 
Bom, agora temos várias coisas para explorar para tentar ter o acesso de root, procurando SUIDs
Verificando Versão de Kernel, Olhando processos e afins, Vamos Começar Olhando Suid.
Para começar a explorar, vou explicar O que é SUID e como explorar:
───────────────── SUID, O que é? [ 0x4 ]
SUID (Set User ID) é uma permissão especial em sistemas Unix/Linux que, quando definida em um O arquivo executável permite que o programa seja executado com as permissões do proprietário do. Arquivo, quer um exemplo prático?
O comando passwd ele tem SUID sobre o usuário Root, pois ele precisa escrever o arquivo /etc/shadow
Você pode identificar SUIDs porque nas permissões do arquivo vista usando ls -l você pode notar.
Que o x nas permissões do dono é trocado para um s
Isso estando em binários como passwd está tudo bem, pois existe uma segurança ao utiliza-lo. Porém, se alguém colocar SUID em binários mal criados ou scripts com falhas de segurança, podemos. Utilizar para escalar o privilégio de usuário para usuário.
Bom já que expliquei sobre SUID, vamos utilizar um comando simples para procurar os arquivos com. SUID ativado.
find / -perm -u=s -ls 2>/dev/null
──── suid-find.png ──────────────────────────────────
────────────────────────────────────────
Aqui percebemos que temos um SUID incomum das que é comum achar em máquinas Linux conversionais.
/usr/sbin/run_container 
Vamos rodar, o arquivo run_container para analizar e verificar alguma vulnerabilidade para explorar.
──── run_container.png ──────────────────────────────────
────────────────────────────────────────
O binário run_container tenta rodar o arquivo /opt/run_container.sh com o commando
validate_container_id, bom, vamos verificar o arquivo.
Quando fui verificar, o arquivo /opt/run_container.sh nem existia, então vamos tentar cria-lo.
e colocar um spawn de shell lá dentro.
Porém, quando fui editar o arquivo usando: /opt/run_container.sh, tive uma pequena surpresa.
──── not-writable.png ──────────────────────────────────
────────────────────────────────────────
Descobrimos que o diretório “/opt/” não pode ser escrito, o que me deixou mais um desafio: burlar
essa restrição de escrita. Uma das coisas que pode nos impedir de editar diretórios pode ser o
AppArmor (Application Armor), um sistema de segurança baseado em perfis que restringe o que os
aplicativos podem fazer no Linux. Ele funciona até mesmo se o usuário for root.
Mas antes de verificar isso, vamos ver qual shell estamos usando: /sh, /bash ou /zsh.
───────────────── Bypass AppArmor E Conseguir Acesso a Root 
──── -ash.png ──────────────────────────────────
────────────────────────────────────────
-ash? 
Tudo bem. Bom, acho estranho pois não estamos em nenhum BusyBox, mas seguindo isso
vamos verificar nossas regras do AppArmor vendo o arquivo /etc/apparmor.d/usr.sbin.ash.
──── ash-flags.png ──────────────────────────────────
────────────────────────────────────────
Bom, podemos verificar que nossa shell não pode escrever no diretório /opt/ usando essa shell.
Vamos dar bypass nesse AppArmor. Para isso, vamos utilizar uma shellbang que eu peguei Aqui
──── bps.pl ────────────────────────────────── #!/usr/bin/perl use POSIX qw(strftime); use POSIX qw(setuid); POSIX::setuid(0); exec “/bin/sh” ──────────────────────────────────────── Bom, vamos executar esse shellbang para trocar nossa shell para um /bin/sh.
──── bypass-ash.png ──────────────────────────────────
────────────────────────────────────────
YESS! 
Agora podemos escrever nosso arquivo /opt/run_container.sh e colocar nosso exploit para
subir nossos privilégios para root.
──── r00ted.png ──────────────────────────────────
────────────────────────────────────────
Agora podemos já pegar nossa última flag em /root/root.txt. 
