HackTheBox BountyHunter machine walkthrough
Questo articolo sarà dedicato al walkthrough della macchina BountyHunter (difficoltà facile) presente in HackTheBox.
Si tratta di una macchina ormai “retired”, di cui ho recuperato sia lo user che il system flag alcuni mesi fa (ottobre 2021) quando era ancora attiva.
Piccolo disclaimer: ovviamente non prendete come corretto e perfetto al 100% il modus operandi descritto. Sono convinto che si sarebbe potuti arrivare in maniera diversa e piú veloce alla cattura dei flag. In ogni caso ritengo sia interessante vedere le prove e i ragionamenti fatti, oltre ai tools usati. Questo per riesaminarli anche a distanza di tempo. D’altronde si impara dai propri errori, specie se sei alle prime armi.
I just pwned BountyHunter in Hack The Box! https://t.co/emfawVy6yU #hackthebox #htb #cybersecurity
— Massimo Rabbi (@fud0_ita) October 10, 2021
Passaggi
Per prima cosa effettuiamo la “classica” scansione con Nmap in modo avere una visione a grandi linee di quali porte/servizi la macchina espone:
nmap -T4 -p- -A 10.10.11.100
Operiamo una serie di ulteriori scansioni con altri tools:
-
ffuf, niente di particolarmente interessante
-
nikto, un riferimento potenzialmente utile e da approfondire
OSVDB-3093: /db.php: This might be interesting... has been seen in web logs from an unknown scanner.
-
dirbuster, anche qui tra le varie risorse individuate il file “db.php”
-
dirb, niente di particolarmente interessante
Proseguiamo quindi provando ad accedere al sito web e navigare in modo da capire in cosa consiste l’applicazione web pubblicata.
- indirizzo http://10.10.11.100/
- usiamo Burp (+ plugin FoxyProxy) per registrare il traffico e individuare indizi
- notiamo che il form di contatto é “fake” visto che non sembrano venir passati i dati inseriti.
In piú gli script Javascript che dovrebbero servire ad un possible check/validazione restituiscono un codice errore 404
/assets/mail/jqBootstrapValidation.js /assets/mail/contact_me.js
Seguendo invece il link al portale http://10.10.11.100/portal.php si ottiene accesso all’applicazione vera e propria. Un sistema di ticketing per inviare i bug.
Inserendo dati di test sembra vengano simulate le potenziali operazioni in caso d’inserimento a database.
Da notare tra i file individuati da Burp o eventualmente nel pannello Network di Firefox:
-
bountylog.js contenente apparentemente il codice utilizzato per inviare i dati attraverso una richiesta Ajax (XMLHttpRequest)
-
tracker_diRbPr00f314.php responsabile della eventuale manipolazione dei dati del form e del risultato restituito
Come si puó notare il campo data viene codificato utilizzando prima URL-encoding e poi Base64 come algoritmi.
Ora partendo dal contenuto originale (non codificato) del campo data sorge spontaneo pensare che si possa
provare un attacco di tipo XXE (XML External Entity).
Si tratta quindi di fare qualche prova cercando di preparare uno snippet che tenti di leggere file locali, come il classico /etc/passwd.
Arrivati a questo punto quello che possiamo tentare di fare é provare a leggere il file db.php che abbiamo individuato sopra. È molto probabile infatti che contenga informazioni interessanti, come credenziali di accesso. Poiché però stiamo tentando di leggere un file .php dobbiamo utilizzare una strategia leggermente diversa adottando un piccolo trick come descritto qui.
Ricordando che la macchina espone anche un servizio SSH possiamo provare a collegarci utilizzando come account utente development, ovvero quello piú “sensato” recuperato dal file passwd. Nell’ottica della “classica” problematica del riuso della password proveremo a collegarci utilizzando la password appena individuata.
Proseguiamo velocemente con l’analisi della home folder e oltre al contenuto del file contract.txt proviamo a vedere se l’utente development é nella lista sudoers. Cerchiamo anche di capire quali comandi puó eventualmente eseguire senza bisogno di autenticazione.
Alla ricerca di ulteriori possibili punti di accesso per tentare una privilege escalation utilizziamo uno strumento come LinPEAS. Questo script non fa altro che cercare all’interno del sistema svariati modi per ottenerla, controllando nei log, lista applicazioni installate e così via. Utilizziamo un semplice comando Python per avviare un server web minimale nella nostra macchina e trasferirlo nella macchina compromessa (da cui useremo wget).
python3 -m http.server 80
Appare evidente che dobbiamo provare a concentrarci sul file ticketValidator.py che puó essere eseguito con privilegi di amministratore. Da una rapida analisi del codice Python dello script sembra che il possibile “punto debole” sia l’uso della funzione eval() senza particolari controlli. Proviamo quindi a eseguire il programma controllando anche ticket non validi, in modo da avere una idea ancora piú precisa di cosa fa lo script.
Possiamo quindi provare a “costruire” un ticket finto che consenta di eseguire un semplicissimo comando ls in grado di listare il contenuto della home directory di root. Utilizzando semplicemente l’operatore and e la logica booleana.
Vediamo ora di recuperare correttamente la System flag per completare l’opera!
“Machine takeways”
- effettuare come buona norma una prima scansione con Nmap (e eventualmente Nikto)
- effettuare “dirbusting” con piú di un tool (i.e ffuf,dirb,dirbuster)
- navigare “manualmente” sul sito e tener traccia di quello che succede, per esempio sfruttando Burp Suite (log history, scope restriction)
- ricordarsi di consultare la top 10 OWASP: in questo caso abbiamo sfruttato una XXE
- importanza dei tabs Proxy e Repeater in Burp Suite durante la fase di testing
- prestare attenzione all’encode/decode dei payload. A volte piú di un algoritmo viene impiegato (i.e UURLEncode + Base64)
- una volta nel sistema ricordarsi sempre quale utente sta eseguendo le operazioni e l’eventuale uso di path relativi/assoluti
- ricordarsi del fattore “umano” nel riuso delle password
- ricordarsi di verificare le cartelle piú comuni ma anche quelle temporanee
- “sudo -l” comando fondamentale che puó tornare utile in molte occasioni
- LinPEAS é utile come strumento anche se bisogna imparare a leggere attentamente il suo report, stando attenti ad eventuali false flags
- conoscere Python é un plus molto utile (i.e. eval() and __import__)
Note aggiuntive
Nell’analisi dei risultati ottenuti dall’enumeration iniziale non ho prestato troppa attenzione al file README.txt che ho consultato solo successivamente. Questo avrebbe potuto darmi giá da subito alcune indicazioni interessanti su come muovermi. Il suo contenuto era infatti abbastanza auto-esplicativo:
Tasks:
[ ] Disable 'test' account on portal and switch to hashed password. Disable nopass.
[X] Write tracker submit script
[ ] Connect tracker submit script to the database
[X] Fix developer group permissions
Riferimenti, links e approfondimenti
- XXE attack:
- https://portswigger.net/web-security/xxe
- https://book.hacktricks.xyz/pentesting-web/xxe-xee-xml-external-entity
- https://www.blackhillsinfosec.com/xml-external-entity-beyond-etcpasswd-fun-profit/
- https://www.synack.com/blog/a-deep-dive-into-xxe-injection/
- https://github.com/luisfontes19/xxexploiter
- https://airman604.medium.com/from-xxe-to-rce-with-php-expect-the-missing-link-a18c265ea4c7
- https://hackingprofessional.github.io/Security/How-to-hack-a-website-with-XML-External-Entity-Injection/
- Privilege Escalation:
- Funzione eval() e altro :
- Pentest cheatsheet: https://github.com/savenas/cheatSheatForPentest
- Online tools: