Hack The Box: Enigma - Report completo di penetration testing e write-up

1. Executive Summary

Enigma è una macchina Linux di livello intermedio ospitata su Hack The Box. La metodologia di assessment segue un ciclo di vita standard del penetration testing: ricognizione, enumerazione, accesso iniziale tramite raccolta di credenziali, enumerazione locale e escalation dei privilegi a root attraverso una vulnerabilità a livello di servizio (CVE-2026-27626 in OliveTin). Questo write-up dettaglia l'analisi passo-passo dei vettori, i toolset, le strategie di esecuzione del codice e le linee guida di remediation necessarie per compromettere completamente il target e ottenere il controllo amministrativo.

2. Raccolta informazioni e ricognizione

2.1 Scansione delle porte di rete (Nmap)

L'assessment è iniziato con una scansione TCP SYN per identificare le porte aperte e i servizi in esecuzione sull'host target.

nmap -p- --min-rate=1000 -T4 <TARGET_IP>

Risultati della scansione:

• Porta 22/tcp (SSH): Aperta, daemon OpenSSH in esecuzione.
• Porta 80/tcp (HTTP): Aperta, server web Nginx/Apache che ospita un'applicazione web.
• Porta 2049/tcp (NFS): Aperta, servizio di condivisione file di rete.

2.2 Enumerazione web e brute-forcing delle directory

Utilizzando strumenti di directory discovery (gobuster / ffuf), abbiamo scansionato il servizio web sulla porta 80 per scoprire endpoint nascosti, portali amministrativi o artefatti di configurazione.

• Scoperta una presenza web pubblica e post di blog di sviluppatori che delineano componenti dell'infrastruttura interna.
• Identificati potenziali percorsi applicativi relativi a file di configurazione del database e script di automazione.

3. Accesso iniziale (compromissione a livello utente)

3.1 Scoperta delle credenziali

Attraverso un'analisi dettagliata dei file dell'applicazione web e delle condivisioni NFS ausiliarie, abbiamo scoperto credenziali di sviluppatore valide.

• Username: haris
• Password: bestfriends

3.2 Stabilire la shell utente tramite SSH

Con le credenziali scoperte, ci siamo autenticati al servizio SSH per stabilire una shell interattiva a bassi privilegi sul sistema target:

ssh haris@<TARGET_IP>

• Shell interattiva ottenuta: haris@enigma:~$
• Individuato e recuperato con successo la flag utente (user.txt).

4. Enumerazione locale e scoperta dell'escalation dei privilegi

4.1 Audit dei servizi interni

Dopo aver stabilito una shell a livello utente, abbiamo esaminato le porte in ascolto locali e i processi attivi per identificare potenziali superfici di attacco non esposte esternamente:

ss -tulpn

Scoperta chiave:

• Il servizio web di gestione dell'automazione OliveTin era in esecuzione localmente su 127.0.0.1:1337 con privilegi root.

4.2 Analisi della configurazione e delle vulnerabilità di OliveTin

Un'ulteriore ispezione del file di configurazione dell'applicazione OliveTin (/opt/OliveTin/config.yaml) ha rivelato che le azioni di backup del database venivano eseguite tramite un wrapper shell. Nello specifico, la configurazione utilizzava il parametro db_pass all'interno di una stringa di comando mysqldump:

shell: "mysqldump -u {{ db_user }} -p'{{ db_pass }}' {{ db_name }} > /opt/backups/backup.sql"
arguments:
  - name: db_pass
    type: password

Questa configurazione introduce una vulnerabilità critica di command injection (CVE-2026-27626) perché il parametro db_pass è racchiuso tra apici singoli in un contesto shell, ma non sanifica adeguatamente l'input contenente operatori di controllo della shell (ad esempio, punti e virgola ;, pipe | o backtick).

5. Strategia di sfruttamento ed esecuzione (CVE-2026-27626)

5.1 Configurare un tunnel di port forwarding SSH

Poiché il servizio OliveTin vulnerabile è vincolato strettamente a 127.0.0.1:1337, le richieste esterne dalla macchina attaccante Kali vengono bloccate con un errore Connection refused. Per interfacciarci con il servizio, abbiamo stabilito un tunnel di port forwarding locale tramite SSH:

ssh -L 1337:127.0.0.1:1337 haris@<TARGET_IP>

5.2 Creazione ed esecuzione del payload di exploit

Utilizzando uno script di exploit Python che prende di mira l'endpoint API di OliveTin (/api/olivetin.api.v1.OliveTinApiService/StartAction), abbiamo iniettato comandi di sistema arbitrari nel vettore del parametro vulnerabile.

A causa della sintassi shell rigorosa e delle dipendenze di directory nel wrapper originale del comando mysqldump, la creazione diretta di file poteva talvolta comportare errori di exit status (come directory target mancanti o vincoli di permessi). Creando stringhe di esecuzione precise o interrogando direttamente il file system attraverso la vulnerabilità API, abbiamo aggirato gli ostacoli all'esecuzione.

Esecuzione del payload del comando tramite l'interfaccia di exploit:

python3 CVE-2026.27626.py -u http://127.0.0.1 -x "cat /root/root.txt"

Output dell'esecuzione:

[+] Execution ID: 7fd15259-3996-4e03-9ebd-329034ee4e0d
======================================================================
Command Output
======================================================================
exit status 127
Usage: mysqldump [OPTIONS] database [tables]
...
ae9306f5690c4812c6f9445027d0d060
sh: 1: : Permission denied
======================================================================

La flag root è stata estratta con successo direttamente attraverso il flusso di output del comando.

6. Post-exploitation ed evidenze di compromissione

• Flag root ottenuta: ae9306f5690c4812c6f9445027d0d060
• Persistenza amministrativa: Un meccanismo di persistenza alternativo prevede l'aggiunta di una chiave pubblica SSH a /root/.ssh/authorized_keys tramite il vettore di command injection, garantendo un accesso amministrativo continuo al terminale.

7. Remediation e raccomandazioni di difesa

1. Sanitizzazione e parametrizzazione dell'input: Assicurarsi che i parametri dell'applicazione passati ai comandi di sistema (come le password del database in OliveTin) siano rigorosamente validati rispetto a set di caratteri alfanumerici, proibendo metacaratteri shell grezzi.
2. Principio del minimo privilegio: Evitare di eseguire software di automazione gestionale come OliveTin nel contesto di sicurezza root a meno che non sia assolutamente necessario. Eseguire i servizi con account di servizio dedicati con permessi minimi.
3. Aggiornamenti software: Aggiornare OliveTin e i wrapper di automazione associati a versioni patchate in cui le vulnerabilità di command injection tramite parametri templated sono mitigate.
4. Segmentazione di rete: Limitare le interfacce di gestione dal binding alle interfacce di loopback se la supervisione amministrativa richiede autenticazione a più fattori o liste di controllo degli accessi (ACL) a livello di rete.