Oggi descriveremo la violazione di una macchina (https://tryhackme.com/room/teamcw) che sfrutta una scarsa riservatezza di dati critici e una nota vulnerabilità dei siti internet chiamata LFI, Local File Inclusion che permette ad un hacker di interagire attraverso un sito web con i file residenti sulla macchina che lo ospita.
L’obbiettivo è conquistare l’accesso ad una macchina linux per poter leggere il file user.txt e successivamente fare privilege escalation accedendo al file root.txt.
Per prima cosa lanciamo una scansione delle porte con il tool nmap:
- -sS è l’opzione per una scansione silenziosa;
- -p- è l’opzione per scansionare tutte le porte del sistema.
La risposta arriva piuttosto velocemente e ci permette di scoprire che la nostra vittima è in ascolto sulle porte:
- 21/tcp con il protocollo FTP usato per mettere a disposizione file e cartelle sulla rete;
- 22/tcp con il protocollo SSH, questo vuol dire che c’è la possibilità di connettersi alla macchina da remoto, per fare questo dobbiamo trovare della credenziali di accesso o almeno uno username per tentare un attacco Brute-Force alla password;
- 80/tcp con il protocollo http, in altre parole questa macchina ospita un sito web.
Il protocollo FTP consente spesso l’accesso come utenti anonimi (Username:anonymous e password in bianco), quindi senza nemmeno pensarci su proviamo a connetterci per scoprire che purtroppo il login come utente anonymous non è disponibile.
A questo punto non avendo ancora della credenziali con il quale tentare la connessione remota alla macchina via porta 22/SSH, dedichiamoci all’analisi della pagina web ospitata dal sito che ci presenta una schermata di default del web-server Apache; leggendola non si trova nulla di interessante, ma controllando il codice sorgente scoviamo una nota dello sviluppatore che ci suggerisce l’esistenza alla stesso indirizzo IP di un altro sito: team.thm.
Prima di visitare il nuovo sito lanciamo una scansione con il tool gobuster per mappare il sito e scoprire altre pagine da visitare:
- dir permette di enumerate le directory ospitate dal sito;
- -u indica che si vuole enumerare un url;
- –wordlist specifica il file contenente i nomi delle potenziali pagine/directory
L’esito della scansione è infruttuoso, quindi lasciamo perdere la pagina ospitata all’indirizzo IP della nostra vittima e concentriamoci sulla pagina team.thm; per visitarla facciamo riferimento alla modifica del file “hosts” sul nostro sistema come in figura.
Adesso possiamo visitare la pagina team.thm dal nostro browser che non offre nulla di interessante ed anche analizzandone il codice sorgente non si trovano indizi di sorta.
Proviamo allora a lanciare gobuster, questa volta contro team.thm, il risultato è più interessante infatti abbiamo diverse cartelle(vedere l’immagine sotto) e il file robots.txt all’indirizzo team.thm/robots.txt che se visitano ci restituisce solo un nome “dale“; abbiamo scoperto il nome di un utente della macchina, ma è ancora poco per connetterci via SSH, si potrebbe tentare un attacco Brute-Force, ma meglio tenere questa ipotesi come estrema ratio.
Come possiamo vedere dall’immagine di sopra abbiamo tre pagine interessanti:
- /assets e /scripts che non possono essere visualizzate;
- /images che contiene le immagini del sito.
A questo punto utilizziamo di nuovo gobuster per verificare il contenuto della cartella “scripts” che sembra decisamente interessante aggiungendo alla fine l’opzione -x che ci permette di specificare l’estensione dei file da cercare. Il risultato è la scoperta della pagina /team.thm/scripts/script.txt. Visitandola possiamo leggere il contenuto dello script e soprattutto la nota conclusiva che suggerisce la presenza di credenziali valide per l’accesso al server FTP (porta 21/tcp) in una vecchia versione dello script stesso .
Torniamo su gobuster e questa volta cerchiamo nella cartella “scripts” un file che abbia le estensioni classiche di vecchi file o backup, .old, .bak, .new, ed ecco un file alla pagina /team.thm/scripts/script.old che aperto ci fornisce le credenziali per accedere al server ftp.
Conquistate le credenziali di accesso al server FTP connettiamoci e dalla cartella “workshare” scarichiamo il file New_site.txt che ci suggerisce la presenza di un ulteriore sito sotto “dev.team.thm” e che una copia della chiave id_rsa degli utenti, utilizzata in luogo delle password, può essere trovata nei file di configurazione dei sistemi, probabilmente dell’SSH.
A questo punto aggiungiamo dev.team.thm al nostro file hosts ed ecco la nuova pagina web che non ci dice nulla di particolarmente interessante non fosse per il link che porta alla pagina “http://dev.team.thm/script.php?page=teamshare.php“. Questa nuova pagina si rivela estremante interessante, infatti contiene uno script che attraverso l’URL permette di leggere i file all’interno della macchina che stiamo attaccando. Proviamo a visualizzare altri file ad esempio il file passwd contenuto nella directory etc.
In effetti il file si può visualizzare e quindi abbiamo la prova dell’esistenza di una vulnerabilità LFI.
Cerchiamo di sfruttare questa debolezza lanciando il programma Burp. Attraverso il browser integrato intercettiamo la pagina che presenta la vulnerabilità e giriamola al tool Sniper. Selezioniamo “teamshare.php” e clicchiamo su “add”, poi passiamo alla tab “payload” e sotto “Payload settings” usiamo il pulsante “load” per caricare una wordlist contenuto nel pacchetto seclist, (puoi scaricare le wordlist di seclist a questo indirizzo) che ci permette di sostituire la parte di URL selezionata con una lista di file tipici delle installazioni linux. Ordiniamo i risultati per lunghezza, i risultati con lunghezza “204” sono file non raggiungibili, i risultati con dimensioni diverse sono invece i file disponibili e tra questi sembra essere particolarmente interessante il file “sshd_config” che potrebbe contenere informazioni per connettersi al server attraverso il protocollo SSH sulla porta 22.
E in effetti visitando la pagina corrispondente al percorso del file “sshd_config” possiamo leggere la chiave id_rsa dell’utente “dale“. A questo punto apriamo un editor di testo e copiamo al suo interno il testo a partire da “—–BEGIN OPENSSH PRIVATE KEY—–” e finendo con “—–END OPENSSH PRIVATE KEY—– ” con l’accortezza di sostituire ogni # con una nuova linea e salviamo il file con il nome di “dale.key“
Adesso abbiamo tutto il necessario per accedere al server tramite SSH ed ecco che la prima flag (user.txt) è nostra.
Conquistato l’accesso alla macchina ora bisogna cercare di elevare i nostri privilegi per accedere al file root.txt nella cartella root, in altre parole bisogna diventare amministratori della macchina. Curiosando tra i file e le cartelle del sistema scopriamo che la macchina ospita altri due utenti, Gyles e ftpuser, ma non sembra esserci nulla di interessante che riguarda l’utente dale, proviamo allora a lanciare il comando “sudo -l” che elenca i percorsi nei quali si trovano i programmi per l’utente “Dale” ed eventuali file speciali che può lanciare.
Il risultato è interessante indicando che l’utente dale può lanciare il file “admin_checks” impersonando l’utente Gyles. Attraverso il comando “cat” seguito dal percorso /home/gyles/admin_checks andiamo a leggere questo script.
Lo script presenta una grossa vulnerabilità, alla riga “read -p “Enter ‘date’ to timestamp the file: ” error” chiede all’utente di inserire un testo che viene salvato come variabile “error” e poi passato direttamente al sistema alla riga “$error 2>/dev/null“.
Lanciamo lo script con “sudo -u gyles /home/gyles/admin_checks” dove -u permette di impersonare l’utente “gyles” e quando richiesto inseriamo il comando “/bin/bash” per realizzare una privilege escalation orizzontale, ossia passare dall’utente “dale” all’utente “gyles“che hanno permessi simili.
Dopo aver verificato con il comando “whoami” di aver avuto successo rendiamo la shell completamente interattiva e quindi più leggibile e facile da usare attraverso il comando “python3 -c ‘import pty;pty.spawn(“/bin/bash”)‘”.
Adesso dobbiamo trovare il modo di diventare amministratori di sistema (utente root), quindi visto che il comando “sudo -l” ci richiede di sapere una password che non abbiamo; curiosiamo tra i file del sistema sino a trovare nel percorso /opt/admin_stuff lo script “script.sh“. Dallo script deduciamo che esistono due altri script che ogni minuto fanno il backup del sito. Controllando i permessi notiamo che lo script “main_backup.sh” appartiene all’utente “root“, ma può essere modificato anche dall’utente gyles; in altre parole ogni comando noi andremo a inserire nello script verrà lanciato come utente “root“!.
A questo punto il gioco è fatto. Apriamo con un editor di testo lo script “main_backup.sh” e sostituiamo il suo contenuto con il comando “chmod +s /bin/bash” che ogni minuto darà a chi lancia una nuova shell (/bin/bash) la possibilità di lanciarla come amministratore di sistema(root). Aspettiamo un minuto e poi lanciamo la nuova shell per ritrovarci utenti root e poter finalmente accedere al contenuto del file /root/root.txt.
Missione Compiuta!!!
